3rd edition chapter2
Upcoming SlideShare
Loading in...5
×
 

3rd edition chapter2

on

  • 611 views

 

Statistics

Views

Total Views
611
Views on SlideShare
611
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

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.

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

3rd edition chapter2 3rd edition chapter2 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). Computer Networking: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 A Top Down Approachrepresent a lot of work on our part. In return for use, we only ask the Featuring the Internet,following: If you use these slides (e.g., in a class) in substantially unaltered form,that you mention their source (after all, we’d like people to use our book!) 3rd edition. 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, and Jim Kurose, Keith Rossnote our copyright of this material. Addison-Wesley, JulyThanks and enjoy! JFK/KWR 2004.All material copyright 1996-2005J.F Kurose and K.W. Ross, All Rights Reserved 2: Application Layer 1
  • Chapter 2: Application layerÌ 2.1 Principles of Ì 2.6 P2P file sharing 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 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 paradigm  socket API 2: Application Layer 3
  • Some network appsÌ E-mail Ì Internet telephoneÌ Web Ì Real-time videoÌ Instant messaging conferenceÌ Remote login Ì Massive parallelÌ P2P file sharing computing ÌÌ Multi-user network games ÌÌ Streaming stored Ì video clips 2: Application Layer 4
  • Creating a network appWrite programs that application transport  run on different end network data link systems and physical  communicate over a network.  e.g., Web: Web server software communicates with browser softwarelittle software written for devices in network core application application transport  network core devices do transport network network data link not run user application data link physical physical code  application on end systems allows for rapid app development, propagation 2: Application Layer 5
  • Chapter 2: Application layerÌ 2.1 Principles of Ì 2.6 P2P file sharing 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
  • Application architecturesÌ Client-serverÌ Peer-to-peer (P2P)Ì Hybrid of client-server and P2P 2: Application Layer 7
  • Client-server architecture server:  always-on host  permanent IP address  server farms for scaling clients:  communicate with server  may be intermittently connected  may have dynamic IP addresses  do not communicate directly with each other 2: Application Layer 8
  • Pure P2P architectureÌ no always-on serverÌ arbitrary end systems directly communicateÌ peers are intermittently connected and change IP addressesÌ example: GnutellaHighly scalableBut difficult to manage 2: Application Layer 9
  • Hybrid of client-server and P2PNapster  File transfer P2P  File search centralized: • Peers register content at central server • Peers query same central server to locate contentInstant messaging  Chatting between two users is P2P  Presence detection/location centralized: • 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 10
  • 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
  • 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 socket  sending process shoves 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 (lots more on this later) 2: Application Layer 12
  • Addressing processesÌ For a process to Ì Identifier includes receive messages, it both the IP address must have an identifier and port numbersÌ A host has a unique32- associated with the bit IP address process on the host.Ì Q: does the IP address Ì Example port numbers: of the host on which  HTTP server: 80 the process runs  Mail server: 25 suffice for identifying Ì More on this later the process?Ì Answer: No, many processes can be running on same host 2: Application Layer 13
  • App-layer protocol definesÌ Types of messages Public-domain protocols: exchanged, e.g., request Ì defined in RFCs & response messages Ì allows forÌ Syntax of message interoperability types: what fields in Ì e.g., HTTP, SMTP messages & how fields are delineated Proprietary protocols: Ì e.g., KaZaAÌ Semantics of the fields, i.e., meaning of information in fieldsÌ Rules for when and how processes send & respond to messages 2: Application Layer 14
  • What transport service does an app need?Data loss BandwidthÌ 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 bandwidth to be 100% reliable data “effective” transfer Ì other apps (“elasticTiming apps”) make use ofÌ some apps (e.g., whatever bandwidth Internet telephony, they get interactive games) require low delay to be “effective” 2: Application Layer 15
  • Transport service requirements of common apps Application Data loss Bandwidth 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, or bandwidth guaranteeÌ congestion control: throttle sender when network overloaded Q: why bother? Why isÌ does not provide: timing, there a UDP? minimum bandwidth guarantees 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 proprietary TCP or UDP (e.g. RealNetworks) Internet telephony proprietary (e.g., Vonage,Dialpad) typically UDP 2: Application Layer 18
  • Chapter 2: Application layerÌ 2.1 Principles of Ì 2.6 P2P file sharing 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 Ì 2.9 Building a Web  SMTP, POP3, IMAP serverÌ 2.5 DNS 2: Application Layer 19
  • 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 20
  • HTTP overviewHTTP: hypertext transfer protocol HT TP r equÌ Web’s application layer PC running HT e st TP protocol Explorer res pon seÌ client/server model  client: browser that st requests, receives, e que Pr on se Server “displays” Web objects TT p H P re s running T Apache Web  server: Web server HT server sends objects in response to requests Mac runningÌ HTTP 1.0: RFC 1945 NavigatorÌ HTTP 1.1: RFC 2068 2: Application Layer 21
  • 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 22
  • HTTP connectionsNonpersistent HTTP Persistent HTTPÌ At most one object is Ì Multiple objects can sent over a TCP be sent over single connection. TCP connectionÌ HTTP/1.0 uses between client and nonpersistent HTTP server. Ì HTTP/1.1 uses persistent connections in default mode 2: Application Layer 23
  • 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 24
  • 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 25
  • Response time modelingDefinition of RRT: time to send 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Ì one RTT for HTTP transmit file request and first few file received bytes of HTTP response to return time timeÌ file transmission timetotal = 2RTT+transmit time 2: Application Layer 26
  • Persistent HTTPNonpersistent HTTP issues: Persistent without pipelining:Ì requires 2 RTTs per object Ì client issues new requestÌ OS overhead for each TCP only when previous connection response has been receivedÌ browsers often open parallel Ì one RTT for each TCP connections to fetch referenced object referenced objects Persistent with pipelining:Persistent HTTP Ì default in HTTP/1.1Ì server leaves connection Ì client sends requests as open after sending response soon as it encounters aÌ subsequent HTTP messages referenced object between same client/server Ì as little as one RTT for all sent over open connection the referenced objects 2: Application Layer 27
  • 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 28
  • HTTP request message: general format 2: Application Layer 29
  • 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 30
  • 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 31
  • 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 32
  • 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 33
  • 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 34
  • Let’s look at HTTP in actionÌ telnet exampleÌ Ethereal example 2: Application Layer 35
  • User-server state: cookiesMany major Web sites Example: use cookies  Susan access InternetFour components: always from same PC  She visits a specific e- 1) cookie header line of commerce site for first HTTP response message time 2) cookie header line in  When initial HTTP HTTP request message requests arrives at site, 3) cookie file kept on site creates a unique ID user’s host, managed by and creates an entry in user’s browser backend database for 4) back-end database at ID Web site 2: Application Layer 36
  • Cookies: keeping “state” (cont.) client server Cookie file usual http request msg server n e da try i tab n b usual http response + creates ID as ac e ke ebay: 8734 Set-cookie: 1678 1678 for user nd Cookie file usual http request msg amazon: 1678 cookie: 1678 cookie- ss ebay: 8734 specific acce usual http response msg action ssone week later: ce ac usual http request msg Cookie file cookie- cookie: 1678 amazon: 1678 spectific ebay: 8734 usual http response msg action 2: Application Layer 37
  • 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 Ì search engines use (Web e-mail) redirection & cookies to learn yet more Ì advertising companies obtain info across sites 2: Application Layer 38
  • Web caches (proxy server)Goal: satisfy client request without involving origin serverÌ user sets browser: Web origin accesses via cache serverÌ browser sends all HTTP Proxy HT st TP requests to cache req server reque HT ues TP e object in cache: cache client TP t HT ons e sp  res returns object pon TPr se HT st  else cache requests ue eq se object from origin T Pr on HT p server, then returns P res HTT object to client client origin server 2: Application Layer 39
  • More about Web cachingÌ Cache acts as both client Why Web caching? and server Ì Reduce response time forÌ Typically cache is installed client request. by ISP (university, Ì Reduce traffic on an company, residential ISP) institution’s access link. Ì Internet dense with caches enables “poor” content providers to effectively deliver content (but so does P2P file sharing) 2: Application Layer 40
  • Caching example originAssumptions serversÌ average object size = 100,000 public bits InternetÌ avg. request rate from institution’s browsers to origin servers = 15/secÌ delay from institutional router 1.5 Mbps 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%Ì total delay = Internet delay + institutional access delay + LAN delay cache = 2 sec + minutes + milliseconds 2: Application Layer 41
  • Caching example (cont) originPossible solution serversÌ increase bandwidth of access public link to, say, 10 Mbps InternetConsequencesÌ 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
  • Caching example (cont) originInstall cache serversÌ suppose hit rate is .4 publicConsequence InternetÌ 40% requests will be satisfied almost immediatelyÌ 60% requests satisfied by origin server 1.5 Mbps access linkÌ utilization of access link reduced to 60%, resulting in institutional negligible delays (say 10 network 10 Mbps LAN msec)Ì total avg delay = Internet delay + access delay + LAN delay = .6*(2.01) secs + milliseconds < 1.4 secs institutional cache 2: Application Layer 43
  • 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 44
  • Chapter 2: Application layerÌ 2.1 Principles of Ì 2.6 P2P file sharing 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
  • FTP: the file transfer protocol FTP file transfer FTP FTP user client server interface user at host local file remote 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
  • FTP: separate control, data connections TCP control connectionÌ FTP client contacts FTP port 21 server at port 21, specifying TCP as transport protocol TCP data connectionÌ Client obtains authorization FTP port 20 FTP over control connection client serverÌ Client browses remote Ì Server opens a second TCP directory by sending commands over control data connection to transfer connection. another file. Ì Control connection: “out ofÌ When server receives a command for a file transfer, band” the server opens a TCP data Ì FTP server maintains “state”: connection to client current directory, earlierÌ After transferring one file, authentication server closes connection. 2: Application Layer 47
  • 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
  • Chapter 2: Application layerÌ 2.1 Principles of Ì 2.6 P2P file sharing 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 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 Netscape Messenger 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
  • Message format: multimedia extensions Ì MIME: multimedia mail extension, RFC 2045, 2056 Ì additional lines in msg header declare MIME content type From: alice@crepes.fr MIME version To: bob@hamburger.edu Subject: Picture of yummy crepe. method used MIME-Version: 1.0 to encode data Content-Transfer-Encoding: base64 Content-Type: image/jpeg multimedia data type, subtype, base64 encoded data .....parameter declaration ......................... ......base64 encoded data encoded data 2: Application Layer 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: Hotmail , Yahoo! Mail, etc. 2: Application Layer 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 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Ì POP3 is stateless message IDs and folder name across sessions 2: Application Layer 61
  • Chapter 2: Application layerÌ 2.1 Principles of Ì 2.6 P2P file sharing 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 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 63
  • DNSDNS services Why not centralize DNS?Ì Hostname to IP Ì single point of failure address translation Ì traffic volumeÌ Host aliasing Ì distant centralized  Canonical and alias database names Ì maintenanceÌ Mail server aliasingÌ Load distribution doesn’t scale!  Replicated Web servers: set of IP addresses for one canonical name 2: Application Layer 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 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 Los Angeles) d U Maryland College Park, MD k RIPE London (also Amsterdam, g US DoD Vienna, VA h ARL Aberdeen, MD i Frankfurt) Stockholm (plus 3 Autonomica, j Verisign, ( 11 locations) other locations) m WIDE Tokyoe NASA Mt View, CAf Internet Software C. Palo Alto,CA (and 17 other locations) 13 root name servers worldwide b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA 2: Application Layer 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 and mail).  Can be maintained by organization or service provider 2: Application Layer 67
  • Local Name ServerÌ Does not strictly belong to hierarchyÌ Each ISP (residential ISP, company, university) has one.  Also called “default name server”Ì When a host makes a DNS query, query is sent to its local DNS server  Acts as a proxy, forwards query into hierarchy. 2: Application Layer 68
  • Example root DNS server 2Ì Host at cis.poly.edu 3 TLD DNS server wants IP address for 4 gaia.cs.umass.edu 5 local DNS server dns.poly.edu 7 6 1 8 authoritative DNS server dns.cs.umass.edu requesting host cis.poly.edu gaia.cs.umass.edu 2: Application Layer 69
  • Recursive queries root DNS serverrecursive query: 2 3Ì puts burden of name resolution on 7 6 contacted name TLD DNS serve serverÌ heavy load? local DNS server 4iterated query: dns.poly.edu 5Ì contacted server 1 8 replies with name of server to contact authoritative DNS serverÌ “I don’t know this dns.cs.umass.edu requesting host name, but ask this cis.poly.edu server” gaia.cs.umass.edu 2: Application Layer 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 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 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 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 74
  • Inserting records into DNSÌ Example: just created startup “Network Utopia”Ì Register name networkuptopia.com at a registrar (e.g., Network Solutions)  Need to provide registrar with names and IP addresses of your authoritative name server (primary and secondary)  Registrar inserts two RRs into the com TLD server: (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, 212.212.212.1, A)Ì Put in authoritative server Type A record for www.networkuptopia.com and Type MX record for networkutopia.comÌ How do people get the IP address of your Web site? 2: Application Layer 75
  • Chapter 2: Application layerÌ 2.1 Principles of Ì 2.6 P2P file sharing 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 Ì 2.9 Building a Web  SMTP, POP3, IMAP serverÌ 2.5 DNS 2: Application Layer 76
  • P2P file sharing Ì Alice chooses one ofExample the peers, Bob.Ì Alice runs P2P client Ì File is copied from application on her Bob’s PC to Alice’s notebook computer notebook: HTTPÌ Intermittently Ì While Alice downloads, connects to Internet; other users uploading gets new IP address from Alice. for each connection Ì Alice’s peer is both aÌ Asks for “Hey Jude” Web client and a transient Web server.Ì Application displays other peers that have All peers are servers = copy of Hey Jude. highly scalable! 2: Application Layer 77
  • P2P: centralized directory Boboriginal “Napster” design centralized directory server1) when peer connects, it 1 informs central server: peers  IP address 1  content 1 32) Alice queries for “Hey 2 Jude” 13) Alice requests file from Bob Alice 2: Application Layer 78
  • P2P: problems with centralized directoryÌ Single point of failure file transfer isÌ Performance decentralized, but bottleneck locating content isÌ Copyright highly centralized infringement 2: Application Layer 79
  • Query flooding: GnutellaÌ fully distributed overlay network: graph  no central server Ì edge between peer XÌ public domain protocol and Y if there’s a TCPÌ many Gnutella clients connection implementing protocol Ì all active peers and edges is overlay net Ì Edge is not a physical link Ì Given peer will typically be connected with < 10 overlay neighbors 2: Application Layer 80
  • Gnutella: protocol File transfer:Ì Query message HTTPsent over existing TCPconnections QueryÌ peers forward QueryHitQuery message y QuÌ QueryHit er ery Qu Hi tsent over er y Qureverse Querypath QueryHitScalability: Qu er ylimited scopeflooding 2: Application Layer 81
  • Gnutella: Peer joining1. Joining peer X must find some other peer in Gnutella network: use list of candidate peers2. X sequentially attempts to make TCP with peers on list until connection setup with Y3. X sends Ping message to Y; Y forwards Ping message.4. All peers receiving Ping message respond with Pong message5. X receives many Pong messages. It can then setup additional TCP connectionsPeer leaving: see homework problem! 2: Application Layer 82
  • Exploiting heterogeneity: KaZaAÌ Each peer is either a group leader or assigned to a group leader.  TCP connection between peer and its group leader.  TCP connections between some pairs of group leaders.Ì Group leader tracks the content in all its o r d in a r y p e e r children. g r o u p - le a d e r p e e r n e ig h o r in g r e la tio n s h ip s in o v e r la y n e tw o r k 2: Application Layer 83
  • KaZaA: QueryingÌ Each file has a hash and a descriptorÌ Client sends keyword query to its group leaderÌ Group leader responds with matches:  For each match: metadata, hash, IP addressÌ If group leader forwards query to other group leaders, they respond with matchesÌ Client then selects files for downloading  HTTP requests using hash as identifier sent to peers holding desired file 2: Application Layer 84
  • KaZaA tricksÌ Limitations on simultaneous uploadsÌ Request queuingÌ Incentive prioritiesÌ Parallel downloading 2: Application Layer 85
  • Chapter 2: Application layerÌ 2.1 Principles of Ì 2.6 P2P file sharing 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 86
  • 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 87
  • 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 88
  • 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 89
  • Stream jargonÌ A stream is a sequence of characters that flow into or out of a process.Ì An input stream is attached to some input source for the process, e.g., keyboard or socket.Ì An output stream is attached to an output source, e.g., monitor or socket. 2: Application Layer 90
  • Socket programming with TCP keyboard monitorExample client-server app:1) client reads line from standard input (inFromUser inFromUser input stream stream) , sends to server via Client socket (outToServer Process process stream)2) server reads line from socket3) server converts line to uppercase, sends back to inFromServer outToServer output input client stream stream4) client reads, prints modified line from socket client TCP clientSocket socket (inFromServer stream) TCP socket to network from network 2: Application Layer 91
  • 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 92
  • 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 93
  • 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 94
  • 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 95
  • 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 96
  • Chapter 2: Application layerÌ 2.1 Principles of Ì 2.6 P2P file sharing 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 97
  • 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 98
  • Client/server socket interaction: UDPServer (running on hostid) Client create socket, port=x, for create socket, clientSocket = incoming request: DatagramSocket() serverSocket = DatagramSocket() Create, address (hostid, port=x, send datagram request using clientSocket read request from serverSocket write reply to serverSocket specifying client read reply from host address, clientSocket port number close clientSocket 2: Application Layer 99
  • Example: Java client (UDP) keyboard monitor inFromUser input stream Client Process Input: receives process packet (TCP Output: sends received “byte packet (TCP sent stream”) receivePacket sendPacket “byte stream”) UDP UDP packet packet client UDP clientSocket socket UDP socket to network from network 2: Application Layer 100
  • 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 101
  • 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 102
  • 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 103
  • 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 104
  • Chapter 2: Application layerÌ 2.1 Principles of Ì 2.6 P2P file sharing 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 Ì 2.9 Building a Web  SMTP, POP3, IMAP serverÌ 2.5 DNS 2: Application Layer 105
  • Building a simple Web serverÌ handles one HTTP Ì after creating server, request you can request fileÌ accepts the request using a browser (e.g., IE explorer)Ì parses header Ì see text for detailsÌ obtains requested file from server’s file systemÌ creates HTTP response message:  header lines + fileÌ sends response to client 2: Application Layer 106
  • 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 requirements: Ì socket programming  reliability, bandwidth, delayÌ Internet transport service model  connection-oriented, reliable: TCP  unreliable, datagrams: UDP 2: Application Layer 107
  • Chapter 2: SummaryMost importantly: learned about protocolsÌ typical request/reply Ì control vs. data msgs message exchange:  in-band, out-of-band  client requests info or service Ì centralized vs. decentralized  server responds with Ì stateless vs. stateful data, status code Ì reliable vs. unreliable msg transferÌ message formats: Ì “complexity at network  headers: fields giving edge” info about data  data: info being communicated 2: Application Layer 108