• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Week3 applications

Week3 applications






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Week3 applications Week3 applications Presentation Transcript

    • Chapter 2Application LayerA note on the use of these ppt slides:We’re making these slides freely available to all (faculty, students, readers).They’re in PowerPoint form so you can add, modify, and delete slides(including this one) and slide content to suit your needs. They obviously Computer Networking:represent a lot of work on our part. In return for use, we only ask the A Top Down Approach,following: If you use these slides (e.g., in a class) in substantially unaltered form, 5th edition.that you mention their source (after all, we’d like people to use our book!) Jim Kurose, Keith Ross Addison-Wesley, April If you post any slides in substantially unaltered form on a www site, thatyou note that they are adapted from (or perhaps identical to) our slides, andnote our copyright of this material. 2009.Thanks and enjoy! JFK/KWRAll material copyright 1996-2009J.F Kurose and K.W. Ross, All Rights Reserved 2: Application Layer 1
    • Chapter 2: Application layerÌ 2.1 Principles of Ì 2.6 P2P applications network applications Ì 2.7 Socket programmingÌ 2.2 Web and HTTP with TCPÌ 2.3 FTP Ì 2.8 Socket programmingÌ 2.4 Electronic Mail with UDP  SMTP, POP3, IMAPÌ 2.5 DNS 2: Application Layer 2
    • Chapter 2: Application LayerOur goals: Ì learn about protocolsÌ conceptual, by examining popular implementation application-level aspects of network protocols application protocols  HTTP  transport-layer  FTP service models  SMTP / POP3 / IMAP  client-server  DNS paradigm Ì programming network  peer-to-peer applications  socket API paradigm (tutorial) 2: Application Layer 3
    • Some network appsÌ e-mail Ì voice over IPÌ web Ì real-time videoÌ instant messaging conferencingÌ remote login Ì grid computingÌ P2P file sharing ÌÌ multi-user network Ì games ÌÌ streaming stored video clips 2: Application Layer 4
    • Creating a network app application transport network data linkwrite programs that physical  run on (different) end systems  communicate over network  e.g., web server software communicates with browser software application transportNo need to write software network data link for network-core devices application physical transport network  Network-core devices do data link physical not run user applications  applications on end systems allows for rapid app development, propagation 2: Application Layer 5
    • Application architecturesÌ Client-serverÌ Peer-to-peer (P2P)Ì Hybrid of client-server and P2P 2: Application Layer 6
    • Client-server architecture server:  always-on host  permanent IP address  server farms for scaling clients:client/server  communicate with server  may be intermittently connected  may have dynamic IP addresses  do not communicate directly with each other 2: Application Layer 7
    • Pure P2P architectureÌ no always-on serverÌ arbitrary end systems directly communicate peer-peerÌ peers are intermittently connected and change IP addressesHighly scalable but difficult to manage 2: Application Layer 8
    • Hybrid of client-server and P2PSkype  voice-over-IP P2P application  centralized server: finding address of remote party:  client-client connection: direct (not through server)Instant messaging  chatting between two users is P2P  centralized service: client presence detection/location • user registers its IP address with central server when it comes online • user contacts central server to find IP addresses of buddies 2: Application Layer 9
    • Processes communicatingProcess: program running Client process: process within a host. that initiatesÌ within same host, two communication processes communicate Server process: process using inter-process that waits to be communication (defined contacted by OS). Ì Note: applications withÌ processes in different P2P architectures have hosts communicate by client processes & exchanging messages server processes 2: Application Layer 10
    • Sockets host or host orÌ process sends/receives server server messages to/from its socket controlled by app developerÌ socket analogous to door process process  sending process shoves socket socket message out door TCP with TCP with buffers, Internet buffers,  sending process relies on variables variables transport infrastructure on other side of door which controlled brings message to socket by OS at receiving processÌ API: (1) choice of transport protocol; (2) ability to fix a few parameters (more on this in tutorial) 2: Application Layer 11
    • Addressing processesÌ to receive messages, process must have identifierÌ host device has unique 32-bit IP addressÌ Q: does IP address of host suffice for identifying the process? 2: Application Layer 12
    • Addressing processesÌ to receive messages, Ì identifier includes both process must have IP address and port identifier numbers associated withÌ host device has unique process on host. 32-bit IP address Ì Example port numbers:Ì Q: does IP address of  HTTP server: 80 host on which process  Mail server: 25 runs suffice for Ì to send HTTP message identifying the to gaia.cs.umass.edu web process? server:  A: No, many  IP address: processes can be  Port number: 80 running on same host Ì more shortly… 2: Application Layer 13
    • App-layer protocol definesÌ Types of messages Public-domain protocols: exchanged, Ì defined in RFCs  e.g., request, response Ì allows forÌ Message syntax: interoperability  what fields in messages & Ì e.g., HTTP, SMTP how fields are delineatedÌ Message semantics Proprietary protocols:  meaning of information in Ì e.g., Skype fieldsÌ Rules for when and how processes send & respond to messages 2: Application Layer 14
    • What transport service does an app need?Data loss ThroughputÌ some apps (e.g., audio) can Ì some apps (e.g., tolerate some loss multimedia) requireÌ other apps (e.g., file minimum amount of transfer, telnet) require throughput to be 100% reliable data “effective” transfer Ì other apps (“elastic apps”)Timing make use of whateverÌ some apps (e.g., throughput they get Internet telephony, interactive games) Security require low delay to be Ì Encryption, data integrity, “effective” … 2: Application Layer 15
    • Transport service requirements of common apps Application Data loss Throughput Time Sensitive file transfer no loss elastic no e-mail no loss elastic no Web documents no loss elastic noreal-time audio/video loss-tolerant audio: 5kbps-1Mbps yes, 100’s msec video:10kbps-5Mbps stored audio/video loss-tolerant same as above yes, few secs interactive games loss-tolerant few kbps up yes, 100’s msec instant messaging no loss elastic yes and no 2: Application Layer 16
    • Internet transport protocols servicesTCP service: UDP service:Ì connection-oriented: setup Ì unreliable data transfer required between client and between sending and server processes receiving processÌ reliable transport between Ì does not provide: sending and receiving process connection setup,Ì flow control: sender won’t reliability, flow control, overwhelm receiver congestion control, timing, throughput guarantee, orÌ congestion control: throttle security sender when network overloadedÌ does not provide: timing, Q: why bother? Why is minimum throughput there a UDP? guarantees, security 2: Application Layer 17
    • Internet apps: application, transport protocols Application Underlying Application layer protocol transport protocol e-mail SMTP [RFC 2821] TCPremote terminal access Telnet [RFC 854] TCP Web HTTP [RFC 2616] TCP file transfer FTP [RFC 959] TCP streaming multimedia HTTP (eg Youtube), TCP or UDP RTP [RFC 1889] Internet telephony SIP, RTP, proprietary (e.g., Skype) typically UDP 2: Application Layer 18
    • Web and HTTPFirst some jargonÌ Web page consists of objectsÌ Object can be HTML file, JPEG image, Java applet, audio file,…Ì Web page consists of base HTML-file which includes several referenced objectsÌ Each object is addressable by a URLÌ Example URL: www.someschool.edu/someDept/pic.gif host name path name 2: Application Layer 19
    • HTTP overviewHTTP: hypertext transfer protocol HT TP re qÌ Web’s application layer PC running HT ues TP t protocol Explorer re s pon seÌ client/server model  client: browser that st requests, receives, re que TP se Server T p on “displays” Web objects H res running T P Apache Web  server: Web server HT server sends objects in response to requests Mac running Navigator 2: Application Layer 20
    • HTTP overview (continued)Uses TCP: HTTP is “stateless”Ì client initiates TCP Ì server maintains no connection (creates socket) information about to server, port 80 past client requestsÌ server accepts TCP connection from client aside Protocols that maintainÌ HTTP messages (application- “state” are complex! layer protocol messages) Ì past history (state) must exchanged between browser be maintained (HTTP client) and Web Ì if server/client crashes, server (HTTP server) their views of “state” mayÌ TCP connection closed be inconsistent, must be reconciled 2: Application Layer 21
    • HTTP connectionsNonpersistent HTTP Persistent HTTPÌ At most one object is Ì Multiple objects can sent over a TCP be sent over single connection. TCP connection between client and server. 2: Application Layer 22
    • Nonpersistent HTTP (contains text,Suppose user enters URL 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 waiting www.someSchool.edu on port 80 for TCP connection at port 80. “accepts” connection, notifying client 2. HTTP client sends HTTP request message (containing URL) into TCP connection 3. HTTP server receives request socket. Message indicates message, forms response that client wants object message containing requested someDepartment/home.index object, and sends message into its socket time 2: Application Layer 23
    • Nonpersistent 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 objectstime 6. Steps 1-5 repeated for each of 10 jpeg objects 2: Application Layer 24
    • Non-Persistent HTTP: Response timeDefinition of RTT: time for a small packet to travel from client to server and back. initiate TCP connectionResponse time: RTTÌ one RTT to initiate TCP request file connection time to RTT transmitÌ one RTT for HTTP file request and first few file received bytes of HTTP response to return time timeÌ file transmission timetotal = 2RTT+transmit time 2: Application Layer 25
    • Persistent HTTPNonpersistent HTTP issues: Persistent HTTPÌ requires 2 RTTs per object Ì server leaves connectionÌ OS overhead for each TCP open after sending connection responseÌ browsers often open parallel Ì subsequent HTTP messages TCP connections to fetch between same referenced objects client/server sent over open connection Ì client sends requests as soon as it encounters a referenced object Ì as little as one RTT for all the referenced objects 2: Application Layer 26
    • HTTP request message Ì two types of HTTP messages: request, response Ì HTTP request message:  ASCII (human-readable format) request line (GET, POST, GET /somedir/page.html HTTP/1.1HEAD commands) Host: www.someschool.edu User-agent: Mozilla/4.0 header Connection: close lines Accept-language:fr Carriage return, (extra carriage return, line feed) line feed indicates end of message 2: Application Layer 27
    • HTTP request message: general format 2: Application Layer 28
    • Uploading form inputPost method:Ì Web page often includes form input URL method:Ì Input is uploaded to Ì Uses GET method server in entity body Ì Input is uploaded in URL field of request line: www.somesite.com/animalsearch?monkeys&banana 2: Application Layer 29
    • Method typesHTTP/1.0 HTTP/1.1Ì GET Ì GET, POST, HEADÌ POST Ì PUTÌ HEAD  uploads file in entity body to path specified  asks server to leave in URL field requested object out of response Ì DELETE  deletes file specified in the URL field 2: Application Layer 30
    • HTTP response message status line (protocol status code HTTP/1.1 200 OKstatus phrase) Connection close Date: Thu, 06 Aug 1998 12:00:15 GMT header Server: Apache/1.3.0 (Unix) lines Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html data, e.g., data data data data data ... requested HTML file 2: Application Layer 31
    • HTTP response status codesIn first line in server->client response message.A few sample codes:200 OK  request succeeded, requested object later in this message301 Moved Permanently  requested object moved, new location specified later in this message (Location:)400 Bad Request  request message not understood by server404 Not Found  requested document not found on this server505 HTTP Version Not Supported 2: Application Layer 32
    • HTTP ServerHow to scale to large number of users?-Fork--create a copy of itself which handles each client request-Threads--create a thread to handle each request
    • HTTP ServerForked server operation--A single listen socket for client requests--A connected socket to each request--A forked process for each connected socket---child process closes listening socket (Why?)--Server goes back to listening--Forked process exits after connection is processed.
    • HTTP ServerThreaded server--Listening is similar--connection socket created--A thread is given the connection socket---listening socket is left alone by thread--Thread closes connected socket after request--Server keeps listening for new requests
    • HTTP ClientHow to reduce fetch time?-Pipelining--send multiple requests without waiting for responses –persistent connections--Pipelined requests are expected to be served “in-order” to client--Use headers to separate responses-Multiple requests sent via--Threads or Forked processes
    • Trying out HTTP (client side) for yourself1. Telnet to your favorite Web server: telnet cis.poly.edu 80 Opens TCP connection to port 80 (default HTTP server port) at cis.poly.edu. Anything typed in sent to port 80 at cis.poly.edu2. Type in a GET HTTP request: GET /~ross/ HTTP/1.1 By typing this in (hit carriage Host: cis.poly.edu return twice), you send this minimal (but complete) GET request to HTTP server3. Look at response message sent by HTTP server! 2: Application Layer 37
    • User-server state: cookies Example:Many major Web sites use cookies Ì Susan always accessFour components: Internet always from PC 1) cookie header line of Ì visits specific e- HTTP response message commerce site for first 2) cookie header line in time HTTP request message 3) cookie file kept on Ì when initial HTTP user’s host, managed by requests arrives at site, user’s browser site creates: 4) back-end database at Web site  unique ID  entry in backend database for ID 2: Application Layer 38
    • Cookies: keeping “state” (cont.) client server ebay 8734 usual http request msg Amazon server cookie file usual http response creates ID Set-cookie: 1678 1678 for user create ebay 8734 entry amazon 1678 usual http request msg cookie: 1678 cookie- access specificone week later: usual http response msg action backend database access ebay 8734 usual http request msg amazon 1678 cookie: 1678 cookie- spectific usual http response msg action 2: Application Layer 39
    • Cookies (continued) asideWhat cookies can bring: Cookies and privacy:Ì authorization Ì cookies permit sites toÌ shopping carts learn a lot about you Ì you may supply nameÌ recommendations and e-mail to sitesÌ user session state (Web e-mail)How to keep “state”:Ì protocol endpoints: maintain state at sender/receiver over multiple transactionsÌ cookies: http messages carry state 2: Application Layer 40
    • Web caches (proxy server)Goal: satisfy client request without involving origin serverÌ user sets browser: origin server Web accesses via cache HT Proxy TP stÌ browser sends all req server re que HT ues TP e client TP t T ons HTTP requests to res H e sp pon se TPr HT cache ues t eq se  object in cache: cache T Pr on HT p returns object P re s H TT  else cache requests object from origin client origin server, then returns server object to client 2: Application Layer 41
    • More about Web cachingÌ cache acts as both Why Web caching? client and server Ì reduce response timeÌ typically cache is for client request installed by ISP Ì reduce traffic on an (university, company, institution’s access residential ISP) link. Ì Internet dense with caches: enables “poor” content providers to effectively deliver content (but so does P2P file sharing) 2: Application Layer 42
    • Caching example originAssumptions serversÌ average object size = 100,000 public bits InternetÌ avg. request rate from institution’s browsers to origin servers = 15/sec 1.5 MbpsÌ delay from institutional router access link to any origin server and back institutional to router = 2 sec network 10 Mbps LANConsequencesÌ utilization on LAN = 15%Ì utilization on access link = 100% institutionalÌ total delay = Internet delay + cache access delay + LAN delay = 2 sec + minutes + milliseconds 2: Application Layer 43
    • Caching example (cont) originpossible solution serversÌ increase bandwidth of access public link to, say, 10 Mbps InternetconsequenceÌ utilization on LAN = 15%Ì utilization on access link = 15% 10 MbpsÌ Total delay = Internet delay + access link access delay + LAN delay institutional = 2 sec + msecs + msecs network 10 Mbps LANÌ often a costly upgrade institutional cache 2: Application Layer 44
    • Caching example (cont) originpossible solution: install servers cache publicÌ suppose hit rate is 0.4 InternetconsequenceÌ 40% requests will be satisfied almost immediately 1.5 MbpsÌ 60% requests satisfied by access link origin serverÌ utilization of access link institutional reduced to 60%, resulting in network 10 Mbps LAN negligible delays (say 10 msec)Ì total avg delay = Internet delay + access delay + LAN institutional delay = .6*(2.01) secs + . cache 4*milliseconds < 1.4 secs 2: Application Layer 45
    • Conditional GETÌ Goal: don’t send object if cache server cache has up-to-date cached HTTP request msg version If-modified-since: objectÌ cache: specify date of <date> not cached copy in HTTP request modified HTTP response If-modified-since: HTTP/1.0 <date> 304 Not ModifiedÌ server: response contains no object if cached copy is up- HTTP request msg to-date: If-modified-since: HTTP/1.0 304 Not <date> object Modified modified HTTP response HTTP/1.0 200 OK <data> 2: Application Layer 46
    • FTP: the file transfer protocol FTP file transfer FTP FTP user client server interface user at host remote file local file system system Ì transfer file to/from remote host Ì client/server model  client: side that initiates transfer (either to/from remote)  server: remote host Ì ftp: RFC 959 Ì ftp server: port 21 2: Application Layer 47
    • FTP: separate control, data connections TCP control connectionÌ FTP client contacts FTP server port 21 at port 21, TCP is transport protocol TCP data connectionÌ client authorized over control FTP port 20 FTP connection client serverÌ client browses remote Ì server opens another TCP directory by sending commands data connection to transfer over control connection. another file.Ì when server receives file Ì control connection: “out of transfer command, server band” opens 2nd TCP connection (for Ì FTP server maintains “state”: file) to client current directory, earlierÌ after transferring one file, authentication server closes data connection. 2: Application Layer 48
    • FTP commands, responsesSample commands: Sample return codesÌ sent as ASCII text over Ì status code and phrase (as control channel in HTTP)Ì USER username Ì 331 Username OK,Ì PASS password password requiredÌ LIST return list of file in Ì 125 data connection current directory already open; transfer startingÌ RETR filename retrieves Ì 425 Can’t open data (gets) file connectionÌ STOR filename stores Ì 452 Error writing (puts) file onto remote file host 2: Application Layer 49
    • Electronic Mail outgoing message queue user mailbox userThree major components: agentÌ user agents mail userÌ mail servers server agentÌ simple mail transfer SMTP mail protocol: SMTP server user SMTP agentUser AgentÌ a.k.a. “mail reader” SMTP mail userÌ composing, editing, reading agent server mail messagesÌ e.g., Eudora, Outlook, elm, user Mozilla Thunderbird agent userÌ outgoing, incoming messages agent stored on server 2: Application Layer 50
    • Electronic Mail: mail servers userMail Servers agentÌ mailbox contains incoming mail user messages for user server agentÌ message queue of outgoing SMTP (to be sent) mail messages mail server userÌ SMTP protocol between mail servers to send email SMTP agent messages SMTP  client: sending mail mail user agent server server  “server”: receiving mail user server agent user agent 2: Application Layer 51
    • 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  commands: ASCII text  response: status code and phraseÌ messages must be in 7-bit ASCII 2: Application Layer 52
    • Scenario: Alice sends message to Bob1) Alice uses UA to compose 4) SMTP client sends Alice’s message and “to” message over the TCP bob@someschool.edu connection2) Alice’s UA sends message 5) Bob’s mail server places the to her mail server; message message in Bob’s mailbox placed in message queue 6) Bob invokes his user agent3) Client side of SMTP opens to read message TCP connection with Bob’s mail server 1 mail mail server user user server 2 agent agent 3 6 4 5 2: Application Layer 53
    • Sample SMTP interactionS: 220 hamburger.eduC: HELO crepes.frS: 250 Hello crepes.fr, pleased to meet youC: MAIL FROM: <alice@crepes.fr>S: 250 alice@crepes.fr... Sender okC: RCPT TO: <bob@hamburger.edu>S: 250 bob@hamburger.edu ... Recipient okC: DATAS: 354 Enter mail, end with "." on a line by itselfC: Do you like ketchup?C: How about pickles?C: .S: 250 Message accepted for deliveryC: QUITS: 221 hamburger.edu closing connection 2: Application Layer 54
    • Try SMTP interaction for yourself:Ì telnet servername 25Ì see 220 reply from serverÌ enter HELO, MAIL FROM, RCPT TO, DATA, QUIT commandsabove lets you send email without using email client (reader) 2: Application Layer 55
    • SMTP: final wordsÌ SMTP uses persistent Comparison with HTTP: connections Ì HTTP: pullÌ SMTP requires message Ì SMTP: push (header & body) to be in 7- bit ASCII Ì both have ASCIIÌ SMTP server uses command/response CRLF.CRLF to determine interaction, status codes end of message Ì HTTP: each object encapsulated in its own response msg Ì SMTP: multiple objects sent in multipart msg 2: Application Layer 56
    • Mail message formatSMTP: protocol for exchanging email msgs header blankRFC 822: standard for text line message format:Ì header lines, e.g., To:  body  From:  Subject: different from SMTP commands!Ì body  the “message”, ASCII characters only 2: Application Layer 57
    • Mail access protocols SMTP SMTP access user user agent protocol agent 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 (agent <-->server) and download  IMAP: Internet Mail Access Protocol [RFC 1730] • more features (more complex) • manipulation of stored msgs on server  HTTP: gmail, Hotmail, Yahoo! Mail, etc. 2: Application Layer 58
    • POP3 protocol S: +OK POP3 server ready C: user bobauthorization phase S: +OK C: pass hungryÌ client commands: S: +OK user successfully logged on  user: declare username C: list  pass: password S: 1 498Ì server responses S: 2 912  +OK S: . C: retr 1  -ERR S: <message 1 contents>transaction phase, client: S: . C: dele 1Ì list: list message numbers C: retr 2Ì retr: retrieve message by S: <message 1 contents> number S: . C: dele 2Ì dele: delete C: quitÌ quit S: +OK POP3 server signing off 2: Application Layer 59
    • POP3 (more) and IMAPMore about POP3 IMAPÌ Previous example uses Ì Keep all messages in “download and delete” one place: the server mode. Ì Allows user toÌ Bob cannot re-read e- organize messages in mail if he changes folders client Ì IMAP keeps user stateÌ “Download-and-keep”: across sessions: copies of messages on  names of folders and different clients mappings betweenÌ POP3 is stateless message IDs and folder name across sessions 2: Application Layer 60
    • DNS: Domain Name SystemPeople: many identifiers: Domain Name System:  SSN, name, passport # Ì distributed database implemented in hierarchy ofInternet hosts, routers: many name servers  IP address (32 bit) - Ì application-layer protocol used for addressing host, routers, name servers to datagrams communicate to resolve names  “name”, e.g., (address/name translation) ww.yahoo.com - used by  note: core Internet humans function, implemented asQ: map between IP application-layer protocol addresses and name ?  complexity at network’s “edge” 2: Application Layer 61
    • DNSDNS services Why not centralize DNS?Ì hostname to IP Ì single point of failure address translation Ì traffic volumeÌ host aliasing Ì distant centralized  Canonical, alias names databaseÌ mail server aliasing Ì maintenanceÌ load distribution  replicated Web servers: doesn’t scale! set of IP addresses for one canonical name 2: Application Layer 62
    • Distributed, Hierarchical Database Root DNS Servers com DNS servers org DNS servers edu DNS servers pbs.org poly.edu umass.eduyahoo.com amazon.com DNS servers DNS serversDNS serversDNS servers DNS serversClient wants IP for www.amazon.com; 1st approx:Ì client queries a 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 2: Application Layer 63
    • 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 a Verisign, Dulles, VA c Cogent, Herndon, VA (also LA) d U Maryland College Park, MD k RIPE London (also 16 other locations) g US DoD Vienna, VA h ARL Aberdeen, MD i Autonomica, Stockholm (plus j Verisign, ( 21 locations) 28 other locations)e NASA Mt View, CA m WIDE Tokyo (also Seoul,f Internet Software C. Palo Alto, Paris, SF)CA (and 36 other locations) 13 root name servers worldwide b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA 2: Application Layer 64
    • TLD and Authoritative ServersÌ Top-level domain (TLD) servers:  responsible for com, org, net, edu, etc, and all top-level country domains uk, fr, ca, jp.  Network Solutions maintains servers for com TLD  Educause for edu TLDÌ Authoritative DNS servers:  organization’s DNS servers, providing authoritative hostname to IP mappings for organization’s servers (e.g., Web, mail).  can be maintained by organization or service provider 2: Application Layer 66
    • Local 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  acts as proxy, forwards query into hierarchy 2: Application Layer 67
    • DNS name root DNS serverresolution example 2Ì Host at cis.poly.edu 3 TLD DNS server wants IP address for 4 gaia.cs.umass.edu 5 iterated query: local DNS server dns.poly.edu Ì contacted server 6 7 replies with name of 1 8 server to contact Ì “I don’t know this authoritative DNS server dns.cs.umass.edu name, but ask this requesting host server” cis.poly.edu gaia.cs.umass.edu 2: Application Layer 68
    • DNS nameresolution example root DNS serverrecursive query: 2 3Ì puts burden of name 7 6 resolution on TLD DNS server contacted name serverÌ heavy load? local DNS server dns.poly.edu 5 4 1 8 authoritative DNS server dns.cs.umass.edu requesting host cis.poly.edu gaia.cs.umass.edu 2: Application Layer 69
    • DNS: caching and updating recordsÌ once (any) name server learns mapping, it caches mapping  cache entries timeout (disappear) after some time  TLD servers typically cached in local name servers • Thus root name servers not often visitedÌ update/notify mechanisms under design by IETF  RFC 2136  http://www.ietf.org/html.charters/dnsind-charter.html 2: Application Layer 70
    • DNS recordsDNS: distributed db storing resource records (RR) RR format: (name, value, type, ttl)Ì Type=A Ì Type=CNAME  name is hostname  name is alias name for some  value is IP address “canonical” (the real) nameÌ Type=NS www.ibm.com is really servereast.backup2.ibm.com  name is domain (e.g.  value is canonical name foo.com)  value is hostname of Ì Type=MX authoritative name server  value is name of mailserver for this domain associated with name 2: Application Layer 71
    • DNS protocol, messagesDNS protocol : query and reply messages, both with same message formatmsg headerÌ identification: 16 bit # for query, reply to query uses same #Ì flags:  query or reply  recursion desired  recursion available  reply is authoritative 2: Application Layer 72
    • DNS protocol, messages Name, type fields for a query RRs in response to query records forauthoritative servers additional “helpful”info that may be used 2: Application Layer 73
    • 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,, A)Ì create authoritative server Type A record for www.networkuptopia.com; Type MX record for networkutopia.comÌ How do people get IP address of your Web site? 2: Application Layer 74
    • Pure P2P architectureÌ no always-on serverÌ arbitrary end systems directly communicate peer-peerÌ peers are intermittently connected and change IP addressesÌ Three topics:  File distribution  Searching for information – Case Study: Skype/Bit- torrent 2: Application Layer 75
    • File Distribution: Server-Client vs P2P Question : How much time to distribute file from one server to N peers? us: server upload Server bandwidth ui: peer i upload u1 d1 u2 bandwidth us d2 di: peer i downloadFile, size F bandwidth dN Network (with uN abundant bandwidth) 2: Application Layer 76
    • File distribution time: server-client ServerÌ server sequentially F u1 d1 u2 sends N copies: us d2  NF/us time dN Network (with abundant bandwidth)Ì client i takes F/di uN time to download Time to distribute F to N clients using = dcs = max { NF/us, F/min(di) } i client/server approach increases linearly in N (for large N) 2: Application Layer 77
    • File distribution time: P2P ServerÌ server must send one F u1 d1 u2 copy: F/us time us d2Ì client i takes F/di time Network (with dN to download abundant bandwidth) uNÌ NF bits must be downloaded (aggregate) Ì fastest possible upload rate: u + s Σ ui dP2P = max { F/us, F/min(di) , NF/(us + Σui) } i 2: Application Layer 78
    • Server-client vs. P2P: exampleClient upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us 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 2: Application Layer 79
    • Types of P2P ArchitecturesCentralized--E.g., NapsterPure--E.g., GnutellaHybrid--E.g., Bit-torrent
    • Key DifferencesCentralized-A server keeps track of location of files & corresponding peers-Peer only needs to contact the server to get the download location-Insecure due to single point of failurePure-No tracking of files-Queries are flooded throughout the network-Robust as there is no single point of failure
    • Key DifferencesHybrid-Overlay networks –logically connected nodes-Publish file locations on websites/blogs etc-A group of “trackers” maintain file locations(Bit-torrent for example)-Distributed Hash Tables are used for efficient searching of file locationsUseful Linkshttp://bittorrent.org/bittorrentecon.pdfhttp://dessent.net/btfaq/
    • File distribution: BitTorrentÌ P2P file distribution tracker: tracks peers torrent: group of participating in torrent peers exchanging chunks of a file obtain list of peers trading chunks peer 2: Application Layer 83
    • BitTorrent (1)Ì 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”)Ì while downloading, peer uploads chunks to other peers.Ì peers may come and goÌ once peer has entire file, it may (selfishly) leave or (altruistically) remain 2: Application Layer 84
    • BitTorrent (2) Sending Chunks: tit-for-tat Ì Alice sends chunks to fourPulling 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 Ì every 30 secs: randomly (Alice) asks each neighbor for list of select another peer, chunks that they have. starts sending chunks  newly chosen peer mayÌ Alice sends requests for her missing chunks join top 4  rarest first  “optimistically unchoke” 2: Application Layer 85
    • BitTorrent: Tit-for-tat(1) Alice “optimistically unchokes” Bob(2) Alice becomes one of Bob’s top-four providers; Bob reciprocates(3) Bob becomes one of Alice’s top-four providers With higher upload rate, can find better trading partners & get file faster! 2: Application Layer 86
    • 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) peers
    • DHT IdentifiersÌ Assign integer identifier to each peer in range [0,2n-1].  Each identifier can be represented by n bits.Ì Require each key to be an integer in same range.Ì To get integer keys, hash original key.  eg, key = h(“Led Zeppelin IV”)  This is why they call it a distributed “hash” table
    • How to assign keys to peers?Ì Central issue:  Assigning (key, value) pairs to peers.Ì Rule: assign key to the peer that has the closest ID.Ì Convention in lecture: closest is the immediate successor of the key.Ì Ex: n=4; peers: 1,3,4,5,8,10,12,14;  key = 13, then successor peer = 14  key = 15, then successor peer = 1
    • Circular DHT (1) 1 15 3 4 12 5 10 8Ì Each peer only aware of immediate successor and predecessor.Ì “Overlay network”
    • Circle DHT (2)O(N) messages 0001 Who’s respon avg to resolve for key 1110 ? I amquery, when there 0011are N peers 1111 1110 1110 0100 1110 1100 1110 1110 0101 Define closest 1110 as closest 1010 successor 1000
    • Circular DHT with Shortcuts 1 Who’s resp for key 1110? 3 15 4 12 5 10 8Ì Each peer keeps track of IP addresses of predecessor, successor, short cuts.Ì Reduced from 6 to 2 messages.Ì Possible to design shortcuts so O(log N) neighbors, O(log N) messages in query
    • Peer Churn 1 •To handle peer churn, require 3 each peer to know the IP address15 of its two successors. • Each peer periodically pings its 4 two successors to see if they12 are still alive. 5 10 8Ì Peer 5 abruptly leavesÌ Peer 4 detects; makes 8 its immediate successor; asks 8 who its immediate successor is; makes 8’s immediate successor its second successor.Ì What if peer 13 wants to join?
    • P2P Case study: Skype Skype clients (SC)Ì inherently P2P: pairs of users communicate.Ì proprietary Skype application-layer login server Supernode protocol (inferred via (SN) reverse engineering)Ì hierarchical overlay with SNsÌ Index maps usernames to IP addresses; distributed over SNs 2: Application Layer 94
    • Peers as relaysÌ Problem when both Alice and Bob are behind “NATs”.  NAT prevents an outside peer from initiating a call to insider peerÌ Solution:  Using Alice’s and Bob’s SNs, Relay is chosen  Each peer initiates session with relay.  Peers can now communicate through NATs via relay 2: Application Layer 95
    • Key Differences Re-visited-Client-Server architecture poor scaling for Server-Pure/Centralized P2P architecture good scaling but performs poorly when upload speeds of peer is bad (due to individual TCP connections-Hybrid/Torrents –advantage of both centralized/pure P2P by splitting files into multiple chunks and off-loading work to different peers (creating more sources)
    • Chapter 2: Summaryour study of network apps now complete!Ì application architectures Ì specific protocols:  client-server  HTTP  P2P  FTP  hybrid  SMTP, POP, IMAP  DNSÌ application service  P2P: BitTorrent, Skype requirements:  reliability, bandwidth, Ì socket programming delayÌ Internet transport service model  connection-oriented, reliable: TCP  unreliable, datagrams: UDP 2: Application Layer 97
    • Chapter 2: SummaryMost importantly: learned about protocolsÌ typical request/reply Important themes: message exchange: Ì control vs. data msgs  client requests info or  in-band, out-of-band service  server responds with Ì centralized vs. data, status code decentralizedÌ message formats: Ì stateless vs. stateful  headers: fields giving Ì reliable vs. unreliable info about data msg transfer  data: info being Ì “complexity at network communicated edge” 2: Application Layer 98