Chapter 2: Application layer

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: Application Layer 1

Some network apps e-mail web instant messaging remote login P2P file sharing multi-user network games streaming stored video clips voice over IP real-time video conferencing cloud computing A Simple Survey of four most frequently used websites requiring login and password http:// www.surveymonkey.co m/s/785pgpv 2: Application Layer 2

Creating a network app write programs that run on (different) end systems communicate over network e.g., web server software communicates with browser software No need to write software for network-core devices Network-core devices do not run user applications applications on end systems allows for rapid app development, propagation application transport network data link physical application transport network data link physical application transport network data link physical 2: Application Layer 3

Application architectures Client-server Peer-to-peer (P2P) Hybrid of client-server and P2P 2: Application Layer 4

Client-server architecture server: always-on host permanent IP address client/server 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 5

Google Data Centers Estimated cost of data center: $600M Google spent $2.4B in 2007 on new data centers, each using 50-100 megawatts

Pure P2P architecture no always-on server arbitrary end systems directly communicate peers are intermittently connected and change IP addresses peer-peer Highly scalable but difficult to manage 2: Application Layer 7

Hybrid of client-server and P2P Skype voice-over-ip P2P application centralized server: finding address of remote party: client-client connection: direct (not through server) Instant messaging chatting between two users is P2P centralized service: client presence detection/ location 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 8

some jargon related to applicationlevel protocols Process: program running within a host. processes running in different hosts communicate by exchanging messages with an application-layer protocol, e.g., HTTP (for web), SMTP, POP3 (for email access) user agent: implements user interface & application-level protocol Web: browser IE (implements HTTP) E-mail: PINE, Outlook (a reading agent implements POP3 and a sending agent implements SMTP) Transport Layer 3-9

A Big Picture: Processes Communication via Sockets (API provided by OS) users user agent API IP address Port # (e.g., 80 for HTTP, and 25 for SMTP Transport Layer 3-10

Socket Programming (More in Recitation/Project #1) App processes communicate with each other through sockets socket Socket API introduced in BSD4.1 UNIX, 1981 explicitly created, used, released by apps client/server paradigm two types of transport service via socket API: unreliable datagram reliable, byte streamoriented 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 A socket is associated with one port # on a host. Transport Layer 3-11

App-layer protocol defines Types of messages exchanged, e.g., request & response messages Syntax of message types: what fields in messages & how fields are delineated Semantics of the fields, ie, meaning of information in fields Rules for when and how processes send & respond to messages Public-domain protocols: defined in RFCs allows for interoperability E.g., HTTP, SMTP uses well-defined port # (0 to 1023) Proprietary protocols: can t use well-define port #s E.g. Skype Transport Layer 3-12

Transport vs. network layer network layer: logical communication between hosts may not be reliable transport layer: logical communication between processes uses, enhances, network layer services Provides either reliable or unreliable services to app processes Use IP Address and Port #s. Household analogy: 12 kids in one house sending letters to 12 kids in another house processes = kids in each room app messages = letters in envelopes 2 hosts = 2 houses transport protocol = Ann and Bill (2 mail collectors in 2 houses) network-layer protocol = postal service Transport Layer 3-13

Socket-programming Socket: a door between application process and end-end-transport protocol (UDP or TCP) controlled by application developer controlled by operating system process socket TCP with buffers, variables internet process socket TCP with buffers, variables controlled by application developer controlled by operating system host or server host or server Transport Layer 3-14

Socket programming with UDP UDP: no connection between client and server no handshaking sender explicitly attaches IP address and port of destination to each packet OS attaches IP address and port of sending socket to each segment server must extract IP address, port of client from received packet UDP: transmitted data may be received out of order, or lost Client must contact server server process must first be running server must have created socket (door) that welcomes client s contact Client contacts server by: creating client-local socket sending a UDP datagram specifying IP address, port number of server process application viewpoint UDP provides unreliable transfer of groups of bytes ( datagrams ) between client and server Transport Layer 3-15

1 Client/1 server with UDP socket Server (running on hostid) Client create socket, port=x, for incoming request: serversocket = DatagramSocket(port) read request from serversocket create socket, clientsocket = DatagramSocket() (at port y) Create, address (hostid, port=x) send datagram request using clientsocket write reply to serversocket specifying client host address, port number (y) read reply from clientsocket close clientsocket Transport Layer 3-16

Example: Java client (UDP) keyboard monitor Get keyboard input (in lowercase) from users Send to a server for uppercase conversion Client Process input stream infromuser Receive the converted characters and display them UDP packet sendpacket clientsocket receivepacket UDP packet UDP socket to network from network 2: Application Layer 17

Example: Java server (UDP) import java.io.*; import java.net.*; Create datagram socket at port 9876 Create space for received datagram Receive datagram class UDPServer { public static void main(string args[]) throws Exception { DatagramSocket serversocket = new DatagramSocket(9876); byte[] receivedata = new byte[1024]; byte[] senddata = new byte[1024]; while(true) { DatagramPacket receivepacket = new DatagramPacket(receiveData, receivedata.length); serversocket.receive(receivepacket); Transport Layer 3-18

Example: Java server (UDP), cont Get IP addr port #, of Client/requester String sentence = new String(receivePacket.getData()); InetAddress IPAddress = receivepacket.getaddress(); int port = receivepacket.getport(); Create datagram to send to client Write out datagram to socket } } String capitalizedsentence = sentence.touppercase(); senddata = capitalizedsentence.getbytes(); DatagramPacket sendpacket = new DatagramPacket(sendData, senddata.length, IPAddress, port); serversocket.send(sendpacket); } End of while loop, loop back and wait for another datagram Transport Layer 3-19

Example: Java client (UDP) import java.io.*; import java.net.*; Create input stream Create client socket Translate server name to IP address using DNS class UDPClient { public static void main(string args[]) throws Exception { BufferedReader infromuser = new BufferedReader(new InputStreamReader(System.in)); DatagramSocket clientsocket = new DatagramSocket(); InetAddress IPAddress = InetAddress.getByName("hostname"); byte[] senddata = new byte[1024]; byte[] receivedata = new byte[1024]; String sentence = infromuser.readline(); senddata = sentence.getbytes(); Transport Layer 3-20

Example: Java client (UDP), cont. Create datagram with data-to-send, length, IP addr, port Send datagram to server Read datagram from server } DatagramPacket sendpacket = new DatagramPacket(sendData, senddata.length, IPAddress, 9876); clientsocket.send(sendpacket); DatagramPacket receivepacket = new DatagramPacket(receiveData, receivedata.length); clientsocket.receive(receivepacket); String modifiedsentence = new String(receivePacket.getData()); System.out.println("FROM SERVER:" + modifiedsentence); clientsocket.close(); } Transport Layer 3-21

Socket programming with TCP Client must contact server server process must first be running server must have created socket (door) that welcomes client s contact Client contacts server by: creating client-local TCP socket specifying IP address, port number of server process When client creates socket: client TCP establishes connection to server TCP To support multiple clients, server TCP can create new socket for each client All subsequent data exchanges over the new socket Similar concept applies to UDP too application viewpoint TCP provides reliable, in-order transfer of bytes ( pipe ) between client and server Transport Layer 3-22

Client/server socket interaction: TCP Server (running on hostid) Client create socket, port=x, for incoming request: welcomesocket = ServerSocket(port) wait for incoming connection request connectionsocket = welcomesocket.accept() TCP connection setup create socket, connect to hostid, port=x clientsocket = Socket(hostid, port) read request from connectionsocket send request using clientsocket write reply to connectionsocket close connectionsocket read reply from clientsocket close clientsocket Transport Layer 3-23

Example: Java client (TCP) import java.io.*; import java.net.*; class TCPClient { Create input stream Create client socket, connect to server Create output stream attached to socket public static void main(string argv[]) throws Exception { String sentence; String modifiedsentence; BufferedReader infromuser = new BufferedReader(new InputStreamReader(System.in)); Socket clientsocket = new Socket("hostname", 6789); DataOutputStream outtoserver = new DataOutputStream(clientSocket.getOutputStream()); 2: Application Layer 24

Example: Java client (TCP), cont. Create input stream attached to socket Send line to server Read line from server BufferedReader infromserver = new BufferedReader(new InputStreamReader(clientSocket.getInputStream())); sentence = infromuser.readline(); outtoserver.writebytes(sentence + '\n'); modifiedsentence = infromserver.readline(); System.out.println("FROM SERVER: " + modifiedsentence); clientsocket.close(); } } 2: Application Layer 25

Example: Java server (TCP) import java.io.*; import java.net.*; class TCPServer { Create welcoming socket at port 6789 Wait, on welcoming socket for contact by client Create input stream, attached to socket public static void main(string argv[]) throws Exception { String clientsentence; String capitalizedsentence; ServerSocket welcomesocket = new ServerSocket(6789); while(true) { Socket connectionsocket = welcomesocket.accept(); BufferedReader infromclient = new BufferedReader(new InputStreamReader(connectionSocket.getInputStream())); 2: Application Layer 26

Example: Java server (TCP), cont Create output stream, attached to socket Read in line from socket DataOutputStream outtoclient = new DataOutputStream(connectionSocket.getOutputStream()); clientsentence = infromclient.readline(); capitalizedsentence = clientsentence.touppercase() + '\n'; Write out line to socket } } } outtoclient.writebytes(capitalizedsentence); End of while loop, loop back and wait for another client connection 2: Application Layer 27

TCP Sockets vs UDP Sockets TCP socket identified by 4-tuple: source IP address source port number dest IP address dest port number Dest IP and port are not explicitly attached to segment. Server has two types of sockets: When client knocks on serversocket s door, server creates connectionsocket and completes TCP conx. Web servers have different sockets for each connecting client non-persistent HTTP will have different socket for each request Transport Layer 3-28

What transport service does an app need? Data loss some apps (e.g., audio) can tolerate some loss other apps (e.g., file transfer, telnet) require 100% reliable data transfer Timing some apps (e.g., Internet telephony, interactive games) require low delay to be effective Throughput some apps (e.g., multimedia) require minimum amount of throughput to be effective other apps ( elastic apps ) make use of whatever throughput they get Security Encryption, data integrity, 2: Application Layer 29

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

Internet transport protocols services TCP service: connection-oriented: setup 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 throughput guarantees, security UDP service: unreliable data transfer between sending and receiving process does not provide: connection setup, reliability, flow control, congestion control, timing, throughput guarantee, or security Q: why bother? Why is there a UDP? 2: Application Layer 31

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] HTTP (eg Youtube), RTP [RFC 1889] SIP, RTP, proprietary (e.g., Skype) Underlying transport protocol TCP TCP TCP TCP TCP or UDP typically UDP 2: Application Layer 32

Chapter 2 outline 2.1 Principles of app layer protocols clients and servers app requirements 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P file sharing Transport Layer 3-33

Web and HTTP First 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 34

HTTP connections Nonpersistent HTTP At most one object (e.g., a HTML file, or a jpeg image but not both!) is sent over a TCP connection. HTTP/1.0 uses nonpersistent HTTP Persistent HTTP Multiple objects can be sent over single TCP connection between client and server. HTTP/1.1 uses persistent connections in default mode Transport Layer 3-35

Non-Persistent HTTP Response time modeling Definition of RRT: time to send a small packet to travel from client to server and back. Response time: one RTT to initiate TCP connection one RTT for HTTP request and first few bytes of response to return One file/one object transmission time total = 2RTT+transmit time initiate TCP connection RTT request file RTT file received time time time to transmit file Transport Layer 3-36

Persistent HTTP Persistent without pipelining: client issues new request only when previous response has been received one RTT for each referenced object Persistent with pipelining: default in HTTP/1.1 client sends requests as soon as it encounters a referenced object as little as one RTT for all the referenced objects HTTP is stateless server maintains no information about past client requests Transport Layer 3-37

User-server interaction: authorization Authorization : control access to server content authorization credentials: typically name, password stateless: client must present authorization in each request client usual http request msg 401: authorization req. WWW authenticate: server authorization: header line in each request if no authorization: header, server refuses access, sends WWW authenticate: header line in response usual http request msg + Authorization: <cred> usual http response msg usual http request msg + Authorization: <cred> usual http response msg time Transport Layer 3-38

Cookies: keeping state (privacy issue?) Cookie file ebay: 8734 client usual http request msg usual http response + Set-cookie: 1678 server server creates ID 1678 for user amazon Cookie file amazon: 1678 ebay: 8734 one week later: usual http request msg cookie: 1678 usual http response msg cookiespecific action access Cookie file amazon: 1678 ebay: 8734 usual http request msg cookie: 1678 usual http response msg cookiespectific action Transport Layer 3-39

Cookies (continued) What cookies can bring: authorization shopping carts recommendations user session state (Web e-mail) aside Cookies and privacy: cookies permit sites to learn a lot about you you may supply name and e-mail to sites How to keep state : protocol endpoints: maintain state at sender/receiver over multiple transactions cookies: http messages carry state 2: Application Layer 40

Web caches (proxy server) Goal: satisfy client request without involving origin server user sets browser: Web accesses via cache browser sends all HTTP requests to cache If object in cache: cache returns object else cache requests object from origin server, then returns object to client client client Proxy server origin server origin server Transport Layer 3-41

Content distribution networks (CDNs) The content providers (e.g., foxnews.com) own the original server Content replication CDN company (e.g., Akamai) installs hundreds of CDN servers throughout Internet in lower-tier ISPs, close to users CDN replicates its customers content in CDN servers. When provider updates content, CDN updates servers origin server in North America CDN distribution node CDN server in S. America CDN server in Europe CDN server in Asia Transport Layer 3-42

More on CDN goto www.cdn.com goto the nearest CDN server not just Web pages streaming stored audio/video streaming real-time audio/video CDN nodes create application-layer overlay network Transport Layer 3-43

FTP: separate control, data connections FTP client contacts FTP server at port 21, specifying TCP as transport protocol Client obtains authorization over control connection Client browses remote directory by sending commands over control connection. When server receives a command for a file transfer, the server opens a TCP data connection to client After transferring one file, server closes connection. FTP client TCP control connection port 21 TCP data connection port 20 FTP server Server opens a second TCP data connection to transfer another file. Control connection: out of band FTP server maintains state : current directory, earlier authentication Transport Layer 3-44

Electronic Mail Three major components: user agents mail servers simple mail transfer protocol: SMTP User Agent a.k.a. mail reader composing, editing, reading mail messages e.g., Eudora, Outlook, elm, Mozilla Thunderbird outgoing, incoming messages stored on server mail server SMTP mail server user agent user agent SMTP SMTP user agent outgoing message queue mail server user mailbox user agent user agent user agent 2: Application Layer 45

Scenario: Alice sends message to Bob 1) Alice uses UA to compose message to bob 2) Alice s UA sends message to her mail server; message placed in message queue 3) Client side of SMTP opens TCP connection with Bob s mail server 1 user agent mail mail SMTP SMTP server server 2 3 4 5 HTTP 4) SMTP client sends Alice s message over the TCP connection 5) Bob s mail server places the message in Bob s mailbox 6) Bob invokes his user agent to read message POP3 IMAP 6 HTTP Access to folders: Yes with IMAP or HTTP; No with POP3 user agent Transport Layer 3-46

SMTP: final words SMTP establishes a direct client-server (persistent) TCP connection SMTP requires message (header & body) to be in 7- bit ASCII For non-ascii data, use Multipurpose Internet Mail Extension (MIME) encoding Encoding method (e.g., base64) and type of the encoded data (e.g., jpeg) are sent in the header Comparison with HTTP: HTTP: pull (client request) SMTP: push (client send) both have ASCII command/response interaction, status codes HTTP: each object encapsulated in its own response msg SMTP: multiple objects sent in multipart msg Transport Layer 3-47

DNS: Domain Name System Maps between a host s name and its IP address Other functions host and mail server aliasing (with multiple names) Load balancing with replicated web servers (one name maps to a set of IP addresses distributed database implemented with a hierarchy and caching Local (default), Root and Authoritative name servers Transport Layer 3-48

P2P: centralized directory original Napster design 1) when a user (peer) connects, it informs central server: IP address content 2) Alice queries for a file 3) Alice requests/gets file from Bob 4) A node = client + server 5) failure, bottleneck, copyright infringement centralized directory server 2 1 1 1 1 Alice 3 Bob peers Transport Layer 3-49

P2P: decentralized directory KaZaA/FastTrack use a bootstrap node Each peer is either a group leader or assigned to a group leader. Group leader tracks the content in all its group members. Peer queries group leader; group leader may query other group leaders. ordinary peer group-leader peer neighoring relationships in overlay network Bootstrap node Transport Layer 3-50

P2P: Query flooding Gnutella no hierarchy/group leaders use bootstrap node to learn about others send join message Send query to neighbors Neighbors forward query If queried peer has object, it sends message back to querying peer join Transport Layer 3-51

P2P: more on query flooding Pros no group leaders (which maybe overburdened) Cons even more difficult to maintain (when nodes leave) may generate excessive query traffic Solution: limit the number of hops or query radius query radius: may not find content when present bootstrap node Transport Layer 3-52

File Distribution: Server-Client vs P2P Question : How much time to distribute file from one server to N peers? File, size F Server u 1 d 1 u 2 u d 2 s u s : server upload bandwidth u i : peer i upload bandwidth d i : peer i download bandwidth d N u N Network (with abundant bandwidth) 2: Application Layer 53

File distribution time: server-client server sequentially sends N copies: NF/u s time client i takes F/d i time to download F Server d N u N u u 2 1 d 1 u d s 2 Network (with abundant bandwidth) Time to distribute F to N clients using client/server approach = d cs = max { NF/u s, F/min(d i ) } increases linearly in N (for large N) 2: Application Layer 54

File distribution time: P2P server must send one copy: F/u s time client i takes F/d i time to download NF bits must be uploaded and downloaded (aggregate) F Server d N u N u u 2 1 d 1 u d s 2 Network (with abundant bandwidth) fastest possible upload rate: u s + Su i Download faster than upload (so won t be the bottleneck) d P2P = max { F/u s, F/min(d i ), NF/(u s + Su i ) } i 2: Application Layer 55

Server-client vs. P2P: example Client upload rate = u, F/u = 1 hour, u s = 10u, d min u s Minimum Distribution Time 3.5 3 2.5 2 1.5 1 0.5 0 P2P Client-Server 0 5 10 15 20 25 30 35 N 2: Application Layer 56

File distribution: BitTorrent P2P file distribution tracker: tracks peers participating in torrent torrent: group of peers exchanging chunks of a file obtain list of peers trading chunks peer 2: Application Layer 57

BitTorrent (1) file divided into 256KB chunks. peer joining torrent: has no chunks, but will accumulate them over time registers with tracker to get list of peers, connects to subset of peers ( neighbors ) while downloading, peer uploads chunks to other peers. peers may come and go once peer has entire file, it may (selfishly) leave or (altruistically) remain 2: Application Layer 58

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

BitTorrent: Tit-for-tat (1) Alice optimistically unchokes Bob (2) Alice becomes one of Bob s top-four providers; Bob reciprocates (3) Bob becomes one of Alice s top-four providers With higher upload rate, can find better trading partners & get file faster! 2: Application Layer 60

Distributed Hash Table (DHT) DHT = distributed P2P database Database has (key, value) pairs; key: ss number; value: human name key: content type; value: IP address Peers query DB with key DB returns values that match the key Peers can also insert (key, value) peers

DHT Identifiers Assign integer identifier to each peer in range [0,2 n -1]. Each identifier can be represented by n bits. Require each key to be an integer in same range. To get integer keys, hash original key. eg, key = h( Led Zeppelin IV ) This is why they call it a distributed hash table

How to assign keys to peers? Central issue: Assigning (key, value) pairs to peers. Rule: assign key to the peer that has the closest ID. Convention in lecture: closest is the immediate successor of the key. Ex: n=4; peers: 1,3,4,5,8,10,12,14; key = 13, then successor peer = 14 key = 15, then successor peer = 1

Circular DHT (1) 1 15 3 4 12 5 10 8 Each peer only aware of immediate successor and predecessor. Overlay network

Circle DHT (2) O(N) messages on avg to resolve query, when there are N peers 1111 I am 0001 0011 Who s resp for key 1110? 1110 1110 0100 1100 1110 1110 1110 0101 Define closest as closest successor 1010 1110 1000

Peer Churn 1 15 12 3 5 4 To handle peer churn, require each peer to know the IP address of its two successors. Each peer periodically pings its two successors to see if they are still alive. 10 8 Peer 5 abruptly leaves Peer 4 detects; makes 8 its immediate successor; asks 8 who its immediate successor is; makes 8 s immediate successor its second successor. What if peer 13 wants to join?

P2P Case study: Skype inherently P2P: pairs of users communicate. proprietary application-layer protocol (inferred via reverse engineering) hierarchical overlay with SNs Index maps usernames to IP addresses; distributed over SNs Skype login server Skype clients (SC) Supernode (SN) 2: Application Layer 67

Peers as relays Problem when both Alice and Bob are behind NATs. NAT prevents an outside peer from initiating a call to insider peer Solution: Using Alice s and Bob s SNs, Relay is chosen Each peer initiates session with relay. Peers can now communicate through NATs via relay 2: Application Layer 68