Peer-to-Peer - Computer Network Systems - Lecture Slides, Slides of Computer Networks

Download Peer-to-Peer - Computer Network Systems - Lecture Slides and more Slides Computer Networks in PDF only on Docsity! Lecture 10 Peer-to-Peer (p2p) Docsity.com Goals of Today’s Lecture Scalability in distributing a large file Single server and N clients Peer-to-peer system with N peers Searching for the right peer Central directory (Napster) Query flooding (Gnutella) Hierarchical overlay (Kazaa) BitTorrent Transferring large files Preventing free-riding Docsity.com Server Distributing a Large File d1 F bits d2 d3 d4 upload rate us Download rates di Internet Docsity.com Server Distributing a Large File Server sending a large file to N receivers Large file with F bits Single server with upload rate us Download rate di for receiver i Server transmission to N receivers Server needs to transmit NF bits Takes at least NF/us time Receiving the data Slowest receiver receives at rate dmin= mini{di} Takes at least F/dmin time Download time: max{NF/us, F/dmin} Docsity.com Speeding Up the File Distribution Increase the upload rate from the server Higher link bandwidth at the one server Multiple servers, each with their own link Requires deploying more infrastructure Alternative: have the receivers help Receivers get a copy of the data And then redistribute the data to other receivers To reduce the burden on the server Docsity.com Comparing the Two Models • Download time – Client-server: max{NF/us, F/dmin} – Peer-to-peer: max{F/us, F/dmin, NF/(us+sumi(ui))} • Peer-to-peer is self-scaling – Much lower demands on server bandwidth – Distribution time grows only slowly with N • But… – Peers may come and go – Peers need to find each other – Peers need to be willing to help each other Docsity.com Challenges of Peer-to-Peer Peers come and go Peers are intermittently connected May come and go at any time Or come back with a different IP address How to locate the relevant peers? Peers that are online right now Peers that have the content you want How to motivate peers to stay in system? Why not leave as soon as download ends? Why bother uploading content to anyone else? Docsity.com Locating the Relevant Peers Three main approaches Central directory (Napster) Query flooding (Gnutella) Hierarchical overlay (Kazaa, modern Gnutella) Design goals Scalability Simplicity Robustness Plausible deniability Docsity.com Napster Technology: Properties • Server’s directory continually updated – Always know what music is currently available – Point of vulnerability for legal action • Peer-to-peer file transfer – No load on the server – Plausible deniability for legal action (but not enough) • Proprietary protocol – Login, search, upload, download, and status operations – No security: cleartext passwords and other vulnerability • Bandwidth issues – Suppliers ranked by apparent bandwidth & response time Docsity.com Napster: Limitations of Central Directory • Single point of failure • Performance bottleneck • Copyright infringement • So, later P2P systems were more distributed – Gnutella went to the other extreme… File transfer is decentralized, but locating content is highly centralized Docsity.com Peer-to-Peer Networks: Gnutella • Gnutella history – 2000: J. Frankel & T. Pepper released Gnutella – Soon after: many other clients • e.g., Morpheus, Limewire, Bearshare – 2001: protocol enhancements, e.g., “ultrapeers” • Query flooding – Join: contact a few nodes to become neighbors – Publish: no need! – Search: ask neighbors, who ask their neighbors – Fetch: get file directly from another node Docsity.com Gnutella: Peer Joining Joining peer X must find some other peers Start with a list of candidate peers X sequentially attempts TCP connections with peers on list until connection setup with Y X sends Ping message to Y Y forwards Ping message. All peers receiving Ping message respond with Pong message X receives many Pong messages X can then set up additional TCP connections Docsity.com Gnutella: Pros and Cons Advantages Fully decentralized Search cost distributed Processing per node permits powerful search semantics Disadvantages Search scope may be quite large Search time may be quite long High overhead, and nodes come and go often Docsity.com Peer-to-Peer Networks: KaAzA KaZaA history 2001: created by Dutch company (Kazaa BV) Single network called FastTrack used by other clients as well Eventually the protocol changed so other clients could no longer talk to it Smart query flooding  Join: on start, the client contacts a super-node • and may later become one Publish: client sends list of files to its super-node Search: send query to super-node, and the super-nodes flood queries among themselves Fetch: get file directly from peer(s); can fetch from multiple peers at once Docsity.com Peer-to-Peer Networks: BitTorrent BitTorrent history and motivation 2002: B. Cohen debuted BitTorrent Key motivation: popular content • Popularity exhibits temporal locality (Flash Crowds) • E.g., Slashdot/Digg effect, CNN Web site on 9/11, release of a new movie or game Focused on efficient fetching, not searching • Distribute same file to many peers • Single publisher, many downloaders Preventing free-loading Docsity.com BitTorrent: Simultaneous Downloading Divide large file into many pieces Replicate different pieces on different peers A peer with a complete piece can trade with other peers Peer can (hopefully) assemble the entire file Allows simultaneous downloading Retrieving different parts of the file from different peers at the same time And uploading parts of the file to peers Important for very large files Docsity.com BitTorrent: Tracker • Infrastructure node – Keeps track of peers participating in the torrent • Peers register with the tracker – Peer registers when it arrives – Peer periodically informs tracker it is still there • Tracker selects peers for downloading – Returns a random set of peers – Including their IP addresses – So the new peer knows who to contact for data • Can have “trackerless” system using DHT Docsity.com BitTorrent: Overall Architecture A B C Peer [Leech] Downloader “US” Peer [Seed] Peer [Leech] Tracker Web Server Docsity.com BitTorrent: Overall Architecture Peer [Leech] Downloader “US” A B C Peer [Seed] Peer [Leech] Tracker Web Server Docsity.com A B C Peer [Leech] Downloader “US” Peer [Seed] Peer [Leech] Tracker Web Server BitTorrent: Overall Architecture Docsity.com BitTorrent: Overall Architecture A B C Peer [Leech] Downloader “US” Peer [Seed] Peer [Leech] Tracker Web Server Docsity.com BitTorrent: Chunk Request Order Which chunks to request? Could download in order Like an HTTP client does Problem: many peers have the early chunks Peers have little to share with each other Limiting the scalability of the system Problem: eventually nobody has rare chunks E.g., the chunks need the end of the file Limiting the ability to complete a download Solutions: random selection and rarest first Docsity.com BitTorrent: Rarest Chunk First Which chunks to request first? The chunk with the fewest available copies i.e., the rarest chunk first Benefits to the peer Avoid starvation when some peers depart Benefits to the system Avoid starvation across all peers wanting a file Balance load by equalizing # of copies of chunks Docsity.com BitTyrant: Gaming BitTorrent • BitTorrent can be gamed, too – Peer uploads to top N peers at rate 1/N – E.g., if N=4 and peers upload at 15, 12, 10, 9, 8, 3 – … then peer uploading at rate 9 gets treated quite well • Best to be the Nth peer in the list, rather than 1st – Offer just a bit more bandwidth than the low-rate peers – But not as much as the higher-rate peers – And you’ll still be treated well by others • BitTyrant software – Uploads at higher rates to higher-bandwidth peers – http://bittyrant.cs.washington.edu/ 40 Docsity.com BitTorrent Today Significant fraction of Internet traffic Estimated at 30% Though this is hard to measure Problem of incomplete downloads Peers leave the system when done Many file downloads never complete Especially a problem for less popular content Still lots of legal questions remains Further need for incentives Docsity.com Conclusions Peer-to-peer networks Nodes are end hosts Primarily for file sharing, and recently telephony Finding the appropriate peers Centralized directory (Napster) Query flooding (Gnutella) Super-nodes (KaZaA) BitTorrent Distributed download of large files Anti-free-riding techniques Great example of how change can happen so quickly in application-level protocols Docsity.com