Ray Ozzie, the developer of Lotus Notes and more recently the founder of Groove Networks, asked us to come up with a clear marketing slogan that would let a busy system designer decide whether peer-to-peer was right for his system. We didn't succeed at finding a pithy summary, but we did make a list of applications that raise a warning flag. There are situations where peer-to-peer is counterindicated.
Peer-to-peer is probably not appropriate when it's important for everybody to know all the current data at the same time. You probably can't run a stock market with peer-to-peer, for instance, because fair pricing fundamentally depends on everybody knowing the asking price and seeing the impact of all bids. An airline reservation system wouldn't be appropriate either, unless each buyer is willing to sit on somebody else's lap. We did not achieve consensus on whether peer-to-peer applications are good for rapidly changing data.
Peer-to-peer systems seem to contain an inherent fuzziness. Gnutella, for instance, doesn't promise you'll find a file that's hosted on its system; it has a "horizon" beyond which you can't see what's there. Knighten said, "There are a lot of things in the peer-to-peer world that we can take advantage of only if we give up certitude." Most computers come and go on the Internet, so that the host for a particular resource may be there one minute and gone the next.
Furthermore, peer-to-peer seems to reward large communities. If very few people ask for a file on Freenet, it might drop off the caches of the various participating systems. Steve Burbeck, a Senior Technical Staff Member at IBM, pointed out that self-organizing file sharing systems like Napster, Gnutella and Freenet are affected by the popularity of files, and hence may be susceptible to the tyranny of the majority.
Some participants suggested that peer-to-peer is good if you have a strong idea what you're looking for (an author, for instance) but have no idea where it is. A centralized system like Yahoo! is better if you have only a vague idea what you're looking for, but possess some confidence that you can find it at a particular site.
Darren New of Invisible Worlds explained that the value of knowing what you want in advance gives the advantage to peer-to-peer systems where a lot of information is available to potential users out-of-band. This rather abstract statement becomes meaningful when one considers Napster. No one would be able to find much on Napster if they couldn't obtain the name of a band and its songs beforehand. Ironically, many people depend on traditional sales channels like Amazon.com to obtain names of songs before they troop over to Napster and download them. Thus, Napster requires a pre-existing, outside infrastructure.
Furthermore, data is easy to find if it's easy to categorize. Tim O'Reilly pointed out that people would have an easier time searching a peer-to-peer system for a pop song than for a particular combination of performers singing an opera number -- and they'd have even more trouble searching for a chapter in an O'Reilly book. Metadata, once again, proves key to the future of peer-to-peer.
Even if you don't know what you want, you might be able to find it by contacting a knowledgeable member of your online cohort.
Peer-to-peer does offer an alternative strength, though: connecting people. Even if you don't know what you want, you might be able to find it by contacting a knowledgeable member of your online cohort. You might even find your request met by an infobot (which records frequently asked questions along with their answers, and spits back answers to newsgroup users), which is a functioning application developed by Kevin Lenzo of Carnegie Mellon University.
Historically, the balance between centralized systems and peer-to-peer shifts back and forth. Many systems, like Usenet and IP routing, started off as pure peer-to-peer but developed some degree of hierarchy as they got bigger. Other systems started out centralized but got too big for it, like the Domain Name System (which had to give up single hosts files). Because of peer-to-peer's scalability, some systems are clearly going to require it. To quote IBM's Burbeck, "When you get up to a billion cellular phones and other devices, you have to be decentralized."
Barriers to peer-to-peer
As with any new technology, peer-to-peer has to grapple with old assumptions, which have been embodied in policies ranging in size from a site administrator's firewall configuration to acts of Congress.
These have already been mentioned. Low-cost technologies can deliver high bandwidth downstream, but cheat the user who wants to publish as well as read. License restrictions such as bans on running a service out of the home, while justifiable from the viewpoint of maintaining adequate throughput on multiple systems, also amputate the possibilities of peer-to-peer.
Firewalls and address translation
When it comes to IP addresses, IPv6 may eliminate the scarcity but not the scares. Most firewall administrators keep their users from getting fixed IP addresses out of fear that they make intrusion easier. The sense of security may be illusory (because people monitoring their own ports have reported intrusion attempts within a few minutes of bringing up their network software), but the practice makes it much harder for an end user's system to host a service.
Even if each user gets a fixed IP address, the Domain Name System is a barrier to end-to-end addressing. Domain names have become a significant expense over the years, and ICANN is not improving the situation. (For instance, they require anyone who wants a new top level domain to pay $50,000 just for the privilege of having the request considered.) For that reason, new services like AOL Instant Messenger and Napster bypass DNS and use their own addressing.
Unfortunately, such ad-hoc addressing solutions lead to problems of their own. AOL tries to shut out competitors by denying them its addresses. Systems that use proprietary systems of addressing can't interoperate. Most ad-hoc namespaces are flat and crude.
Finally, packet filtering, while it plays an important role in securing a LAN, also leads to "port 80 pollution" as everybody tries to use the Web for services that would be more appropriate with a different protocol. The solution to this problem, unfortunately, will not be in sight until operating systems become more secure and IP security can be set up with a few mouse clicks (or vocal commands).
Government restrictions have not yet affected peer-to-peer technologies, but could have a chilling effect in the future. Scott Miller, lead U.S. developer for Freenet, pointed out that early peer-to-peer systems happen to be associated with violations of intellectual property (at least in the minds of the copyright holders) but that such activities were neither the purpose of peer-to-peer nor the most likely types of mature applications to emerge. Nevertheless, a couple of participants reported that peer-to-peer has been branded with a scarlet I for Infringement in the minds of investors, courts, and the general public.
Software patents could also stifle technology. We spent some time discussing ways to use prior art searches of patents defensively.
Barriers to entry
Finally, things that currently make it hard for users to start a peer-to-peer service need to be attacked by the peer-to-peer developers themselves. If every new peer-to-peer service requires the user to download, install, and configure a new program, it will remain a craft shop for tinkerers. Shirky pointed out that Java was supposed to provide the universal client that allowed everything else to run seamlessly, but Java on the client didn't pan out. We need something as easy as the update service offered by Windows and some other products.
Even after users install a client, they may abort their involvement if they are forced to learn a system of metadata and apply a lot of tags. Jon Udell, programming consultant and Byte Magazine columnist, said, "When everybody's a publisher, responsibility goes along with that." Dornfest called for local vocabularies to provide just the right depth of metadata, combined with clients that allow its application with just a mouse click, a keystroke, or automagically.
Napster made the registration of users' MP3 files nearly automatic. Janelle Brown, senior writer at Salon, reminded us of the sad history of Hotline, a service similar to Napster that appeared much earlier but never took off. Among the various diagnoses the group offered in post mortem, it was pointed out that prospective users had to upload material before doing any downloads. That restriction may have turned them off. Nevertheless, another quid-pro-quo system -- where you have to provide a resource in order to use a resource -- is being tried by the new venture MojoNation.
The ability to trust the system and other users is critical. Balancing the privacy of the individual with the need to authenticate users and kick malicious disrupters off the system is a difficult feat.
In this article I've tried to summarize the most interesting themes from the September 2000 peer-to-peer summit. Leaders in the field are exploring more such themes in the book Peer-to-Peer, to be released by O'Reilly & Associates in February, and at the O'Reilly Peer-To-Peer Conference in San Francisco, which takes place February 14-16. I hope you'll stick around -- and don't be afraid to participate.
Discuss this article in the O'Reilly Network Linux Forum.
Return to the Linux DevCenter.