Chapter 2 Application Layer Computer Networking A Top

Chapter 2 Application Layer Computer Networking: A Top Down Approach, Jim Kurose, Keith Ross Addison-Wesley. 2: Application Layer 1

Chapter 2: Application layer r 2. 1 Principles of network applications r 2. 2 Web and HTTP r 2. 3 FTP r 2. 4 Electronic Mail v r 2. 6 P 2 P Applications r 2. 7 Socket programming with TCP r 2. 8 Socket programming with UDP SMTP, POP 3, IMAP r 2. 5 DNS 2: Application Layer 2

Chapter 2: Application Layer Our goals: r conceptual, architectural aspects of network application protocols v transport-layer service models v client-server paradigm v peer-to-peer paradigm r learn about protocols v HTTP v FTP v SMTP / POP 3 / IMAP v DNS 2: Application Layer 3

Some network apps r e-mail r web r instant messaging r remote login r P 2 P file sharing r multi-user network r voice over IP r real-time video conferencing r grid computing r … r games r r streaming stored video clips Note: different applications may have different - Requirements (delay, loss, Tput, jitter bounds, security) - Number of participants (unicast, multicast, broadcast, manycast, profilecast) - Architecture (client-server, p 2 p, flat, hierarchical, hybrid, self-configuring) 2: Application Layer 4

Creating a network app Application programs v v run on end systems communicate over network little software written for devices in network core v v application transport network data link physical network core devices do not run user applications on end systems allows for rapid app development, propagation application transport network data link physical 2: Application Layer 5

Application architectures r Client-server r Peer-to-peer (P 2 P) r Hybrid of client-server and P 2 P 2: Application Layer 6

Client-server architecture server: v always-on host v permanent IP address v server farms for scaling Clients (in general): v client/server v v v communicate with server intermittently connected have dynamic IP addresses do not communicate directly with each other 2: Application Layer 7

Pure P 2 P architecture r No ‘always-on’ server r arbitrary end systems directly communicate peer-peer r peers intermittently connected & change IP addresses r example: Gnutella Highly scalable but difficult to manage 2: Application Layer 8

Hybrid of client-server and P 2 P Skype v voice-over-IP P 2 P application v centralized server: finding address of remote party v client-client connection: direct (not through server) Instant messaging v chatting between two users is P 2 P v centralized service: client detection & location • user registers IP address with central server • uses central server to find addresses of buddies 2: Application Layer 9

Processes communicating Process: program running within a host. r within same host, two processes communicate using inter-process communication (defined by OS). r processes in different hosts communicate by exchanging messages Client process: process that initiates communication Server process: process that waits to be contacted r Note: applications with P 2 P architectures have client processes & server processes 2: Application Layer 10

Sockets r process sends/receives messages to/from its socket host or server process controlled by app developer process socket TCP with buffers, variables Internet TCP with buffers, variables controlled by OS r API: (1) choice of transport protocol; (2) ability to fix a few parameters (more on this later) 2: Application Layer 11

Addressing processes r Q: does IP address of host on which process runs suffice for identifying the process? v A: No, many processes can runn on same host r identifier includes IP address & port numbers associated with process on host. r Example port numbers: v v HTTP server: 80 Mail server: 25 r to send HTTP message to gaia. cs. umass. edu web server: v IP address: 128. 119. 245. 12 v Port number: 80 r more later… 2: Application Layer 12

What transport service does an app need? Data loss r some apps (e. g. , audio) can tolerate some loss (~10%) r others (e. g. , FTP, telnet) require 100% delivery Timing r some apps (e. g. , Vo. IP, interactive games) require low (bounded) delay (and/or jitter) to be “effective” v Example: Vo. IP jitter or handoff delay bound is ~200 ms r others (e. g. , FTP) are tolerant to some delay/jitter v Some multimedia apps use buffering & playback point adjustment 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 2: Application Layer 13

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 2: Application Layer 14

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 provide: timing, minimum bandwidth guarantees, multicast support UDP service: r - 2: Application Layer 15

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. , Vonage, Dialpad) TCP TCP TCP or UDP typically UDP 2: Application Layer 16

Chapter 2: Application layer r 2. 1 Principles of network applications v v app architectures app requirements r 2. 2 Web and HTTP r 2. 4 Electronic Mail v SMTP, POP 3, IMAP r 2. 6 P 2 P file sharing r 2. 7 Socket programming with TCP r 2. 8 Socket programming with UDP r 2. 5 DNS 2: Application Layer 17

HTTP overview HTTP: hypertext transfer protocol r client/server model client: browser to request & receive Web objects v server: Web server sends objects in response to requests r HTTP 1. 0: RFC 1945 r HTTP 1. 1: RFC 2068 (persistent TCP) v HT TP req ues PC running HT t TP res Explorer pon se st P TT H ue eq r r TP HT e n spo se Server running Apache Web server Mac running Fire. Fox 2: Application Layer 18

HTTP overview (continued) Uses TCP: r 1. client initiates TCP connection to server, port 80 r 2. server accepts TCP connection from client r 3. HTTP (application-layer) messages exchanged between HTTP client and HTTP server r 4. TCP connection closed A ‘state’ is information kept in memory of a host, server or router to reflect past events: such as routing tables, data structures or database entries HTTP is “stateless” r server maintains no information about past client requests Protocols that maintain “state” are complex! r history (state) is maintained r if server/client crashes, views of “state” may be inconsistent, must be reconciled r state is added via ‘cookies’ Design Issues: - Stateful vs Stateless - Hard State vs Soft State 2: Application Layer 19

HTTP connections I. Nonpersistent HTTP r At most one object is sent over a TCP connection. Used in HTTP/1. 0 II. Persistent HTTP r Multiple objects can be sent over single TCP connection. Used in HTTP/1. 1 by default: v v A. persistent with pipelining B. persistent without pipelining 2: Application Layer 20

I. Nonpersistent HTTP User enters URL some. School. edu/some. Department/home. index (contains text, references to 10 jpeg images) 1 a. HTTP client initiates TCP connection to some. School. edu : port 80 1 b. HTTP server @ some. School. edu port 80. “accepts” connection, notifying client 2. HTTP client sends request message (containing URL) into TCP connection. Message indicates that client wants object some. Department/home. index 3. HTTP server receives request message, sends response message containing requested object time 2: Application Layer 21

I. Nonpersistent HTTP (cont. ) 4. HTTP server closes TCP 5. HTTP client receives response connection. message containing html file, displays html. Parsing html file, finds 10 referenced jpeg objects time 6. Steps 1 -5 repeated for each of 10 jpeg objects 2: Application Layer 22

I. Non-Persistent HTTP: Response time Definition of RTT: time to send request from client to server and back. Response time: r one RTT to initiate TCP connection r one RTT for HTTP request and first few bytes of HTTP response to return r file transmission time total = 2 RTT+transmit time initiate TCP connection RTT request file RTT file received time to transmit file time 2: Application Layer 23

Persistent HTTP I. Nonpersistent HTTP issues: r requires 2 RTTs per object r OS overhead for each TCP connection r browsers often open parallel TCP connections to fetch referenced objects II. Persistent HTTP r server leaves connection open after sending response r subsequent HTTP messages between same client/server sent over open connection A. Persistent without pipelining: r client issues new request only when previous response has been received r one RTT for each referenced object B. Persistent with pipelining: r default in HTTP/1. 1 r client sends requests as soon as it encounters a referenced object r as little as one RTT for all the referenced objects 2: Application Layer 24

Web caches (proxy servers) Goal: satisfy client request without involving origin server r user sets browser: Web origin server accesses via cache r browser sends all HTTP requests to cache v v v object in cache: cache returns object else cache requests object from origin server, then returns object to client Cache keeps copy of object for future use HT client. HTTP TP req ues res Proxy server t pon se t es qu e se Pr on T p HT res P TT H client - Can all objects be cached? - Proxy vs. local browser cache st que re se TP pon HT es Pr T HT origin server 2: Application Layer 25

More about Web caching r cache acts as both client and server r typically cache is installed by ISP (university, company, residential ISP) Why Web caching? r 1. reduce response time for client request r 2. reduce traffic on an institution’s access link. 2: Application Layer 26

Caching example origin servers Assumptions r average object size = 100 k bits r avg. request rate from institution’s browsers = 15 req/sec r delay from institutional router to any origin server and back = 2 sec public Internet 1. 5 Mbps access link Consequences r utilization on LAN = 15% r utilization on access link = 100% r total delay institutional network = Internet delay + access delay + LAN delay = 2 sec + minutes + milliseconds 10 Mbps LAN 2: Application Layer 27

Caching example (cont) origin servers one solution: install cache r suppose hit rate is 0. 4 consequence public Internet r 40% requests will be satisfied almost immediately r 60% requests satisfied by origin server r utilization of access link reduced to 60%, resulting in negligible delays (say 10 msec) r total avg delay = Internet delay + access delay + LAN delay =. 6*(2. 01) secs +. 4*milliseconds < 1. 4 secs 1. 5 Mbps access link institutional network 10 Mbps LAN institutional cache 2: Application Layer 28

FTP: the file transfer protocol user at host FTP user client interface file transfer FTP server remote file system local file system r client/server model client: side initiating transfer, server: remote host r ftp: RFC 959, ftp server: port 21 TCP control connection r Separate data and control connections v port 21 r FTP server maintains “state”: v current directory, earlier authentication FTP client TCP data connection port 20 2: Application Layer FTP server 29

outgoing message queue Electronic Mail user mailbox Three components: r 1. user agents, 2. mail servers r 3. SMTP (simple mail transfer protocol) User Agent r “mail reader”: editing, reading mail r e. g. , Outlook, Mozilla Thunderbird r Out/incoming msgs stored on server user agent mail server SMTP Mail Servers r Mailbox: incoming messages r message queue outgoing msgs mail server r SMTP protocol between mail servers to send email messages v client: sending mail server v “server”: receiving mail server user agent mail server SMTP user agent 2: Application Layer 30

Electronic Mail: SMTP [RFC 2821] r uses TCP to reliably transfer email message from client to server, port 25 r direct transfer: sending server to receiving server r three phases of transfer v 1. handshake, 2. transfer of messages, 3. closure r SMTP uses persistent connections: sending mail server sends all its messages to the receiving mail server one TCP connection r Email Scenario: 1 user agent 2 Send mail server 3 mail server 4 5 user agent 6 Rcv mail 2: Application Layer 31

SMTP: Comparison with HTTP: r HTTP: pull r SMTP: push r both have ASCII command/response interaction, status codes r HTTP: each object encapsulated in its own response msg r SMTP: multiple objects sent in multipart msg Protocol Design Issue: - Pull vs. Push vs. Hybrid (spectrum) - how far do we push/pull - Issues & factors to analyze: - access pattern, delay, object dynamics, … 2: Application Layer 32

Chapter 2: Application layer r 2. 1 Principles of network applications r 2. 2 Web and HTTP r 2. 3 FTP r 2. 4 Electronic Mail v SMTP, POP 3, IMAP r 2. 5 DNS r 2. 6 P 2 P file sharing r 2. 7 Socket programming with TCP r 2. 8 Socket programming with UDP r 2. 9 Building a Web server 2: Application Layer 33

DNS: Domain Name System Internet identifiers for hosts, routers: v v IP address used for addressing datagrams “name”, e. g. , ww. yahoo. com - used by humans Q: map between IP addresses and name ? 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) v note: core Internet function, implemented as application-layer protocol v complexity at network’s “edge” 2: Application Layer 34

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

Distributed, Hierarchical Database Root DNS Servers com DNS servers yahoo. com amazon. com DNS servers org DNS servers pbs. org DNS servers edu DNS servers poly. edu umass. edu DNS servers Client wants IP for www. amazon. com; 1 st approx: r client queries a root server to find com DNS server r client queries com DNS server to get amazon. com DNS server r client queries amazon. com DNS server to get IP address for www. amazon. com 2: Application Layer 36

DNS: Root name servers r contacted by local name server that can not resolve name r root name server: v v v 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 g US Do. D Vienna, VA h ARL Aberdeen, MD j Verisign, ( 21 locations) e NASA Mt View, CA f Internet Software C. Palo Alto, k RIPE London (also 16 other locations) i Autonomica, Stockholm (plus 28 other locations) m WIDE Tokyo (also Seoul, 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 37

TLD and Authoritative Servers r I. Top-level domain (TLD) servers: v responsible for com, org, net, edu, etc, and all top -level country domains uk, fr, ca, jp. v Network Solutions maintains servers for com TLD v Educause for edu TLD r II. Authoritative DNS servers: v organization’s DNS servers, providing authoritative hostname to IP mappings for organization’s servers (e. g. , Web, mail). v can be maintained by organization or service provider 2: Application Layer 38

III. Local Name Server r does not strictly belong to hierarchy r each ISP (residential ISP, company, university) has one. v also called “default name server” r when host makes DNS query, query is sent to its local DNS server v acts as proxy, forwards query into hierarchy 2: Application Layer 39

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

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

DNS: caching and updating records r once (any) name server learns mapping, it caches mapping v cache entries timeout (disappear) after some time (soft state !) v TLD servers typically cached in local name servers • Thus root name servers not often visited (reduces load and delays) r update/notify mechanisms under design by IETF v RFC 2136 v http: //www. ietf. org/html. charters/dnsind-charter. html 2: Application Layer 42

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

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: v query or reply v recursion desired v recursion available v reply is authoritative 2: Application Layer 44

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 45

Inserting records into DNS r example: new startup “Network Utopia” r register name networkuptopia. com at DNS registrar (e. g. , Network Solutions) v v provide names, IP addresses of authoritative name server (primary and secondary) registrar inserts two RRs into com TLD server: (networkutopia. com, dns 1. networkutopia. com, NS) (dns 1. networkutopia. com, 212. 1, A) r create authoritative server Type A record for www. networkuptopia. com; Type MX record for networkutopia. com r How do people get IP address of your Web site? 2: Application Layer 46

Chapter 2: Application layer r 2. 1 Principles of network applications v v app architectures app requirements r 2. 2 Web and HTTP r 2. 4 Electronic Mail v SMTP, POP 3, IMAP r 2. 5 DNS r 2. 6 P 2 P file sharing r 2. 7 Socket programming with TCP r 2. 8 Socket programming with UDP r 2. 9 Building a Web server 2: Application Layer 47

P 2 P file sharing Example r Alice runs P 2 P client application on her notebook computer r intermittently connects to Internet; gets new IP address for each connection r asks for “Hey Jude” r application displays other peers that have copy of Hey Jude. r Alice chooses one of the peers, Bob. r file is copied from Bob’s PC to Alice’s notebook: HTTP r while Alice downloads, other users uploading from Alice. r Alice’s peer is both a Web client and a transient Web server. All peers are servers = highly scalable! 2: Application Layer 48

P 2 P: centralized directory original “Napster” design 1) when peer connects, it informs central server: v v Bob centralized directory server 1 peers IP address content 2) Alice queries for “Hey Jude” 3) Alice requests file from Bob 1 3 1 2 1 Alice 2: Application Layer 49

P 2 P: problems with centralized directory r single point of failure r performance bottleneck r copyright infringement: “target” of lawsuit is obvious file transfer is decentralized, but locating content is highly centralized Advantages vs. disadvantages Search time and overhead? 2: Application Layer 50

Query flooding: Gnutella r fully distributed v no central server r public domain protocol r many Gnutella clients implementing protocol Advantages vs Disadvs of overlays? overlay network: graph r edge between peer X and Y if there’s a TCP connection r all active peers and edges form overlay net r edge: virtual (not physical) link r given peer typically connected with < 10 overlay neighbors 2: Application Layer 51

Gnutella: protocol r Query message sent over existing TCP connections r peers forward Query message y er r Query. Hit Qu t 2 Hi ry sent over ue Q 6 reverse 1 Query path 7 Query. Hit Scalability: limited scope flooding 3 Query 5 Query. Hit 4 Q ue ry 8 File transfer: HTTP 2 Q ue ry 2: Application Layer 52

Gnutella: Peer joining peer Alice must find another peer in Gnutella network: use list of candidate peers 2. Alice sequentially attempts TCP connections with candidate peers until connection setup with Bob 3. Flooding: Alice sends Ping message to Bob; Bob forwards Ping message to his overlay neighbors (who then forward to their neighbors…. ) r peers receiving Ping message respond to Alice with Pong message 4. Alice receives many Pong messages, and can then setup additional TCP connections 1. 2: Application Layer 53

Hierarchical Overlay r between centralized index, query flooding approaches r each peer is either a group leader or assigned to a group leader. v v TCP connection between peer and its group leader. TCP connections between some pairs of group leaders. r group leader tracks content in its children 2: Application Layer 54

Comparing Client-server, P 2 P architectures Question : How much time distribute file initially at one server to N other computers? us: server upload bandwidth Server us File, size F u. N d. N u 1 d 1 u 2 ui: client/peer i upload bandwidth d 2 di: client/peer i download bandwidth Network (with abundant bandwidth) 2: Application Layer 55

Client-server: file distribution time r server sequentially sends N copies: v NF/us time r client i takes F/di time to download Server F us u. N u 1 d 1 u 2 d 2 Network (with abundant bandwidth) d. N Time to distribute F to N clients using = dcs = max { NF/us, F/min(di) } i client/server approach increases linearly in N (for large N) 2: Application Layer 56

P 2 P: file distribution time r server must send one Server F u 1 d 1 u 2 d 2 copy: F/us time us r client i takes F/di time Network (with d. N to download abundant bandwidth) u. N r NF bits must be downloaded (aggregate) r fastest possible upload rate (assuming all nodes sending file chunks to same peer): us + Sui i=1, N Sui) } i=1, N d. P 2 P = max { F/us, F/min(di) , NF/(us + i 2: Application Layer 57

Comparing Client-server, P 2 P architectures 2: Application Layer 58

P 2 P Case Study: Bit. Torrent r P 2 P file distribution tracker: tracks peers participating in torrent: group of peers exchanging chunks of a file obtain list of peers trading chunks peer 2: Application Layer 59

Bit. Torrent (1) r file divided into 256 KB chunks. r peer joining torrent: has no chunks, but will accumulate them over time v registers with tracker to get list of peers, connects to subset of peers (“neighbors”) r while downloading, peer uploads chunks to other peers (requiring nodes to be contributors!). r peers may come and go r once peer has entire file, it may (selfishly) leave or (altruistically) remain v 2: Application Layer 60

Bit. Torrent (2) Pulling Chunks r at any given time, different peers have different subsets of file chunks r periodically, a peer (Alice) asks each neighbor for list of chunks that they have. r Alice issues requests for her missing chunks v rarest first Sending Chunks: tit-for-tat r Alice sends chunks to four neighbors currently sending her chunks at the highest rate v re-evaluate top 4 every 10 secs r every 30 secs: randomly select another peer, starts sending chunks v newly chosen peer may join top 4 2: Application Layer 61

P 2 P Case study: Skype clients (SC) r P 2 P (pc-to-pc, pc-to- phone, phone-to-pc) Voice-Over-IP (Vo. IP) Skype application login server v also IM r proprietary application -layer protocol (inferred via reverse engineering) r hierarchical overlay Supernode (SN) 2: Application Layer 62

Skype: making a call r User starts Skype r SC registers with SN v list of bootstrap SNs r SC logs in Skype login server (authenticate) r Call: SC contacts SN will callee ID v SN contacts other SNs (unknown protocol, maybe flooding) to find addr of callee; returns addr to SC r SC directly contacts callee, over. TCP 2: Application Layer 63

Chapter 2: Application layer r 2. 1 Principles of network applications r 2. 2 Web and HTTP r 2. 3 FTP r 2. 4 Electronic Mail v r 2. 6 P 2 P file sharing r 2. 7 Socket programming with TCP r 2. 8 Socket programming with UDP SMTP, POP 3, IMAP r 2. 5 DNS 2: Application Layer 64

Socket programming Goal: learn how to build client/server application that communicate using sockets Socket API r introduced in BSD 4. 1 UNIX, 1981 r explicitly created, used, released by apps r client/server paradigm r two types of transport service via socket API: v unreliable datagram v reliable, byte streamoriented socket a host-local, application-created, OS-controlled interface (a “door”) into which application process can both send and receive messages to/from another application process 2: Application Layer 65

Socket-programming using TCP Socket: a door between application process and endend-transport protocol (UCP or TCP) TCP service: reliable transfer of bytes from one process to another controlled by application developer controlled by operating system process socket TCP with buffers, variables host or server internet socket TCP with buffers, variables controlled by application developer controlled by operating system host or server 2: Application Layer 66

Socket programming with TCP Client must contact server r server process must first be running r server must have created socket (door) that welcomes client’s contact Client contacts server by: r creating client-local TCP socket r specifying IP address, port number of server process r When client creates socket: client TCP establishes connection to server TCP r When contacted by client, server TCP creates new socket for server process to communicate with client v allows server to talk with multiple clients v source port numbers used to distinguish clients (more in Chap 3) application viewpoint TCP provides reliable, in-order transfer of bytes (“pipe”) between client and server 2: Application Layer 67

Client/server socket interaction: TCP Server Client (running on hostid) create socket, port=x, for incoming request: welcome. Socket = Server. Socket() TCP wait for incoming connection request connection. Socket = welcome. Socket. accept() read request from connection. Socket write reply to connection. Socket close connection. Socket setup create socket, connect to hostid, port=x client. Socket = Socket() send request using client. Socket read reply from client. Socket close client. Socket 2: Application Layer 68

Stream jargon r A stream is a sequence of characters that flow into or out of a process. r An input stream is attached to some input source for the process, e. g. , keyboard or socket. r An output stream is attached to an output source, e. g. , monitor or socket. Client process client TCP socket 2: Application Layer 69

Chapter 2: Application layer r 2. 1 Principles of network applications r 2. 2 Web and HTTP r 2. 3 FTP r 2. 4 Electronic Mail v SMTP, POP 3, IMAP r 2. 5 DNS r 2. 6 P 2 P file sharing r 2. 7 Socket programming with TCP r 2. 8 Socket programming with UDP r 2. 9 Building a Web server 2: Application Layer 70

Socket programming with UDP: no “connection” between client and server r no handshaking r sender explicitly attaches IP address and port of destination to each packet r server must extract IP address, port of sender from received packet application viewpoint UDP provides unreliable transfer of groups of bytes (“datagrams”) between client and server UDP: transmitted data may be received out of order, or lost 2: Application Layer 71

Client/server socket interaction: UDP Server (running on hostid) create socket, port=x, for incoming request: server. Socket = Datagram. Socket() read request from server. Socket write reply to server. Socket specifying client host address, port number Client create socket, client. Socket = Datagram. Socket() Create, address (hostid, port=x, send datagram request using client. Socket read reply from client. Socket close client. Socket 2: Application Layer 72

Example: client (UDP) Client process Input: receives packet (recall that. TCP received “byte stream”) Output: sends packet (recall that TCP sent “byte stream”) client UDP socket 2: Application Layer 73

Chapter 2: Summary our study of network apps now complete! r application architectures v client-server v P 2 P v hybrid r application service requirements: v reliability, bandwidth, delay r specific protocols: v HTTP v FTP v SMTP, POP, IMAP v DNS v P 2 P: Bit. Torrent, Skype r socket programming r Internet transport service model v v connection-oriented, reliable: TCP unreliable, datagrams: UDP 2: Application Layer 74

Chapter 2: Summary Most importantly: learned about protocols r typical request/reply message exchange: v v client requests info or service server responds with data, status code r message formats: v headers: fields giving info about data v data: info being communicated Important themes: r control vs. data msgs v in-band, out-of-band r centralized vs. decentralized r stateless vs. stateful r reliable vs. unreliable msg transfer r “complexity at network edge” 2: Application Layer 75