May 01 MacTech Online
Volume Number: 17 (2001)
Issue Number: 05
Column Tag: MacTech Online
by Jeff Clites firstname.lastname@example.org
The users of Napster couldn’t possibly have known what they were really doing. They thought they were just trading some music. The recording industry thought they were stealing. But what they were really doing, of course, was networking. Peer-to-peer networking, actually. In truth, peer-to-peer (or “p2p”) networking is nothing new, but it has taken a product like Napster, with its popularity and legal controversy, to bring it into the limelight. Now, not only are there new p2p applications, but there are articles, web sites, books, and conferences springing up. Like other “hot” technologies (Java and XML come to mind), there is a great deal of hype surrounding p2p — but there is also substance, if you dig deep enough.
As a side effect of the recent interest in p2p, there has also been a great deal of focus on defining what exactly constitutes a p2p technology. At its most basic, p2p networking is just client-server networking in which the machines involved act as clients sometimes and as servers other times. As a trivial example, two machines running FTP servers can act as peers. Some feel that “true” p2p application, in the modern sense, must explicitly allow for the involvement of computers which are not always connected to the internet and whose IP addresses change. But in truth, a precise definition is beside the point, as is the issue of whether a given application qualifies as p2p. What’s more important are the systems and technologies that are being developed, and the uses to which they are being put. At its core, the interesting part of p2p isn’t that it’s peer-based; the interesting aspect is content distribution, and putting this into the hands of end users.
From its inception, the web has been about content distribution — it was originally designed as a mechanism for sharing research papers. But end users in today’s web are largely passive — most users don’t produce web content, but only view it. But p2p technologies are changing this, and turning end users into active participants, and they’re doing this as a matter of course — for instance, Napster users are automatically servers of MP3 content. This is a theme which recurs in many p2p applications: users play the role of content providers without needing to make an extra effort to do so, and while they are becoming more involved in the Internet they are not necessarily participating in the web, per se — users are more often sharing files than creating web pages.
This month we are going to take a look at Gnutella, one of the many interesting p2p applications springing up today, both for its technological features and for the insights it gives into the p2p “movement”. It’s a file-sharing-focussed p2p application, and a contender to be the successor to Napster. But first we are going to look at Napster itself, and find out why it has turned out to be such an important technology.
Napster as a Paradigm
The most important technological insight of Napster was its judicious mixing of centralization and decentralization. In a nutshell, what Napster adds to the “two FTP servers” scenario is integration with a search engine. (From a sociological point of view, Napster also adds ease of use, and a focus on a specific type of content.) Searches in Napster are preformed via a central server which indexes the music on each of the connected Napster clients. This allows for fast and efficient searching. But actual file transfers are conducted directly between two client machines, without passing through any centralized server. This is key, because it allows the Napster system as a whole to effectively take advantage of the aggregate bandwidth and disk space of all of its users — there is no need for a huge disk farm to store the content, and an unlimited number of transfers between clients can happen simultaneously without impacting the performance of the system as a whole. The decentralized aspects are in a sense the most inspired strength of Napster, and they are really what has sparked interest in peer-to-peer technologies in themselves. The centralized search facilities are in a sense the greatest weakness, but more from a political or legal point of view than from a technological one, because they necessitate a single authority which can be targeted with legal action, and an essential linchpin which can be “attacked” to shut down the entire system. Unsurprisingly, this has led to a trend in new p2p technologies to try to avoid any centralization at all, in order to provide both legal and technological robustness against attempts to shut down any systems developed. This backlash is a mixed blessing, because centralization in and of itself it not always a flaw — some operations are appropriate to centralize, such as searching, and in the absence of worries about “social attacks” this is often the best approach. At the same time, a community obsessed with maximizing the “p” in p2p is producing some interesting systems which are pushing the limits of what would have been thought to be possible in a purely distributed peer system, and is giving us greater insight into what can and cannot be done without centralization. After the legal controversy dies down I think that we will again be designing systems which are a sensible mix of p2p and traditional client-server, but they will be better than they would have been without the war stories from today’s p2p innovators.
Gnutella began at AOL with developers from Nullsoft, the company behind the popular Winamp MP3 player for Windows, and it quickly became on open source project being developed outside of the company. It has been described as the open-source Napster. At the surface this is true, but Gnutella differs from Napster in several important ways.
To begin with, Gnutella is actually a protocol, rather than an application, and there are several different applications for multiple platforms which speak the Gnutella protocol. Like Napster, Gnutella software allows users to perform searches and transfer files, and the same software plays the role of both client and server, both downloading and vending content. The key difference is that Gnutella is completely decentralized — there is no central entity to service queries. When a Gnutella application starts up, it joins the Gnutella network by connecting to another “node” — to any other machine running Gnutella software. In the beginning, users would find another node to connect to through word-of-mouth, or from web sites which posted lists of IP addresses of nodes, but today there are nodes called “host caches” which are set up to vend the locations of active nodes to new users joining the network (one point of slight, and optional, centralization in Gnutella). Once a node has connected to a handful of other nodes, it is part of the network, and equivalent to every other node. This has been described as a software-based network on top of the physical network, and it’s in a constant state of flux as new nodes join and others drop out — as new connections form and old ones are severed, from one minute to the next. When a user want to search the network for a piece of content, his node sends his query to each of its “adjacent” nodes (the nodes to which it is connected), which in turn forward the query to the nodes that they know about, and so on. Each node can then respond to the query by sending its response back along the network to the node which originated the query. In case you missed it, Gnutella queries happen via a broadcast across the network of users, rather than through a central server which indexes all of the content. More about this in a minute. As responses to a query trickle back to a node, if any of them contain the URL of a file that the user want to download, he can download it directly from the machine which sent that response. This is the same strategy employed by Napster, in that the (potentially large) file transfers bypass the greater Gnutella network completely.
In addition to the search strategy, Gnutella differs from Napster in the search content. A Gnutella query is free-form, and each node is independent and free to interpret a query however it likes. Napster treats queries as searches for MP3s, but a Gnutella query could be looking for music, some other type of file, or a different kind of information entirely. Most commonly, a node will treat a query as a request for a file, and will match the query against either file names or file content (the former would be appropriate for an MP3, and the latter for a news article). But to demonstrate the flexibility of this approach, Gnutella developers set up a small network with nodes which each handled queries in a different way — one interpreted them as requests for stock quotes, one matched them against news headlines, and another evaluated them as arithmetic expressions — and provided a web-based search interface to the network. This demonstrated the flexibility of the notion of a query along the network, and also pointed out that private Gnutella networks could easily be set up to serve novel functions. (This type of private Gnutella network is trivial to set up — it’s just a set of nodes which don’t happen to know about any nodes outside of a small set.)
As mentioned above, Gnutella uses a broadcast-based approach to searching. This strategy is a key feature of Gnutella and its decentralization, and it’s arguably its fatal flaw. It’s a flaw because queries take a significant amount of bandwidth across the network, and this poses a direct barrier to scalability. Gnutella’s approach is actually quite strange, once you begin to analyze it, and it’s difficult to decide whether it’s clever or pathological. Although logically a broadcast, queries are passed from node to node via direct TCP/IP connection, rather than via UDP broadcast. Also, despite being TCP-based, the queries are lossy — nodes will discard their responses if querying nodes are reacting too slowly. This saves things somewhat, as it prevents a few slow nodes from clogging the network. Also, queries have a time-to-live (TTL), just like IP packets — typically, Gnutella queries have a TTL of 7, meaning that queries are only transmitted to nodes 7 hops away. On average, a query reaches about 10,000 other nodes.
The Gnutella community is quick to point out that this “distributed query” approach models the way humans interact, transferring knowledge in an ever-changing network of interactions. On the other hand, as nice as the analogy may sound, it might not be the best design strategy, and the comparison breaks down in the details. If you do the math, even with TTLs and lossy responses, the performance of Gnutella networks will degrade and hit a bandwidth wall when the network grows above a certain number of nodes. Steps are being taken to address the “bandwidth issue”, and more sophisticated software is being developed to implement various strategies. Interestingly, this problem is no surprise to Gnutella developers — it was known at the very beginning, and is an inherent problem with broadcasts. Nevertheless, developers persisted in this approach, demonstrating an enthusiasm (or dementia) which has been attendant to p2p development, characterized as a willingness to go ahead and try things which seem “theoretically impossible but practically possible”. This sounds like a rather irrational philosophy for a community of developers, but despite this Gnutella has actually performed better than the naysayers predicted, and has given us a better idea of what is possible with this type of approach. And although the Gnutella community is now forced to do some technological clean up, they are able to address the real problems that have actually arisen, at a point where they know the strengths and weaknesses of their system better than they would have to start out with, and so are in a better position to solve them.
If you want to learn more about the ever-changing p2p landscape, and about Gnutella in particular, there are several great places to start. O’Reilly’s OpenP2P portal site contains original content as well as pointers to articles on other sites, and has a Gnutella section which can help you keep up to speed as the technology develops. O’Reilly also has a recently-published book, Peer-to-Peer: Harnessing the Power of Disruptive Technologies (ISBN: 0-596-00110-X), with articles on specific p2p technologies as well as articles covering general topics which are relevant across applications. In particular, check out “Gnutella: Alive, Well, and Changing Fast” and “Gnutella and the Transient Web” here, and “The Gnutella paradox” on Salon.com. Also, the Gnutella web site at wego.com is a portal for both Gnutella developers and users, and Gnutelliums maintains information on all of the Gnutella clients available for various platforms. If you are interested in developing p2p software, or just in figuring out how certain things are done, the source code to these clients (often licensed under the GPL) is a great resource. It’s often included with the client distributions, or you can find much of it at GnutellaDev. And finally, if you plan on doing any Gnutella development, you’ll need to know the details of the protocol, which you can find at Gnutelliums and at Clip2.
Gnutella: Alive, Well, and Changing Fast
Gnutella and the Transient Web
The Gnutella paradox
Gnutella portal page
The GnutellaNet protocol at MROB
The Gnutella Protocol Specification v0.4
Lessons from Gnutella and Napster
The genesis and growth of Gnutella and Napster have a lot to tell us about both the technological and the sociological aspects of new technologies. In particular, Napster is popular not because it is p2p, but because people really like music — it's the content that's really important to the end user, not the means to get there, and it just happened that in Napster's case p2p was the best way to deliver this. I also find it telling that Napster isn't web browser based, but instead uses its own standalone client. This confounds the prevailing wisdom today that everything needs to live in a browser or the public won't use it. In Napster's case, it really wasn't technologically feasible to work inside of a browser, and I think it would have been a disaster if they had tried. The important lesson here is that if the content is compelling enough, and the technology delivers it well, then users are perfectly happy downloading a new piece of software to use. They really don't need to use Netscape or IE for everything, and I hope that developers realize this as they are planning for the next generation of applications.
In a way, Gnutella is a result of embracing the technology of Napster and inferring a set of ideals from it, rather than understanding what really has made it popular. On the other hand, there's really nothing wrong with that, and I don't think the Gnutella community would mind being accused of putting the cart before the horse. Not everything has to be the basis for a business plan, after all. Enthusiasm for the idea of p2p and a willingness to experiment are improving the underlying technology, and showing us what is possible, and in some cases how simply things can be done. And in the end, people are having fun with it — both developers and users. The "let's just try it and see what happens" approach is working out pretty well in fact. So when a business plan does come along, they'll be ready.