1 / 22

Chapter 2: Application layer

2.1 Principles of network applications 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS. 2.6 P2P applications 2.7 Socket programming with TCP 2.8 Socket programming with UDP 2.9 Building a Web server. Chapter 2: Application layer. People: many identifiers:

ulric-boyd
Télécharger la présentation

Chapter 2: Application layer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 2.1 Principles of network applications 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P applications 2.7 Socket programming with TCP 2.8 Socket programming with UDP 2.9 Building a Web server Chapter 2: Application layer 2: Application Layer

  2. People: many identifiers: SSN, name, passport # Internet hosts, routers: IP address (32 bit) - used for addressing datagrams “name”, e.g., ww.yahoo.com - used by humans Q: map between IP addresses and name ? Domain Name System: distributed database implemented in hierarchy of many name servers application-layer protocol host, routers, name servers to communicate to resolvenames (address/name translation) note: core Internet function, implemented as application-layer protocol complexity at network’s “edge” DNS: Domain Name System 2: Application Layer

  3. Why not centralize DNS? single point of failure traffic volume distant centralized database maintenance doesn’t scale! DNS services hostname to IP address translation host aliasing Canonical, alias names mail server aliasing load distribution replicated Web servers: set of IP addresses for one canonical name DNS 2: Application Layer

  4. Root DNS Servers org DNS servers edu DNS servers com DNS servers poly.edu DNS servers umass.edu DNS servers pbs.org DNS servers yahoo.com DNS servers amazon.com DNS servers Distributed, Hierarchical Database Client 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

  5. 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 DNS: Root name servers a Verisign, Dulles, VA c Cogent, Herndon, VA (also LA) d U Maryland College Park, MD g US DoD Vienna, VA h ARL Aberdeen, MD j Verisign, ( 21 locations) k RIPE London (also 16 other locations) i Autonomica, Stockholm (plus 28 other locations) m WIDE Tokyo (also Seoul, Paris, SF) e NASA Mt View, CA f Internet Software C. Palo Alto, 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

  6. 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

  7. 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

  8. Host at cis.poly.edu wants IP address for gaia.cs.umass.edu local DNS server dns.poly.edu DNS name resolution example root DNS server 2 3 TLD DNS server 4 5 • iterated query: • contacted server replies with name of server to contact • “I don’t know this name, but ask this server” 6 7 1 8 authoritative DNS server dns.cs.umass.edu requesting host cis.poly.edu gaia.cs.umass.edu 2: Application Layer

  9. root DNS server 2 3 6 7 TLD DNS server 4 local DNS server dns.poly.edu 5 1 8 authoritative DNS server dns.cs.umass.edu requesting host cis.poly.edu gaia.cs.umass.edu DNS name resolution example • recursive query: • puts burden of name resolution on contacted name server • heavy load? 2: Application Layer

  10. 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 DNS: caching and updating records 2: Application Layer

  11. DNS: distributed db storing resource records (RR) Type=NS name is domain (e.g. foo.com) value is hostname of authoritative name server for this domain RR format: (name, value, type, ttl) DNS records • Type=A • name is hostname • value is IP address • Type=CNAME • name is alias name for some “canonical” (the real) name www.ibm.com is really servereast.backup2.ibm.com • value is canonical name • Type=MX • value is name of mailserver associated with name 2: Application Layer

  12. DNS protocol :queryand reply messages, both with same message format DNS protocol, messages • msg 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

  13. DNS protocol, messages Name, type fields for a query RRs in response to query records for authoritative servers additional “helpful” info that may be used 2: Application Layer

  14. SIP: Session Initiation Protocol[RFC 3261] SIP long-term vision: • all telephone calls, video conference calls take place over Internet • people are identified by names or e-mail addresses, rather than by phone numbers • you can reach callee, no matter where callee roams, no matter what IP device callee is currently using Multimedia Networking

  15. Setting up a call, SIP provides mechanisms .. for caller to let callee know she wants to establish a call so caller, callee can agree on media type, encoding to end call determine current IP address of callee: maps mnemonic identifier to current IP address call management: add new media streams during call change encoding during call invite others transfer, hold calls SIP Services Multimedia Networking

  16. Setting up a call to known IP address • Alice’s SIP invite message indicates her port number, IP address, encoding she prefers to receive (PCM ulaw) • Bob’s 200 OK message indicates his port number, IP address, preferred encoding (GSM) • SIP messages can be sent over TCP or UDP; here sent over RTP/UDP. • default SIP port number is 5060. Multimedia Networking

  17. codec negotiation: suppose Bob doesn’t have PCM ulaw encoder. Bob will instead reply with 606 Not Acceptable Reply, listing his encoders Alice can then send new INVITE message, advertising different encoder rejecting a call Bob can reject with replies “busy,” “gone,” “payment required,” “forbidden” media can be sent over RTP or some other protocol Setting up a call (more) Multimedia Networking

  18. Example of SIP message INVITE sip:bob@domain.com SIP/2.0 Via: SIP/2.0/UDP 167.180.112.24 From: sip:alice@hereway.com To: sip:bob@domain.com Call-ID: a2e3a@pigeon.hereway.com Content-Type: application/sdp Content-Length: 885 c=IN IP4 167.180.112.24 m=audio 38060 RTP/AVP 0 Notes: • HTTP message syntax • sdp = session description protocol • Call-ID is unique for every call. • Here we don’t know Bob’s IP address. • intermediate SIPservers needed. • Alice sends, receives SIP messages using SIP default port 506 • Alice specifies in header that SIP client sends, receives SIP messages over UDP Multimedia Networking

  19. caller wants to call callee, but only has callee’s name or e-mail address. need to get IP address of callee’s current host: user moves around DHCP protocol user has different IP devices (PC, PDA, car device) result can be based on: time of day (work, home) caller (don’t want boss to call you at home) status of callee (calls sent to voicemail when callee is already talking to someone) Service provided by SIP servers: SIP registrar server SIP proxy server Name translation and user location Multimedia Networking

  20. SIP Registrar • when Bob starts SIP client, client sends SIP REGISTER message to Bob’s registrar server (similar function needed by Instant Messaging) REGISTER sip:domain.com SIP/2.0 Via: SIP/2.0/UDP 193.64.210.89 From: sip:bob@domain.com To: sip:bob@domain.com Expires: 3600 Register Message: Multimedia Networking

  21. SIP Proxy • Alice sends invite message to her proxy server • contains address sip:bob@domain.com • proxy responsible for routing SIP messages to callee • possibly through multiple proxies. • callee sends response back through the same set of proxies. • proxy returns SIP response message to Alice • contains Bob’s IP address • proxy analogous to local DNS server Multimedia Networking

  22. Example Caller jim@umass.edu with places a call to keith@upenn.edu (1) Jim sends INVITEmessage to umass SIPproxy. (2) Proxy forwardsrequest to upenn registrar server. (3) upenn server returnsredirect response,indicating that it should try keith@eurecom.fr (4) umass proxy sends INVITE to eurecom registrar. (5) eurecom registrar forwards INVITE to 197.87.54.21, which is running keith’s SIP client. (6-8) SIP response sent back (9) media sent directly between clients. Note: also a SIP ack message, which is not shown. Multimedia Networking

More Related