Application Layer Application Layer File Distribution: Server-Client vs P2P File distribution time: server-client Question : How much time to distribute file Server server sequentially from one server to N peers ? u 2 F u 1 d 1 sends N copies: d 2 u s u s : server upload NF/u s time bandwidth Network (with d N Server client i takes F/d i abundant bandwidth) u i : peer i upload u N time to download bandwidth u 2 u 1 d 1 d 2 u s d i : peer i download File, size F bandwidth Time to distribute F d N to N clients using = d cs = max { NF/u s , F/min(d i ) } Network (with abundant bandwidth) client/server approach i u N increases linearly in N (for large N) CSE Department CSE Department 85 86 Application Layer Application Layer Server-client vs. P2P: example File distribution time: P2P Client upload rate = u, F/u = 1 hour, u s = 10u, d min ≥ u s Server server must send one u 2 F copy: F/u s time u 1 d 1 3.5 d 2 u s P2P client i takes F/d i time Minimum Distribution Time 3 Client-Server Network (with to download d N 2.5 abundant bandwidth) NF bits must be u N 2 downloaded (aggregate) fastest possible upload rate: u s + S u i 1.5 1 0.5 0 d P2P = max { F/u s , F/min(d i ) , NF/(u s + S u i ) } 0 5 10 15 20 25 30 35 i N CSE Department CSE Department 87 88 Application Layer Application Layer File distribution: BitTorrent Torrent File P2P file distribution A .torrent file is a text file, which consists of two parts torrent: group of tracker: tracks peers peers exchanging participating in torrent chunks of a file (1) Information about Tracker obtain list of peers (2) Information about the file to be shared trading chunks index of the blocks of the file hash value of each block Bram Cohen Published on peer April, 2001 CSE Department CSE Department 89 90 15
Application Layer Application Layer Overall Architecture Overall Architecture Tracker Tracker Web Web Server Server C C A A Peer Peer Peer Peer [Seed] [Seed] B B [Leech] [Leech] Downloader Peer Downloader Peer “US” [Leech] “US” [Leech] CSE Department CSE Department 91 92 Application Layer Application Layer Overall Architecture Overall Architecture Tracker Tracker Web Web Server Server C C A A Peer Peer Peer [Seed] Peer [Seed] B B [Leech] [Leech] Downloader Downloader Peer Peer “US” “US” [Leech] [Leech] CSE Department CSE Department 93 94 Application Layer Application Layer Overall Architecture Overall Architecture Tracker Tracker Web Web Server Server C C A A Peer Peer Peer Peer [Seed] [Seed] B B [Leech] [Leech] Downloader Peer Downloader Peer “US” [Leech] “US” [Leech] CSE Department CSE Department 95 96 16
Application Layer Application Layer Overall Architecture BitTorrent (1) Tracker Web Server file divided into 256KB chunks . peer joining torrent: has no chunks, but will accumulate them over time registers with tracker to get list of peers, connects to subset of peers (“neighbors”) C while downloading, peer uploads chunks to other A peers. Peer peers may come and go Peer [Seed] B once peer has entire file, it may (selfishly) leave or [Leech] (altruistically) remain Downloader Peer “US” [Leech] CSE Department CSE Department 97 98 Application Layer Application Layer BitTorrent (2) DHT (Distributed Hash Table) Sending Chunks: tit-for-tat Alice sends chunks to four Pulling Chunks neighbors currently at any given time, sending her chunks at the different peers have highest rate different subsets of re-evaluate top 4 every file chunks 10 secs periodically, a peer (Alice) asks each every 30 secs: randomly neighbor for list of select another peer, chunks that they have. starts sending chunks A class of a decentralized distributed system that provides a lookup service; newly chosen peer may Alice sends requests ( key , value ) pairs are stored in a DHT, and any participating node can join top 4 efficiently retrieve the value associated with a given key. for her missing chunks Responsibility for maintaining the mapping from keys to values is distributed rarest first among the nodes Highly scalable! CSE Department CSE Department 99 100 Application Layer Application Layer Hash Table Distributed Hash Table (DHT) DHT = distributed P2P database Database has (key, value) pairs; key: ss number; value: human name key: content type; value: IP address Peers query DB with key DB returns values that match the key Peers can also insert (key, value) CSE Department CSE Department 101 102 17
Application Layer Application Layer DHT Identifiers How to assign keys to peers? Central issue: Assign integer identifier to each peer in range [0,2 n -1]. Assigning (key, value) pairs to peers. Rule: assign key to the peer that has the Each identifier can be represented by n bits. closest ID. Convention in lecture: closest is the Require each key to be an integer in same range. immediate successor of the key. To get integer keys , hash original key. Example: n=4; peers: 1,3,4,5,8,10,12,14; eg, key = h(“Led Zeppelin IV”) key = 13, then successor peer = 14 This is why they call it a distributed “hash” table key = 15, then successor peer = 1 CSE Department CSE Department 103 104 Application Layer Application Layer Circle DHT (2) Circular DHT (1) Overlay Link 1 Not the real link! O(N) messages Who’s resp 0001 on avg to resolve for key 1110 ? 3 15 query, when there I am are N peers 0011 4 1111 1110 12 5 0100 1110 10 1110 8 1100 Each peer only aware of immediate successor 0101 1110 1110 and predecessor. Define closest 1110 as closest 1010 “ Overlay network ” 1000 successor CSE Department CSE Department 105 106 Application Layer Application Layer Circular DHT with Shortcuts Peer Churn 1 1 Who’s resp • To handle peer churn, require for key 1110? each peer to know the IP address 3 3 of its two successors. 15 15 • Each peer periodically pings its two successors to see if they 4 4 are still alive . 12 12 5 5 How to achieve 10 O(log N) search time? 10 8 8 Peer 5 abruptly leaves Each peer keeps track of IP addresses of predecessor, successor, short cuts . Peer 4 detects; makes 8 its immediate successor; Reduced from 6 to 2 messages. asks 8 who its immediate successor is; makes 8’s Possible to design shortcuts so O(log N) neighbors, O(log immediate successor its second successor. N) messages in query What if peer 13 wants to join? CSE Department CSE Department 107 108 18
Application Layer Application Layer Chapter 2: Summary Chapter 2: Summary our study of network apps now complete! Most importantly: learned about protocols specific protocols: application architectures HTTP client-server typical request/reply Important themes: FTP P2P message exchange: SMTP, POP, IMAP control vs. data msgs hybrid DNS in-band, out-of-band client requests info or application service P2P: BitTorrent, Skype service centralized vs. socket programming requirements: server responds with decentralized data, status code reliability, bandwidth, stateless vs. stateful delay message formats: reliable vs. unreliable Internet transport headers: fields giving msg transfer service model info about data “complexity at network data: info being connection-oriented, edge” communicated reliable: TCP unreliable, datagrams: UDP CSE Department CSE Department 109 110 Application Layer Application Layer Labs with Wireshark Wireshark The best way to learn protocols: by "seeing protocols in action" and by "playing around with protocols" observing the sequence of messages exchanges between two protocol entities delving down into the details of protocol operation causing protocols to perform certain actions and then observing these actions and their consequences. Wireshark: a very good network protocol analyzer CSE Department CSE Department 111 112 Application Layer Application Layer The User Interface Labs for Chapter 2 Two Labs HTTP DNS Every student should complete all labs Write your answers (HTTP & DNS) in paper. Due on 30 April 2015 (Thursday) CSE Department CSE Department 113 114 19
Recommend
More recommend