Lecture 21 P2P. Napster. Centralized Index. Napster. Gnutella. Peer-to-Peer Model March 16, Overview:

Transcription

1 PP Lecture 1 Peer-to-Peer Model March 16, 005 Overview: centralized database: Napster query flooding: Gnutella intelligent query flooding: KaZaA swarming: BitTorrent unstructured overlay routing: Freenet structured overlay routing: Distributed Hash Tables Napster Centralized Database: Join: on startup, client contacts central server Publish: reports list of files to central server Search: query the server => return someone that stores the requested file Fetch: get the file directly from peer Centralized Index Please give me foo.mp Servent 1 Servent Here it is 5 I am looking for 1 file foo.mp I have file Get it from foo.mp servent 1 4 Centralized Index Problems with Napster: centralized index is highly loaded if index fails, the whole system stops Napster Pros: simple search scope is O(1) controllable (pro or con?) Cons: server maintains O(N) State server does all processing single point of failure Gnutella In 000, J. Frankel and T. Pepper from Nullsoft released Gnutella Soon many other clients: Bearshare, Morpheus, LimeWire, etc. In 001, many protocol enhancements including ultrapeers 1

2 Gnutella Query Flooding: Join: on startup, client contacts a few other nodes; these become its neighbors Publish: no need Search: ask neighbors, who ask their neighbors, and so on... when/if found, reply to sender. Fetch: get the file directly from peer Gnutella (v0.4) PING Notify a peer of your existence PONG Reply to a PING request QUERY Find a file in the network RESPONSE Give the location of a file PUSHREQUEST Request a server behind a firewall to push a file out to a client. Flooding Searches We keep the servents, but we remove the centralized index. Each servent is connected to a few others. File search requests are sent recursively through the network, until the file is found or a distance limit is reached (e.g., hops). S1 S4 1 S S5 S6 S7 S8 * S9 Flooding Searches Advantages: real PP system (every node has same role) no centralized server self-organized (connect your servent to a few others) Drawbacks: each search generates lots of traffic certain nodes become highly linked/loaded distance limits: do not search entire system Flooding Searches Possible optimization: superpeers (Kazaa) subset of servers with high capacity is dynamically selected to act as local indexes normal clients only talk to superpeers superpeers talk to each other to resolve queries Gnutella Descriptor Header Descriptor ID uniquely identifies descriptor on the network Descriptor is 0x00 = Ping, 0x01 = Pong, 0x40 = Push, 0x80 = Query, 0x81 = Response TTL(0) = TTL(i)+Hops(i)

3 Gnutella Ping Gnutella Pong Descriptor No payload (i.e., payload length = 0). Used for probing the network. Responding to Ping descriptors. Enough information to establish connection. File sharing meta-data. Gnutella Query Descriptor Gnutella Response Descriptor For positive File Found replies to a query. For querying the network for a particular file or files (usually substring of file name). Quality of Service parameter (minimum speed). Result Set field includes file index, size and name. Gnutella Push Descriptor For getting files from firewall-protected servents. Request pushing a file from an internal node to an outside servent. Gnutella: Routing Unique IDs, servents memorize IDs to prevent looping. Pong descriptors are sent the same route as ping descriptors (if a servent sees a pong but did not see a ping, pong is discarded). Same with QueryHit and Query. Same with Push and QueryHit. Ping & query are forwarded to all neighbors except the one that the message came from. Each servent decrements TTL and increments Hops. If TTL is zero, the descriptor is not forwarded along any connection.

4 Gnutella: Downloads After query hits are received, servent can select file. Download request is via HTTP GET message (servent replies with HTTP OK followed by file data). Data is sent over direct TCP connection (not the Gnutella network), the protocol is HTTP. Gnutella Pros: Fully de-centralized Search cost distributed Cons: Search scope is O(N) Search time is O(???) Nodes leave often, network unstable Aside: Search Time Aside: All Peers Equal? 56kbps Modem 10Mbps LAN 56kbps Modem 56kbps Modem Aside: Network Resilience Partial Topology Random 0% die Targeted 4% die KaZaA In 001, KaZaA created by Dutch company KaZaA BV. Single network called FastTrack used by other clients as well: Morpheus, gift, etc. Eventually protocol changed so other clients could no longer talk to it. Most popular file sharing network today with >10 million users (number varies). 4

5 KaZaA Smart Query Flooding: Join: on startup, client contacts a supernode... may at some point become one itself Publish: send list of files to supernode Search: send query to supernode, supernodes flood query amongst themselves. Fetch: get the file directly from peer(s); can fetch simultaneously from multiple peers KaZaA Super Nodes KaZaA: File Insert insert(x, KaZaA: File Search search(a) --> )... Publish Query Replies search(a) --> I have X! Where is file A? KaZaA: Fetching KaZaA More than one node may have requested file... How to tell? must be able to distinguish identical files Not necessarily same filename same filename not necessarily same file... Use Hash of file KaZaA uses UUHash: fast, but not secure alternatives: MD5, SHA-1 How to fetch? Get bytes [ ] from A, [ ] from B alternative: Erasure Codes Pros: tries to take into account node heterogeneity: bandwidth host Computational Resources host Availability (?) rumored to take into account network locality Cons: mechanisms easy to circumvent still no real guarantees on search scope or search time 5

6 BitTorrent BitTorrent In 00, B. Cohen debuted BitTorrent Key motivation: popularity exhibits temporal locality (flash crowds) e.g., Slashdot effect, CNN on 9/11, new movie/game release Focused on efficient Fetching, not Searching: distribute the same file to all peers single publisher, multiple downloaders Has some real publishers: Blizzard Entertainment using it to distribute the beta of their new games Swarming: Join: contact centralized tracker server, get a list of peers. Publish: run a tracker server. Search: out-of-band, e.g., use Google to find a tracker for the file you want. Fetch: download chunks of the file from your peers. Upload chunks you have to them. BitTorrent: Publish/Join BitTorrent: Fetch Tracker BitTorrent: Sharing Strategy Employ Tit-for-tat sharing strategy I ll share with you if you share with me be optimistic: occasionally let freeloaders download otherwise no one would ever start! also allows you to discover better peers to download from when they reciprocate similar to: Prisoner s Dilemma Approximates Pareto Efficiency Game Theory: No change can make anyone better off without making others worse off BitTorrent Pros: works reasonably well in practice gives peers incentive to share resources; avoids freeloaders Cons: Pareto Efficiency relative weak condition central tracker server needed to bootstrap swarm (is this really necessary?) 6