P2P File Sharing Systems Johnny Wong Note: Materials of these slides are based on the those from the textbook “Computer Networking: A Top-Down Approach featuring the Internet” by J.F Kurose and K.W. Ross

P2P file sharing Alice chooses one of the peers, Bob. Example File is copied from Bob’s PC to Alice’s notebook: HTTP While Alice downloads, other users uploading from Alice. Alice’s peer is both a Web client and a transient Web server. All peers are servers = highly scalable! Example Alice runs P2P client application on her notebook computer Intermittently connects to Internet; gets new IP address for each connection Asks for “Hey Jude” Application displays other peers that have copy of Hey Jude.

P2P: centralized directory directory server peers Alice Bob 1 2 3 original “Napster” design 1) when peer connects, it informs central server: IP address content 2) Alice queries for “Hey Jude” 3) Alice requests file from Bob

P2P: problems with centralized directory Single point of failure Performance bottleneck Copyright infringement file transfer is decentralized, but locating content is highly centralized

P2P: Query flooding Send query to neighbors Neighbors forward query If queried peer has object, it sends message back to querying peer Gnutella no hierarchy use bootstrap node to learn about others join message join

P2P: more on query flooding Pros peers have similar responsibilities: no group leaders highly decentralized no peer maintains directory info Cons excessive query traffic query radius: may not have content when present bootstrap node maintenance of overlay network

P2P: decentralized directory Each peer is either a group leader or assigned to a group leader. Group leader tracks the content in all its children. Peer queries group leader; group leader may query other group leaders.

More about decentralized directory overlay network peers are nodes edges between peers and their group leaders edges between some pairs of group leaders virtual neighbors bootstrap node connecting peer is either assigned to a group leader or designated as leader advantages of approach no centralized directory server location service distributed over peers more difficult to shut down disadvantages of approach bootstrap node needed group leaders can get overloaded

Unstructured P2P File Sharing Centralized Napster Distributed Gnutella KaZaA

Napster: how does it work Application-level, client-server protocol over point-to-point TCP Centralized directory server Steps: connect to Napster server upload your list of files to server. give server keywords to search the full list with. select “best” of matching answers (pings) Pings the candidate server using RTT

Gnutella Open-source Links are TCP-connections Each peer sends a query to each of its peers; the receiving peer sends a search query; once the file is found, the response follows the search path backward to the querier; file transfer is point-to-point

Gnutella (con’t) more difficult to “pull plug” decentralized searching for files central directory server no longer the bottleneck more difficult to “pull plug” each application instance serves to: store selected files route queries from and to its neighboring peers respond to queries if file stored locally serve files

Gnutella history 3/14/00: release by AOL, almost immediately withdrawn became open source many iterations to fix poor initial design (poor design turned many people off) issues: how much traffic does one query generate? how many hosts can it support at once? what is the latency associated with querying? is there a bottleneck?

Gnutella: limited scope query Searching by flooding: if you don’t have the file you want, query 7 of your neighbors. if they don’t have it, they contact 7 of their neighbors, for a maximum hop count of 10. reverse path forwarding for responses (not files) (useful for saving TCP connections)

Gnutella in practice Gnutella traffic << KaZaA traffic Anecdotal: Couldn’t find anything Downloads wouldn’t complete Fixes: do things KaZaA is doing: hierarchy, queue management, parallel download,… good source for technical info/open questions about Gnutella: http://www.limewire.com/index.jsp/tech_papers

KaZaA: Technology Software Proprietary control data encrypted (including queries/responses) KaZaA Web site gives a few hits Some studies described in Web Everything in HTTP request and response messages Architecture hierarchical cross between Napster and Gnutella File transfer is not encrypted although the control data is encrypted

KaZaA: The service (2) User can configure max number of simultaneous uploads and max number of simultaneous downloads queue management at server and client Frequent uploaders can get priority in server queue Keyword search User can configure “up to x” responses to keywords Responses to keyword queries come in waves; stops when x responses are found From user’s perspective, service resembles Google, but provides links to MP3s and videos rather than Web pages

KaZaA: Architecture Each peer is either a supernode or an ordinary node (assigned to one supernode) Each supernode connected to many other supernodes (supernode overlay) Nodes that have more connection bandwidth and are more available are designated as supernodes Ordinary nodes: super nodes: m:1 Supernode: supernode: m:n

KaZaa Supernode Each supernode acts as a mini-Napster hub, tracking the content and IP addresses of its descendants Guess: supernode has (on average) 200-500 descendants; roughly 10,000 supernodes Low bandwidth or intermitted connections

KaZaA: Overlay maintenance List of potential supernodes included with software download New peer goes through list until it finds operational supernode Connects, obtains more up-to-date list Node then pings nodes on list and connects with the one with smallest RTT If supernode goes down, node obtains updated list and chooses new supernode

KaZaA Queries If x matches found, done. Node first sends query (keyword) to supernode Supernode responds with matches If x matches found, done. Otherwise, supernode forwards query to subset of supernodes If total of x matches found, done. Otherwise, query further forwarded Probably by original supernode rather than recursively? Not clear how the original supernode queries other supernodes until x matches are found? Or it use a recursive query