P2P Applications - Peer-to-Peer Computing: Applications, Architecture, Protocols, and Challenges - page 12

Napster [Napster, 2009], launched in 1999 and shut down in 2001 by court
order, was among the first P2P file sharing applications. From the perspective
of attracting users, Napster was highly successful in that at its peak reportedly
over 26 million participants joined the network. Napster's file sharing model
is not strictly a P2P one because it relies on centralized servers to host the file
lists for participants to search for desired files. Specifically, the client program
on a user's machine shows the file lists obtained from the connected server,
and then, the user can search and select appropriate peers for downloading.
Thus, the selection of peers is done manually by the user. As such, there was
essentially no control over the authenticity of files and the performance of
the downloading. With centralized servers at its core, the Napster network
was not highly scalable. Currently, WinMX [WinMX World, 2009] is the most
prominent client program that is based on the Napster related protocols.
Gnutella [Gnutella Protocol Development, 2009] represented a major im-
provement over the Napster model. Indeed, the Gnutella protocol is fully de-
centralized in that participating peers help each other in file discovery, control
messages routing, and file transmission. As such, “Gnutella” nowadays hardly
refers to any particular piece of P2P application. Rather it refers to a whole
family of file sharing applications that are implemented based on the open
Gnutella protocol. As in any fully decentralized file sharing system, when a
client starts, the very first problem is to discover and locate other active peers.
In the original design of the Gnutella protocol, this was based on a flooding
mechanism—the starting client broadcasts the so-called “ping” messages over
the network. When such a ping message is received by an active Gnutella user,
it replies a “pong” message to the starting client. Obviously, a more funda-
mental question is that to whom should the starting client send the requests
in the first place? Many heuristics are used in this bootstrapping process. For
example, the starting client can use the list of well-known users that come
with the client program. Another scheme is to use a Web cache of actively
connected machines.
From a scalability point of view, a drawback of the blind flooding approach
is that the volume of tra c generated could be large, even if the maximum
hop-count a request message can travel is usually limited to 7. Thus, the
notion of “ultra-peer” is introduced in the Gnutella protocol. Specifically,
some participating peers are designated as ultra-peers which play the role of
“hubs” or “routers” in the Gnutella network. When a new client starts, it
actually connects to several (e.g., three) such ultra-peers, each of which could
be connected to more than 30 other ultra-peers. Essentially, a user (as a leaf
node) sends a request message to its ultra-peers which then forward to its
connected ultra-peers. Consequently, with such a more hierarchical network
structure, the scope that can be reached by a request message becomes much
larger yet the tra c volume generated is limited.
As in Napster, when a Gnutella request finds a suitable provider for the
desired file, the two peers can then manage the transfer without any other