Traditional Applications Ø World Wide Web § TCP Connections The original version of HTTP (1.0) established a separate TCP connection for each o data item retrieved from the server. It’s not too hard to see how this was a very inefficient mechanism: connection setup o and teardown messages had to be exchanged between the client and server even if all the client wanted to do was verify that it had the most recent copy of a page. Thus, retrieving a page that included some text and a dozen icons or other small o graphics would result in 13 separate TCP connections being established and closed. 25
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. § 26
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 27
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 28
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 29
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 30
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. 31
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 32
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- access cookie: 1678 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 33
Cookies (continued) what cookies can be used for: aside authorization cookies and privacy: Ø § 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 34
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 35
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 36
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 37
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 154 Mbps 1.54 Mbps 154 Mbps consequences: access link § LAN utilization: 15% institutional 9.9% § access link utilization = 99% network 1 Gbps LAN § total delay = Internet delay + access delay + LAN delay § = 2 sec + minutes + usecs msecs Cost: increased access link speed (not cheap!) 38
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!) 39
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!) 40
Conditional GET server client 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> 41
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 42
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 43
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 44
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 45
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) 46
Sample SMTP interaction S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <alice@crepes.fr> S: 250 alice@crepes.fr... Sender ok C: RCPT TO: <bob@hamburger.edu> S: 250 bob@hamburger.edu ... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup? C: How about pickles? C: . S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection 47
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 48
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 § 49
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. 50
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 S: <message 1 contents> dele: delete Ø S: . quit Ø C: dele 2 C: quit S: +OK POP3 server signing off 51
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 Ø 52
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 53
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) 54
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) Sensitivity of the ear varies with frequency A loud tone can mask nearby tones 55
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) 56
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 57
Digital Video (2) Ø JPEG lossy compression sequence for one image: Step 1 Step 3 Step 2 Step 5 58
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 for Input 24-bit RGB pixels pixels every 4 pixels 59
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 60
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 / = 61
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 62
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 63
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 64
Streaming Stored Media (2) Ø Effective streaming starts the playout during transport § With RTSP (Real-Time Streaming Protocol) 65
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 66
Streaming Stored Media (4) Ø Parity packet can repair one lost packet in a group of N § Decoding is delayed for N packets 67
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 68
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) 69
Streaming Stored Media (7) Ø RTSP commands § Sent from player to server to adjust streaming 70
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] 71
Streaming Live Media (2) Ø With multicast streaming media, parity is effective § Clients can each lose a different packet and recover 72
Streaming Live Media (2) Ø Production side of a student radio station. 73
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) 74
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 75
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 76
Real-Time Conferencing (4) Ø Logical channels that make up an H.323 call 77
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 78
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 79
Real-Time Conferencing (7) Comparison of H.323 and SIP. 80
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” 81
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 82
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 Ø 83
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) 84
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 85
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 86
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 87
Infrastructure Services Name Resolution Ø Name resolution in practice, where the numbers 1–10 show the sequence of steps in the process. 88
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 89
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 90
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 91
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) 92
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 93
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 94
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) 95
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 capacity file, size F 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 96
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 97
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 98
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 99
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 100
Recommend
More recommend
