Traditional Applications Ø World Wide Web § TCP Connections To overcome this situation, HTTP version 1.1 introduced persistent connections— o the client and server can exchange multiple request/response messages over the same TCP connection. Persistent connections have many advantages. o ü First, they obviously eliminate the connection setup overhead, thereby reducing the load on the server, the load on the network caused by the additional TCP packets, and the delay perceived by the user. ü Second, because a client can send multiple request messages down a single TCP connection, TCP’s congestion window mechanism is able to operate more efficiently. This is because it’s not necessary to go through the slow start phase for each page. § 24
Non-persistent HTTP suppose user enters URL: (contains text, references to 10 www.someSchool.edu/someDepartment/home.index jpeg images) 1a. HTTP client initiates TCP connection to HTTP server (process) at 1b.HTTP server at host www.someSchool.edu on port 80 www.someSchool.edu waiting for TCP connection at port 80. “accepts” connection, notifying client 2.HTTP client sends HTTP request message (containing URL) into TCP 3.HTTP server receives request message, connection socket. Message indicates forms response message containing that client wants object requested object, and sends message someDepartment/home.index into its socket time 25
Non-persistent HTTP (cont.) 4.HTTP server closes TCP connection. 5 . HTTP client receives response message containing html file, displays html. Parsing html file, finds 10 referenced jpeg objects time 6.Steps 1-5 repeated for each of 10 jpeg objects 26
Non-persistent HTTP: response time RTT (definition): time for a small packet to travel from client to server and back HTTP response time: initiate TCP connection one RTT to initiate TCP Ø RTT connection request file one RTT for HTTP request and Ø time to RTT first few bytes of HTTP response transmit file to return file received file transmission time Ø non-persistent HTTP response Ø time time time = 2RTT+ file transmission time 27
Persistent and non-persistent HTTP persistent HTTP: non-persistent HTTP issues: Ø server leaves connection Ø requires 2 RTTs per object open after sending response Ø OS overhead for each TCP Ø subsequent HTTP messages connection between same client/server Ø browsers often open sent over open connection parallel TCP connections to Ø client sends requests as fetch referenced objects soon as it encounters a referenced object Ø as little as one RTT for all the referenced objects 28
Caching Ø One of the most active areas of research (and entrepreneurship) in the Internet today is how to effectively cache Web pages. Ø Caching has benefits. § From the client’s perspective, a page that can be retrieved from a nearby cache can be displayed much more quickly than if it has to be fetched from across the world. § From the server’s perspective, having a cache intercept and satisfy a request reduces the load on the server. 29
Caching Ø Caching can be implemented in many different places. § a user’s browser can cache recently accessed pages, and simply display the cached copy if the user visits the same page again. § a site can support a single site-wide cache. Ø This allows users to take advantage of pages previously downloaded by other users. Ø Closer to the middle of the Internet, ISPs can cache pages. Ø Note that in the second case, the users within the site most likely know what machine is caching pages on behalf of the site, and they configure their browsers to connect directly to the caching host. This node is sometimes called a proxy 30
Cookies: keeping “state” (cont.) client server ebay 8734 usual http request msg Amazon server cookie file creates ID usual http response backend 1678 for user create set-cookie: 1678 database entry ebay 8734 amazon 1678 usual http request msg cookie- cookie: 1678 access specific action usual http response msg one week later: access usual http request msg ebay 8734 cookie- cookie: 1678 amazon 1678 specific action usual http response msg 31
Cookies (continued) what cookies can be used for: aside cookies and privacy: authorization Ø § cookies permit sites to learn a shopping carts Ø lot about you recommendations Ø § you may supply name and e- user session state (Web e-mail) Ø mail to sites how to keep “state”: § protocol endpoints: maintain state at sender/receiver over multiple transactions § cookies: http messages carry state 32
Web caches (proxy server) goal: satisfy client request without involving origin server Ø user sets browser: Web accesses via cache Ø browser sends all HTTP proxy requests to cache server client origin § object in cache: cache server returns object § else cache requests object from origin server, then returns object to client client origin server 33
More about Web caching Ø cache acts as both client and server why Web caching? § server for original requesting client § reduce response time for § client to origin server client request Ø typically cache is installed § reduce traffic on an by ISP (university, institution’s access link company, residential ISP) § Internet dense with caches: enables “poor” content providers to effectively deliver content 34
Caching example: assumptions: § avg object size: 100K bits origin § avg request rate from browsers to servers origin servers:15/sec public § avg data rate to browsers: 1.50 Mbps Internet § RTT from institutional router to any origin server: 2 sec § access link rate: 1.54 Mbps 1.54 Mbps access link consequences: problem! institutional § LAN utilization: 15% network § access link utilization = 99% 1 Gbps LAN § total delay = Internet delay + access delay + LAN delay = 2 sec + minutes + usecs 35
Caching example: fatter access link assumptions: § avg object size: 100K bits origin § avg request rate from browsers to origin servers servers:15/sec public § avg data rate to browsers: 1.50 Mbps Internet § RTT from institutional router to any origin server: 2 sec § access link rate: 1.54 Mbps 1.54 Mbps 154 Mbps 154 Mbps consequences: access link § LAN utilization: 15% institutional § access link utilization = 99% 9.9% network 1 Gbps LAN § total delay = Internet delay + access delay + LAN delay § = 2 sec + minutes + usecs msecs Cost: increased access link speed (not cheap!) 36
Caching example: install local cache assumptions: § avg object size: 100K bits origin § avg request rate from browsers to origin servers servers:15/sec public § avg data rate to browsers: 1.50 Mbps Internet § RTT from institutional router to any origin server: 2 sec § access link rate: 1.54 Mbps consequences: 1.54 Mbps access link § LAN utilization: 15% § access link utilization = ? institutional § total delay = Internet delay + access delay + network LAN delay = ? 1 Gbps LAN local web How to compute link cache utilization, delay? Cost: web cache (cheap!) 37
Caching example: install local cache Calculating access link utilization, delay with cache: origin Ø suppose cache hit rate is 0.4 servers public § 40% requests satisfied at cache, 60% Internet requests satisfied at origin Ø access link utilization: § 60% of requests use access link Ø data rate to browsers over access link 1.54 Mbps access link = 0.6*1.50 Mbps = .9 Mbps § utilization = 0.9/1.54 = .58 institutional network 1 Gbps LAN Ø total delay local web § = 0.6 * (delay from origin servers) +0.4 * (delay cache when satisfied at cache) § = 0.6 (2.01) + 0.4 (~msecs) = ~ 1.2 secs § less than with 154 Mbps link (and cheaper too!) 38
Conditional GET client server Goal: don’t send object if Ø cache has up-to-date cached version HTTP request msg object If-modified-since: <date> § no object transmission delay not § lower link utilization modified HTTP response before cache: specify date of Ø HTTP/1.0 <date> 304 Not Modified cached copy in HTTP request If-modified-since: <date> HTTP request msg server: response contains Ø object If-modified-since: <date> no object if cached copy is modified up-to-date: after HTTP response <date> HTTP/1.0 200 OK HTTP/1.0 304 Not Modified <data> 39
Electronic Mail Ø SMTP, MIME, IMAP § Email is one of the oldest network applications § It is important o (1) to distinguish the user interface (i.e., your mail reader) from the underlying message transfer protocols (such as SMTP or IMAP), and o (2) to distinguish between this transfer protocol and a companion protocol (RFC 822 and MIME) that defines the format of the messages being exchanged 40
Electronic Mail Three major components: outgoing user message queue user agents Ø agent user mailbox mail servers Ø mail user simple mail transfer protocol: SMTP Ø server agent SMTP User Agent mail user server agent a.k.a. “mail reader” Ø SMTP composing, editing, reading mail Ø messages SMTP user agent e.g., Outlook, Thunderbird, iPhone mail Ø mail client server user outgoing, incoming messages stored on Ø agent server user agent 41
Electronic Mail: servers mail servers: outgoing user message queue agent mailbox contains incoming Ø user mailbox messages for user mail user server message queue of outgoing (to be agent Ø SMTP sent) mail messages mail user server agent SMTP protocol between mail Ø SMTP servers to send email messages SMTP user § client: sending mail server agent mail § “server”: receiving mail server server user agent user agent 42
Electronic Mail: SMTP [RFC 2821] Ø uses TCP to reliably transfer email message from client to server, port 25 Ø direct transfer: sending server to receiving server Ø three phases of transfer § handshaking (greeting) § transfer of messages § closure Ø command/response interaction (like HTTP ) § commands: ASCII text § response: status code and phrase Ø messages must be in 7-bit ASCI 43
Scenario: Alice sends message to Bob 1) Alice uses UA to compose message “to” 4) SMTP client sends Alice’s message bob@someschool.edu over the TCP connection 2) Alice’s UA sends message to her mail 5) Bob’s mail server places the server; message placed in message message in Bob’s mailbox queue 6) Bob invokes his user agent to read 3) client side of SMTP opens TCP connection message with Bob’s mail server user user 1 mail mail agent agent server server 2 6 3 4 5 Alice’s mail server Bob’s mail server (rutgers.edu) (albany.edu) 44
SMTP: final words comparison with HTTP: SMTP uses persistent connections Ø SMTP requires message (header & Ø HTTP: pull Ø body) to be in 7-bit ASCII SMTP: push Ø SMTP server uses CRLF.CRLF to Ø both have ASCII Ø determine end of message command/response interaction, status codes HTTP: each object Ø encapsulated in its own response message SMTP: multiple objects sent Ø in multipart message 45
Mail message format SMTP: protocol for exchanging email messages header RFC 822: standard for text message blank format: line header lines, e.g., Ø § To: body § From: § Subject: different from SMTP MAIL FROM, RCPT TO: commands! MIME – Multipurpose Internet Ø Body: the “message” Ø Mail Extensions § ASCII characters only § Supports non-text attachments 46
Mail access protocols mail access user user SMTP SMTP protocol agent agent (e.g., POP, IMAP ) sender’s mail receiver’s mail server server SMTP: delivery/storage to receiver’s server Ø mail access protocol: retrieval from server Ø § POP: Post Office Protocol [RFC 1939]: authorization, download § IMAP: Internet Mail Access Protocol [RFC 1730]: more features, including manipulation of stored messages on server § HTTP: gmail, Hotmail, Yahoo! Mail, etc. 47
POP3 protocol authorization phase S: +OK POP3 server ready C: user bob client commands: Ø S: +OK C: pass hungry user: declare username § S: +OK user successfully logged on pass: password § C: list server responses Ø S: 1 498 § +OK S: 2 912 § -ERR S: . C: retr 1 transaction phase, client: S: <message 1 contents> S: . list: list message numbers Ø C: dele 1 retr: retrieve message by number Ø C: retr 2 dele: delete S: <message 1 contents> Ø S: . quit Ø C: dele 2 C: quit S: +OK POP3 server signing off 48
POP3 (more) and IMAP IMAP more about POP3 keeps all messages in one place: at previous example uses POP3 Ø Ø server “download and delete” mode allows user to organize messages in § Bob cannot re-read e-mail if he Ø folders changes client keeps user state across sessions: POP3 “download-and-keep”: Ø Ø copies of messages on different names of folders and mappings Ø clients between message IDs and folder name POP3 is stateless across sessions Ø 49
Multimedia Applications Ø Audio and video have become key types of traffic, e.g., voice over IP, and video streaming. § Digital audio § Digital video § Streaming stored media § Streaming live media § Real-time conferencing 50
Digital Audio (1) Ø ADC (Analog-to-Digital Converter) produces digital audio from a microphone § Telephone: 8000 8-bit samples/second (64 Kbps); computer audio is usually better quality (e.g., 16 bit) ADC Digital audio Continuous audio (sampled, 4-bit quantized) (sine wave) 51
Digital Audio (2) Ø Digital audio is typically compressed before it is sent § Lossy encoders (like Advanced Audio Coding - AAC) exploit human perception § It is not necessary to encode signals whose power falls below Threshold of audibility. § Large compression ratios (can be >10X) ~ 20Hz –20KHz Sensitivity of the ear varies with frequency A loud tone can mask nearby tones 52
Digital Audio (3) Ø Perceptual Coding § Based on science of psychoacoustics (way humans perceive sound) § Frequency Masking § Temporal Masking § Examples: MP3, AAC Ø Huffman Encoding § Assigns short codes to numbers that appear frequently Masked Frequencies Frequency Information Audio Samples Encoded Audio Sampling Digital Psychoacoustic Huffman (1, 2, 5 Filters Model Encoding channels) 53
Digital Video (1) Ø Video is digitized as pixels (sampled, quantized) § SD TV quality: 640x480 pixels, 24-bit color, 30 times/sec § HD TV quality: 1280x720 pixels § Player refreshes 500-100 times to minimize flicker Ø Video is sent compressed due to its large bandwidth § Lossy compression exploits human perception o E.g., JPEG for still images, MPEG, H.264 for video § Large compression ratios (often 50X for video) § Video is normally > 1 Mbps, versus >10 kbps for speech and >100 kbps for music 54
Digital Video (2) Ø JPEG lossy compression sequence for one image: Step 1 Step 2 Step 3 Step 5 55
Digital Video (3) Ø Step 1: Pixels are mapped to luminance (brightness)/chrominance (YCbCr) color space § Luma signal (Y), Chroma signal: 2 components (Cb and Cr) § Chrominance is sub-sampled, the eye is less sensitive to chrominance 8-bit luminance 8-bit chrominances Input 24-bit RGB pixels pixels for every 4 pixels 56
Digital Video (4) Ø Step 2: Each component block is transformed to spatial frequencies with DCT (Discrete Cosine Transformation) § Captures the key image features Transformed block One component block 57
Digital Video (5) Ø Step 3: DCT coefficients are quantized by dividing by thresholds; reduces bits in higher spatial frequencies § Top left element is differenced over blocks (Step 4) Thresholds Input Output / = 58
Digital Video (6) Ø Step 5: The block is run-length encoded in a zig-zag order. Then it is Huffman coded before sending (Step 6) Order in which the block coefficients are sent 59
Digital Video (7) Ø MPEG compresses over a sequence of frames, further using motion tracking to remove temporal redundancy § MPEG Output § I (Intra-coded) frames are self-contained § P (Predictive) frames use block motion predictions § B (Bidirectional) frames may base prediction on future frame Three consecutive frames with stationary and moving components 60
Streaming Stored Media (1) Ø A simple method to stream stored media, e.g., for video on demand, is to fetch the video as a file download § But has large startup delay, except for short files 61
Streaming Stored Media (2) Ø Effective streaming starts the playout during transport § With RTSP (Real-Time Streaming Protocol) 62
Streaming Stored Media (3) Ø Key problem: how to handle transmission errors Strategy Advantage Disadvantage Use reliable transport Repairs all errors Increases jitter significantly (TCP) Add FEC (e.g., Repairs most errors Increases overhead, decoding parity) complexity and jitter Interleave media Masks most errors Slightly increases decoding complexity and jitter 63
Streaming Stored Media (4) Ø Parity packet can repair one lost packet in a group of N § Decoding is delayed for N packets 64
Streaming Stored Media (5) Ø Interleaving spreads nearby media samples over different transmissions to reduce the impact of loss Packet stream Media samples Loss reduces temporal resolution; doesn’t leave a gap 65
Streaming Stored Media (6) Ø Key problem: media may not arrive in time for playout due to variable bandwidth and loss/retransmissions § Client buffers media to absorb jitter; we still need to pick an achievable media rate Safety margin, Can pause server (or go to avoid a stall ahead and save to disk) 66
Streaming Stored Media (7) Ø RTSP commands § Sent from player to server to adjust streaming 67
Streaming Live Media (1) Ø Streaming live media is similar to the stored case plus: § Can’t stream faster than “live rate” to get ahead o Usually need larger buffer to absorb jitter § Often have many users viewing at the same time o UDP with multicast greatly improves efficiency. It is rarely available, so many TCP connections are used. o For very many users, content distribution is used [later] 68
Streaming Live Media (2) Ø With multicast streaming media, parity is effective § Clients can each lose a different packet and recover 69
Streaming Live Media (2) Ø Production side of a student radio station. 70
Real-Time Conferencing (1) Ø Real-time conferencing has two or more connected live media streams, e.g., voice over IP, Skype video call Ø Key issue over live streaming is low (interactive) latency § Want to reduce delay to near propagation § Benefits from network support, e.g., QoS § Or, benefits from ample bandwidth (no congestion) 71
Real-Time Conferencing (2) Ø H.323 architecture for Internet telephony supports calls between Internet computers and PSTN phones. VoIP Internet/PSTN call Internet Gatekeeper controls calls for LAN hosts 72
Real-Time Conferencing (3) Ø H.323 protocol stack: § Call is digital audio/video over RTP/UDP/IP § Call setup is handled by other protocols (Q.931 etc.) Application 73
Real-Time Conferencing (4) Ø Logical channels that make up an H.323 call 74
Real-Time Conferencing (5) Ø SIP (Session Initiation Protocol) is an alternative to H.323 to set up real-time calls § Simple, text-based protocol with URLs for addresses § Data is carried with RTP / RTCP as before 75
Real-Time Conferencing (6) Ø Setting up a call with the SIP three-way handshake § Proxy server lets a remote callee be connected § Call data flows directly between caller/callee 76
Real-Time Conferencing (7) Comparison of H.323 and SIP. 77
DNS: domain name system people: many identifiers: Domain Name System: § SSN, name, passport # § distributed database Internet hosts, routers: implemented in hierarchy of § IP address (32 bit) - used for many name servers addressing datagrams § application-layer protocol: hosts, § “name”, e.g., www.yahoo.com name servers communicate to - used by humans resolve names (address/name translation) Q: how to map between IP address and name, and vice versa ? note: core Internet function, implemented as application-layer protocol complexity at network’s “edge” 78
DNS: services, structure DNS services why not centralize DNS? hostname to IP address Ø single point of failure Ø translation traffic volume Ø host aliasing Ø distant centralized database Ø § canonical, alias names maintenance Ø mail server aliasing Ø load distribution Ø A: doesn‘t scale! § replicated Web servers: many IP addresses correspond to one name 79
Domain Name Space Ø DNS is hierarchical Ø Assigned based on affiliation of institution 80
DNS: a distributed, hierarchical database Root DNS Servers … … org DNS servers edu DNS servers com DNS servers poly.edu umass.edu pbs.org yahoo.com amazon.com DNS servers DNS servers DNS servers DNS servers DNS servers client wants IP for www.amazon.com; 1 st approximation: client queries root server to find com DNS server Ø client queries .com DNS server to get amazon.com DNS server Ø client queries amazon.com DNS server to get IP address for www.amazon.com Ø 81
DNS: root name servers contacted by local name server that can not resolve name Ø root name server: Ø § contacts authoritative name server if name mapping not known § gets mapping § returns mapping to local name server c. Cogent, Herndon, VA (5 other sites) k. RIPE London (17 other sites) d. U Maryland College Park, MD h. ARL Aberdeen, MD i. Netnod, Stockholm (37 other sites) j. Verisign, Dulles VA (69 other sites ) m. WIDE Tokyo e. NASA Mt View, CA (5 other sites) f. Internet Software C. Palo Alto, CA (and 48 other sites) 13 logical root name “servers” a. Verisign, Los Angeles CA worldwide (5 other sites) b. USC-ISI Marina del Rey, CA • each “server” replicated many l. ICANN Los Angeles, CA times (41 other sites) g. US DoD Columbus, OH (5 other sites) 82
TLD, authoritative servers top-level domain (TLD) servers: § responsible for com, org, net, edu, aero, jobs, museums, and all top- level country domains, e.g.: uk, fr, ca, jp § Network Solutions maintains servers for .com TLD § Educause for .edu TLD authoritative DNS servers: § organization’s own DNS server(s), providing authoritative hostname to IP mappings for organization’s named hosts § can be maintained by organization or service provider 83
Local DNS name server Ø does not strictly belong to hierarchy Ø each ISP (residential ISP, company, university) has one § also called “default name server” Ø when host makes DNS query, query is sent to its local DNS server § has local cache of recent name-to-address translation pairs (but may be out of date!) § acts as proxy, forwards query into hierarchy 84
DNS name resolution example root DNS server host at cis.poly.edu wants IP Ø address for gaia.cs.umass.edu 2 3 TLD DNS server 4 iterated query: 5 § contacted server replies local DNS server with name of server to dns.poly.edu contact 6 7 § “I don’t know this name, but 1 8 ask this server” authoritative DNS server dns.cs.umass.edu requesting host cis.poly.edu gaia.cs.umass.edu 85
Infrastructure Services Name Resolution Ø Name resolution in practice, where the numbers 1–10 show the sequence of steps in the process. 86
DNS name resolution example root DNS server recursive query: 3 2 § puts burden of name 7 6 resolution on contacted name server TLD DNS server § heavy load at upper levels of hierarchy? local DNS server 4 dns.poly.edu 5 1 8 authoritative DNS server dns.cs.umass.edu requesting host cis.poly.edu gaia.cs.umass.edu 87
DNS: caching, updating records Ø once (any) name server learns mapping, it caches mapping § cache entries timeout (disappear) after some time (TTL) § TLD servers typically cached in local name servers o thus root name servers not often visited Ø cached entries may be out-of-date (best effort name-to- address translation!) § if name host changes IP address, may not be known Internet-wide until all TTLs expire Ø update/notify mechanisms proposed IETF standard § RFC 2136 88
DNS records DNS: distributed database storing resource records (RR) RR format: (name, value, type, ttl) type=A type=CNAME § name is hostname § name is alias name for some “canonical” § value is IP address (the real) name § www.ibm.com is really type=NS servereast.backup2.ibm.com § value is canonical name name is domain (e.g., foo.com) value is hostname of authoritative type=MX name server for this domain § value is name of mailserver associated with name 89
DNS protocol, messages Ø query and reply messages, both with same message format 2 bytes 2 bytes message header identification flags § identification: 16 bit # for # questions # answer RRs query, reply to query uses # authority RRs # additional RRs same # questions (variable # of questions) § flags: § query or reply answers (variable # of RRs) § recursion desired authority (variable # of RRs) § recursion available § reply is authoritative additional info (variable # of RRs) 90
DNS Protocol, messages 2 bytes 2 bytes identification flags # questions # answer RRs # authority RRs # additional RRs name, type fields questions (variable # of questions) for a query RRs in response answers (variable # of RRs) to query records for authority (variable # of RRs) authoritative servers additional “helpful” additional info (variable # of RRs) info that may be used 91
Inserting records into DNS Ø example: new startup “Network Utopia” Ø register name networkuptopia.com at DNS registrar (e.g., Network Solutions) § provide names, IP addresses of authoritative name server (primary and secondary) § registrar inserts two RRs into .com TLD server: (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, 212.212.212.1, A) Ø create authoritative server type A record for www.networkuptopia.com; type MX record for networkutopia.com 92
Pure P2P architecture Ø no always-on server Ø arbitrary end systems directly communicate Ø peers are intermittently connected and change IP addresses examples: § file distribution (BitTorrent) § Streaming (KanKan) § VoIP (Skype) 93
File distribution: client-server vs P2P Question: how much time to distribute file (size F ) from one server to N peers ? § peer upload/download capacity is limited resource u s : server upload capacity d i : peer i download u 1 d 1 file, size F capacity u 2 u s d 2 server d i u N network (with abundant bandwidth) u i d N u i : peer i upload capacity 94
File distribution time: client-server server transmission: must Ø sequentially send (upload) N file F u s copies : d i § time to send one copy: F/u s network u i § time to send N copies: NF/u s client: each client must download Ø file copy d min = min client download rate q min client download time: F/d min q time to distribute F to N clients using client-server approach D c-s > max{NF/u s, ,F/d min } increases linearly in N 95
File distribution time: P2P server transmission: must upload Ø at least one copy F u s § time to send one copy: F/u s d i client: each client must download Ø network file copy u i § min client download time: F/d min clients: as aggregate must Ø download NF bits § max upload rate (limiting max download rate) is u s + S u i time to distribute F P2P approach D P2P >=max{F/u s, ,F/d min, ,NF/( u s + S u i ) } to N clients using increases linearly in N … … but so does this, as each peer brings service capacity 96
Client-server vs. P2P: example client upload rate = u , F/u = 1 hour, u s = 10u, d min ≥ u s 3.5 P2P Minimum Distribution Time 3 Client-Server 2.5 2 1.5 1 0.5 0 0 5 10 15 20 25 30 35 N 97
P2P file distribution: BitTorrent protocol § file divided into 256Kb chunks § peers in torrent send/receive file chunks torrent: group of peers tracker: tracks peers participating in torrent exchanging chunks of a file Alice arrives … … obtains list of peers from tracker … and begins exchanging file chunks with peers in torrent 98
P2P file distribution: BitTorrent Ø peer joining torrent: § has no chunks, but will accumulate them over time from other peers § registers with tracker to get list of peers, connects to subset of peers ( “ neighbors ” ) Ø while downloading, peer uploads chunks to other peers Ø peer may change peers with whom it exchanges chunks Ø churn: peers may come and go Ø once peer has entire file, it may (selfishly) leave or (altruistically) remain in torrent 99
BitTorrent: requesting, sending file chunks requesting chunks: sending chunks: tit-for-tat § at any given time, different peers § Alice sends chunks to those four peers have different subsets of file currently sending her chunks at chunks highest rate • other peers are choked by Alice § periodically, Alice asks each peer (do not receive chunks from her) for list of chunks that they have • re-evaluate top 4 every 10 secs § Alice requests missing chunks from peers, rarest first § every 30 secs: randomly select another peer, starts sending chunks • “ optimistically unchoke ” this peer • newly chosen peer may join top 4 100
Recommend
More recommend
