Your SlideShare is downloading. ×
  • Like
Chapter2 application
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Chapter2 application

  • 292 views
Published

 

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
292
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
8
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 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
  • 2. 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
  • 3. Chapter 2: Application LayerOur goals: learn about protocols Conceptual(khái by examining popular niệm),implementation( application-level sự thi hành) aspects protocols (khía cạnh)ofnetwork  HTTP application protocols  FTP  transport-layer  SMTP / POP3 / IMAP servicemodels(kiểu)  DNS  client-server programming network paradigm(hệ biến applications hoá)  socket API  peer-to-peer paradigm 2: Application Layer 3
  • 4. 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
  • 5. 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
  • 6. 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.9 Building a Web 2.5 DNS server 2: Application Layer 6
  • 7. Application architectures Client-server Peer-to-peer (P2P) Hybrid of client-server and P2P 2: Application Layer 7
  • 8. Client-server architecture server:  always-on host  permanent IP address  server farms for scaling clients:client/server  communicate with server  may be intermittently (không liên tục)connected  may have dynamic IP addresses  do not communicate directly with each other 2: Application Layer 8
  • 9. Pure P2P architecture no always-on server Arbitrary(bất kỳ) end systems directly peer-peer communicate peers are intermittently connected and change IP addressesHighly scalable(có thể thay đổi được ) but difficult to manage 2: Application Layer 9
  • 10. Hybrid of client-server and P2PSkype  voice-over-IP P2P application  centralized server: finding address of remote party(thuê bao):  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(bạn thân) 2: Application Layer 10
  • 11. 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). processes in different Note: applications with hosts communicate by P2P architectures have exchanging messages client processes & server processes 2: Application Layer 11
  • 12. Socketsprocess sends/receives host or host ormessages to/from its server serversocket controlled bysocket analogous(tương process app developer processtự) to door socket socket sending process shoves TCP with TCP with (đẩy)message out door 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 processAPI: (1) choice of transport protocol; (2) ability to fixa few parameters (lots more on this later) 2: Application Layer 12
  • 13. 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 13
  • 14. Addressing processes to receive messages, identifier includes both process must have IP address and port identifier numbers (chữ số để xác host device has unique định port)associated 32-bit IP address with process on host. Q: does IP address of Example port numbers: host on which process  HTTP server: 80 runs suffice for  Mail server: 25 identifying the to send HTTP message process? to gaia.cs.umass.edu web  A: No, many server: processes can be  IP address: 128.119.245.12 running on same host  Port number: 80 more shortly… 2: Application Layer 14
  • 15. App-layer protocol defines Types of messages Public-domain protocols: exchanged, defined in RFCs  e.g., request, response allows for Message syntax(cú pháp): interoperability(sự  what fields in messages & tương kết) how fields are delineated(mô tả,) e.g., HTTP, SMTP Message semantics Proprietary(cá nhân) (semantics) protocols:  meaning of information in e.g., Skype fields Rules for when and how processes send & respond to messages 2: Application Layer 15
  • 16. 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 “effective” integrity(tính toàn vẹn), … 2: Application Layer 16
  • 17. 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 17
  • 18. 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 (làm tràn) receiver congestion control, timing, throughput guarantee, or congestion (tắc security nghẽn)control: throttle(tiết lưu) sender when network overloaded Q: why bother? Why is does not provide: timing, there a UDP? minimum throughput guarantees, security 2: Application Layer 18
  • 19. 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 19
  • 20. Chapter 2: Application layer 2.1 Principles of 2.6 P2P applications network applications 2.7 Socket programming  app architectures with TCP app requirements 2.8 Socket programming  2.2 Web and HTTP with UDP 2.4 Electronic Mail  SMTP, POP3, IMAP 2.5 DNS 2: Application Layer 20
  • 21. 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 21
  • 22. HTTP overviewHTTP: hypertext(siêu văn bản) transfer HT TP r equ protocol PC running HT TP est Explorer res Web’s application layer pon se protocol client/server model st ue  client: browser that eq TPr on se Server requests, receives, HT res p running TP Apache Web “displays” Web objects HT server  server: Web server sends objects in Mac running response to requests Navigator 2: Application Layer 22
  • 23. 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 “state” HTTP messages (application- are complex! layer protocol messages) past history (state) must be exchanged between browser maintained (HTTP client) and Web if server/client crashes(bị server (HTTP server) hỏng), their views of “state” TCP connection closed may be inconsistent(không vững ), must be reconciled(điều hòa) 2: Application Layer 23
  • 24. 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 24
  • 25. 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 25
  • 26. 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 26
  • 27. 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 27
  • 28. 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 28
  • 29. 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 29
  • 30. HTTP request message: general format 2: Application Layer 30
  • 31. 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 31
  • 32. 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 32
  • 33. 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 33
  • 34. 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 34
  • 35. 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 2: Application Layer 35
  • 36. 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 36
  • 37. 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 37
  • 38. Cookies (continued) asideWhat cookies can bring: Cookies and privacy: authorization cookies permit sites to shopping carts learn a lot about you recommendations you may supply name 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 38
  • 39. Web caches (proxy server)Goal: satisfy client request without involving origin server user sets browser: origin server Web accesses via t es cache Proxy qu re browser sends all server P TT clientHTTP on s e H HTTP requests to re HTTPsrequest esp pon Pr se HTT cache t es se qu on object in cache: cache re  sp TP returns object re HT TP  else cache requests HT object from origin client origin server, then returns server object to client 2: Application Layer 39
  • 40. 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 40
  • 41. 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 41
  • 42. 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 42
  • 43. 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 43
  • 44. Conditional GETGoal: don’t send object if cache servercache has up-to-date cached HTTP request msgversion If-modified-since: objectcache: specify date of <date> notcached copy in HTTP request modified HTTP responseIf-modified-since: HTTP/1.0 <date> 304 Not Modifiedserver: response contains noobject if cached copy is up- HTTP request msgto-date: If-modified-since:HTTP/1.0 304 Not <date> object Modified modified HTTP response HTTP/1.0 200 OK <data> 2: Application Layer 44
  • 45. 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.9 Building a Web 2.5 DNS server 2: Application Layer 45
  • 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 46
  • 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 file) to client FTP server maintains “state”: current directory, earlier after transferring one file, authentication server closes data connection. 2: Application Layer 47
  • 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 48
  • 49. 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 49
  • 50. Electronic Mail outgoing message queue user mailbox userThree major components: agent user agents mail user server mail servers agent simple mail transfer SMTP mail protocol: SMTP server user SMTP agentUser Agent a.k.a. “mail reader” SMTP mail user composing, editing, reading server agent mail messages e.g., Eudora, Outlook, elm, user Mozilla Thunderbird agent user outgoing, incoming messages agent stored on server 2: Application Layer 50
  • 51. 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
  • 52. 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
  • 53. 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
  • 54. 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
  • 55. 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
  • 56. SMTP: final words SMTP uses persistent Comparison with HTTP: connections HTTP: pull SMTP requires message (header & body) to be in 7- SMTP: push 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
  • 57. 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
  • 58. 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
  • 59. 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
  • 60. 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 message IDs and folder POP3 is stateless name across sessions 2: Application Layer 60
  • 61. 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.9 Building a Web 2.5 DNS server 2: Application Layer 61
  • 62. 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 62
  • 63. 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 63
  • 64. 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 64
  • 65. 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 65
  • 66. 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
  • 67. 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
  • 68. 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 5iterated query: local DNS server dns.poly.edu contacted server 7 6 replies with name of 1 8 server to contact authoritative DNS server “I don’t know this dns.cs.umass.edu name, but ask this requesting host server” cis.poly.edu gaia.cs.umass.edu 2: Application Layer 68
  • 69. DNS nameresolution example root DNS serverrecursive query: 2 3 puts burden of name 6 7 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
  • 70. 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
  • 71. 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 www.ibm.com is really Type=NS servereast.backup2.ibm.com  name is domain (e.g.  value is canonical name foo.com)  value is hostname of Type=MX authoritative name  value is name of mailserver server for this domain associated with name 2: Application Layer 71
  • 72. 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
  • 73. 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
  • 74. 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 How do people get IP address of your Web site? 2: Application Layer 74
  • 75. Chapter 2: Application layer 2.1 Principles of 2.6 P2P applications network applications 2.7 Socket programming  app architectures with TCP app requirements 2.8 Socket programming  2.2 Web and HTTP with UDP 2.4 Electronic Mail  SMTP, POP3, IMAP 2.5 DNS 2: Application Layer 75
  • 76. 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 2: Application Layer 76
  • 77. 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 77
  • 78. 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 = max { NF/us, F/min(di) } = dcs i client/server approach increases linearly in N (for large N) 2: Application Layer 78
  • 79. 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 dN Network (with to download abundant bandwidth) uN NF bits must be downloaded (aggregate) fastest possible upload rate: us + Σui dP2P = max { F/us, F/min(di) , NF/(us + Σui) } i 2: Application Layer 79
  • 80. 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 80
  • 81. 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 81
  • 82. 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 82
  • 83. BitTorrent (2) Sending Chunks: tit-for-tatPulling Chunks Alice sends chunks to four neighbors currently at any given time, sending her chunks at the different peers have highest rate different subsets of  re-evaluate top 4 every file chunks 10 secs periodically, a peer (Alice) asks each every 30 secs: randomly neighbor for list of select another peer, chunks that they have. starts sending chunks  newly chosen peer may Alice sends requests for her missing chunks join top 4  “optimistically unchoke”  rarest first 2: Application Layer 83
  • 84. 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 84
  • 85. 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
  • 86. 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
  • 87. 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
  • 88. Circular DHT (1) 1 3 15 4 12 5 10 8 Each peer only aware of immediate successor and predecessor. “Overlay network”
  • 89. 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
  • 90. Circular DHT with Shortcuts 12 15 Who’s resp for key 1110? 10 8 1 3 5 4 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
  • 91. 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?
  • 92. 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 92
  • 93. 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 93
  • 94. 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 94
  • 95. Socket programmingGoal: learn how to build client/server application that communicate using socketsSocket API socket introduced in BSD4.1 UNIX, a host-local, 1981 application-created, explicitly created, used, OS-controlled interface released by apps (a “door”) into which client/server paradigm application process can two types of transport both send and service via socket API: receive messages to/from  unreliable datagram another application process  reliable, byte stream- oriented 2: Application Layer 95
  • 96. Socket-programming using TCP Socket: a door between application process and end- end-transport protocol (UCP or TCP) TCP service: reliable transfer of bytes from one process to another controlled bycontrolled by process application application process developer developer socket socket TCP with TCP with controlled bycontrolled by buffers, operating operating buffers, internet system system variables variables host or host or server server 2: Application Layer 96
  • 97. Socket programming with TCPClient must contact server When contacted by client, server process must first server TCP creates new be running socket for server process to server must have created communicate with client socket (door) that  allows server to talk with welcomes client’s contact multiple clients  source port numbersClient contacts server by: used to distinguish creating client-local TCP clients (more in Chap 3) socket specifying IP address, port application viewpoint number of server process TCP provides reliable, in-order When client creates transfer of bytes (“pipe”) socket: client TCP between client and server establishes connection to server TCP 2: Application Layer 97
  • 98. Client/server socket interaction: TCPServer (running on hostid) Client create socket, port=x, for incoming request: welcomeSocket = ServerSocket() TCP create socket, wait for incoming connection request connection setup connect to hostid, port=x connectionSocket = clientSocket = welcomeSocket.accept() Socket() send request using read request from clientSocket connectionSocket write reply to connectionSocket read reply from clientSocket close connectionSocket close clientSocket 2: Application Layer 98
  • 99. Stream jargon keyboard monitorA stream is a sequence ofcharacters that flow intoor out of a process. inFromUser input streamAn input stream is Clientattached to some input Process processsource for the process,e.g., keyboard or socket.An output stream isattached to an output inFromServer outToServer output inputsource, e.g., monitor or stream streamsocket. client TCP clientSocket socket TCP socket to network from network 2: Application Layer 99
  • 100. Socket programming with TCPExample client-server app:1) client reads line from standard input (inFromUser stream) , sends to server via socket (outToServer stream)2) server reads line from socket3) server converts line to uppercase, sends back to client4) client reads, prints modified line from socket (inFromServer stream) 2: Application Layer 100
  • 101. Example: Java client (TCP) import java.io.*; import java.net.*; class TCPClient { public static void main(String argv[]) throws Exception { String sentence; String modifiedSentence; Create input stream BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); Create client socket, Socket clientSocket = new Socket("hostname", 6789); connect to server Create DataOutputStream outToServer = output stream new DataOutputStream(clientSocket.getOutputStream());attached to socket 2: Application Layer 101
  • 102. Example: Java client (TCP), cont. Create BufferedReader inFromServer = input stream new BufferedReader(newattached to socket InputStreamReader(clientSocket.getInputStream())); sentence = inFromUser.readLine(); Send line to server outToServer.writeBytes(sentence + n); Read line modifiedSentence = inFromServer.readLine(); from server System.out.println("FROM SERVER: " + modifiedSentence); clientSocket.close(); } } 2: Application Layer 102
  • 103. Example: Java server (TCP) import java.io.*; import java.net.*; class TCPServer { public static void main(String argv[]) throws Exception { String clientSentence; Create String capitalizedSentence; welcoming socket ServerSocket welcomeSocket = new ServerSocket(6789); at port 6789 while(true) {Wait, on welcomingsocket for contact Socket connectionSocket = welcomeSocket.accept(); by client BufferedReader inFromClient = Create input new BufferedReader(newstream, attached InputStreamReader(connectionSocket.getInputStream())); to socket 2: Application Layer 103
  • 104. Example: Java server (TCP), cont Create outputstream, attached DataOutputStream outToClient = to socket new DataOutputStream(connectionSocket.getOutputStream()); Read in line from socket clientSentence = inFromClient.readLine(); capitalizedSentence = clientSentence.toUpperCase() + n; Write out line outToClient.writeBytes(capitalizedSentence); to socket } } } End of while loop, loop back and wait for another client connection 2: Application Layer 104
  • 105. 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 105
  • 106. Socket programming with UDPUDP: no “connection” between client and server no handshaking sender explicitly attaches application viewpoint IP address and port of destination to each packet UDP provides unreliable transfer of groups of bytes (“datagrams”) server must extract IP between client and server address, port of sender from received packetUDP: transmitted data may be received out of order, or lost 2: Application Layer 106
  • 107. Client/server socket interaction: UDPServer (running on hostid) Client create socket, create socket, port= x. clientSocket = serverSocket = DatagramSocket() DatagramSocket() Create datagram with server IP and port=x; send datagram via read datagram from clientSocket serverSocket write reply to serverSocket specifying read datagram from client address, clientSocket port number close clientSocket 2: Application Layer 107
  • 108. Example: Java client (UDP) keyboard monitor inFromUser input stream Client Process Input: receives process packet (recall Output: sends thatTCP received packet (recall “byte stream”) receivePacket sendPacket that TCP sent UDP packet UDP packet “byte stream”) client UDP clientSocket socket UDP socket to network from network 2: Application Layer 108
  • 109. Example: Java client (UDP) import java.io.*; import java.net.*; class UDPClient { public static void main(String args[]) throws Exception { Create input stream BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); Create client socket DatagramSocket clientSocket = new DatagramSocket(); Translate InetAddress IPAddress = InetAddress.getByName("hostname"); hostname to IPaddress using DNS byte[] sendData = new byte[1024]; byte[] receiveData = new byte[1024]; String sentence = inFromUser.readLine(); sendData = sentence.getBytes(); 2: Application Layer 109
  • 110. Example: Java client (UDP), cont. Create datagram with data-to-send, DatagramPacket sendPacket =length, IP addr, port new DatagramPacket(sendData, sendData.length, IPAddress, 9876); Send datagram clientSocket.send(sendPacket); to server DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); Read datagram clientSocket.receive(receivePacket); from server String modifiedSentence = new String(receivePacket.getData()); System.out.println("FROM SERVER:" + modifiedSentence); clientSocket.close(); } } 2: Application Layer 110
  • 111. Example: Java server (UDP) import java.io.*; import java.net.*; class UDPServer { public static void main(String args[]) throws Exception Create { datagram socket DatagramSocket serverSocket = new DatagramSocket(9876); at port 9876 byte[] receiveData = new byte[1024]; byte[] sendData = new byte[1024]; while(true) { Create space for DatagramPacket receivePacket =received datagram new DatagramPacket(receiveData, receiveData.length); Receive serverSocket.receive(receivePacket); datagram 2: Application Layer 111
  • 112. Example: Java server (UDP), cont String sentence = new String(receivePacket.getData()); Get IP addr InetAddress IPAddress = receivePacket.getAddress(); port #, of sender int port = receivePacket.getPort(); String capitalizedSentence = sentence.toUpperCase(); sendData = capitalizedSentence.getBytes();Create datagram DatagramPacket sendPacket =to send to client new DatagramPacket(sendData, sendData.length, IPAddress, port); Write out datagram serverSocket.send(sendPacket); to socket } } } End of while loop, loop back and wait for another datagram 2: Application Layer 112
  • 113. Chapter 2: Summaryour study of network apps now complete! application architectures specific protocols:  HTTP  client-server  FTP  P2P  SMTP, POP, IMAP  hybrid  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 113
  • 114. 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 communicated “complexity at network edge” 2: Application Layer 114