An Overview of Applications Xin Liu ECS 152

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

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

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

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

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, Ka. Za. A 5

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 6

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

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

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 m HTTP server: 80 Mail server: 25 9

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 10

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

Internet transport protocols services TCP service: r connection-oriented: setup r r required between client and server processes reliable transport between sending and receiving process flow control: sender won’t overwhelm receiver congestion control: throttle sender when network overloaded 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 12

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

An Example: Domain Name System Internet hosts, routers: m m IP address “name”, e. g. , bread. cs. ucdavis. edu r Map between IP addresses and name r Host aliasing: m m relay 1. west. abc. com is abc. com, www. abc. com Canonical hostname r Mail-server aliasing: r Load balancing r Different from app. , e. g. , web, email. 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” r used by other applications 14

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

DNS: Root name servers r contacted by local name server that can not resolve name r root name server: m m m contacts authoritative name server if name mapping not known gets mapping returns mapping to local name server 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 k RIPE London i NORDUnet Stockholm m WIDE Tokyo e NASA Mt View, CA f Internet Software C. Palo Alto, CA b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA 13 root name servers worldwide 16

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

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

DNS: iterated queries recursive query: 2 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” root name server iterated query 3 4 7 local name server dns. eurecom. fr 1 8 requesting host intermediate name server dns. ucdavis. edu 5 6 authoritative name server dns. cs. ucdavis. edu surf. eurecom. fr hi. cs. ucdavis. edu 19

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 20

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

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 22

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 23