1. 1 An Overview of Applications Xin Liu ECS 152A Ref: slides by J. Kurose and K. Ross

2. 2 Application architecture r Client-server architecture m Servers always on m With fixed address m Server farm r P2P architecture m Scalability m Difficult to manage r Hybrid m Napster m Instant messaging Register to central server Chatting in a p2p fashion

3. 3 Network applications: some review Process: program running within a host. r within same host, two processes communicate using interprocess communication (defined by OS). r processes running in different hosts communicate with an application-layer protocol user agent: interfaces with user “above” and network “below”. r implements user interface & application-level protocol m Web: browser m E-mail: mail reader m streaming audio/video: media player Q: software needed for network core?

4. 4 Applications and application-layer protocols Application: communicating, distributed processes m e.g., e-mail, Web, P2P file sharing, instant messaging m running in end systems (hosts) m exchange messages to implement application Application-layer protocols m one “piece” of an app m define messages exchanged by apps and actions taken m use communication services provided by lower layer protocols (TCP, UDP) application transport network data link physical application transport network data link physical application transport network data link physical

5. 5 App-layer protocol defines r Types of messages exchanged, eg, request & response messages r Syntax of message types: what fields in messages & how fields are delineated r Semantics of the fields, ie, meaning of information in fields r Rules for when and how processes send & respond to messages Public-domain protocols: r defined in RFCs r allows for interoperability r eg, HTTP, SMTP Proprietary protocols: r eg, KaZaA

6. 6 Components of Network App. r Application-layer protocol is one piece r Web is an application m HTTP protocol m HTML standard for document formats m Web browsers (Navigator, firefox, IE) m Web servers (e.g., Apache, microsoft servers) r E-mail m SMTP protocol m Mail servers, mail readers

7. 7 Client-server paradigm Typical network app has two pieces: client and server application transport network data link physical application transport network data link physical Client: r initiates contact with server (“speaks first”) r typically requests service from server, r Web: client implemented in browser; e-mail: in mail reader request reply Server: r provides requested service to client r e.g., Web server sends requested Web page, mail server delivers e-mail

8. 8 Processes communicating across network r process sends/receives messages to/from its socket r socket analogous to door m sending process shoves message out door m sending process assumes transport infrastructure on other side of door which brings message to socket at receiving process r Can choose the transport layer protocol process TCP with buffers, variables socket host or server process TCP with buffers, variables socket host or server Internet controlled by OS controlled by app developer

9. 9 Addressing processes: r For a process to receive messages, it must have an identifier r Every host has a unique 32-bit IP address r Example port numbers: m HTTP server: 80 m Mail server: 25

10. 10 What transport service does an app need? Data loss r some apps (e.g., audio) can tolerate some loss r other apps (e.g., file transfer, telnet) require 100% reliable data transfer Timing r some apps (e.g., Internet telephony, interactive games) require low delay to be “effective” Bandwidth r some apps (e.g., multimedia) require minimum amount of bandwidth to be “effective” r other apps (“elastic apps”) make use of whatever bandwidth they get

11. 11 Transport service requirements of common apps Application file transfer e-mail Web documents real-time audio/video stored audio/video interactive games instant messaging Data loss no loss loss-tolerant no loss Bandwidth elastic audio: 5kbps-1Mbps video:10kbps-5Mbps same as above few kbps up elastic Time Sensitive no yes, 100’s msec yes, few secs yes, 100’s msec yes and no

12. 12 Internet transport protocols services TCP service: r connection-oriented: setup required between client and server processes r reliable transport between sending and receiving process r flow control: sender won’t overwhelm receiver r congestion control: throttle sender when network overloaded r does not providing: timing, minimum bandwidth guarantees UDP service: r unreliable data transfer between sending and receiving process r does not provide: connection setup, reliability, flow control, congestion control, timing, or bandwidth guarantee

13. 13 Internet apps: application, transport protocols Application e-mail remote terminal access Web file transfer streaming multimedia Internet telephony Application layer protocol SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] proprietary (e.g. RealNetworks) proprietary (e.g., Dialpad) Underlying transport protocol TCP TCP or UDP typically UDP

14. 14 An Example: Domain Name System Internet hosts, routers: m IP address m “name”, e.g., bread.cs.ucdavis.edu r Map between IP addresses and name r Host aliasing: m relay1.west.abc.com is abc.com, www.abc.com m Canonical hostname r Mail-server aliasing: r Load balancing r Different from app., e.g., web, email. r used by other applications Domain Name System: r distributed database implemented in hierarchy of many name servers r application-layer protocol host, routers, name servers to communicate to resolve names (address/name translation) m note: core Internet function, implemented as application-layer protocol m complexity at network’s “edge”

15. 15 DNS name servers r no server has all name- to-IP address mappings r Distributed, hierarchical local name servers: m each ISP, company has local (default) name server m host DNS query first goes to local name server authoritative name server: m for a host: stores that host’s IP address, name m can perform name/address translation for that host’s name Why not centralize DNS? r single point of failure r traffic volume r distant centralized database r maintenance doesn’t scale! Use UDP, port 53

16. 16 DNS: Root name servers r contacted by local name server that can not resolve name r root name server: m contacts authoritative name server if name mapping not known m gets mapping m returns mapping to local name server b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA e NASA Mt View, CA f Internet Software C. Palo Alto, CA i NORDUnet Stockholm k RIPE London m WIDE Tokyo a NSI Herndon, VA c PSInet Herndon, VA d U Maryland College Park, MD g DISA Vienna, VA h ARL Aberdeen, MD j NSI (TBD) Herndon, VA 13 root name servers worldwide

17. 17 Simple DNS example host surf.eurecom.fr wants IP address of hi.cs.ucdavis.edu 1. contacts its local DNS server, dns.eurecom.fr 2. dns.eurecom.fr contacts root name server, if necessary 3. root name server contacts authoritative name server, dns.ucdavis.edu, if necessary requesting host surf.eurecom.fr hi.cs.ucdavis.edu root name server authorititive name server dns.ucdavis.edu local name server dns.eurecom.fr 1 2 3 4 5 6

18. 18 DNS example Root name server: r may not know authoritative name server r may know intermediate name server: who to contact to find authoritative name server requesting host surf.eurecom.fr hi.cs.ucdavis.edu root name server local name server dns.eurecom.fr 1 2 3 4 5 6 authoritative name server dns.cs.ucdavis.edu intermediate name server dns.ucdavis.edu 7 8

19. 19 DNS: iterated queries recursive query: r puts burden of name resolution on contacted name server r heavy load? iterated query: r contacted server replies with name of server to contact r “I don’t know this name, but ask this server” requesting host surf.eurecom.fr hi.cs.ucdavis.edu root name server local name server dns.eurecom.fr 1 2 3 4 5 6 authoritative name server dns.cs.ucdavis.edu intermediate name server dns.ucdavis.edu 7 8 iterated query

20. 20 DNS: caching and updating records r once (any) name server learns mapping, it caches mapping m cache entries timeout (disappear) after some time r update/notify mechanisms under design by IETF m RFC 2136 m http://www.ietf.org/html.charters/dnsind-charter.html

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

22. 22 DNS protocol, messages DNS protocol : query and reply messages, both with same message format msg header r identification: 16 bit # for query, reply to query uses same # r flags: m query or reply m recursion desired m recursion available m reply is authoritative

23. 23 DNS protocol, messages Name, type fields for a query RRs in reponse to query records for authoritative servers additional “helpful” info that may be used