2: Application Layer1 Network applications: some jargon 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 mail reader m streaming audio/video: media player

2: Application Layer2 Applications and application-layer protocols Application: communicating, distributed processes m e.g., , 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

2: Application Layer3 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

2: Application Layer4 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; in mail reader request reply Server: r provides requested service to client r e.g., Web server sends requested Web page, mail server delivers

2: Application Layer5 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 asssumes transport infrastructure on other side of door which brings message to socket at receiving process 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 r API: (1) choice of transport protocol; (2) ability to fix a few parameters

2: Application Layer6 Socket programming Socket API r introduced in BSD4.1 UNIX, 1981 r explicitly created, used, released by apps r client/server paradigm r two types of transport service via socket API: m unreliable datagram m reliable, byte stream- oriented 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 socket Goal: learn how to build client/server application that communicate using sockets

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

2: Application Layer8 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 m allows server to talk with multiple clients m source port numbers used to distinguish clients TCP provides reliable, in-order transfer of bytes (“pipe”) between client and server application viewpoint

2: Application Layer9 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, eg, keyboard or socket. r An output stream is attached to an output source, eg, monitor or socket.

2: Application Layer10 Socket programming with TCP Example client-server app: 1) client reads line from standard input ( inFromUser stream), sends to server via socket ( outToServer stream) 2) server reads line from socket 3) server converts line to uppercase, sends back to client 4) client reads, prints modified line from socket ( inFromServer stream) Client process client TCP socket

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

2: Application Layer12 Example: Java client (TCP) import java.io.*; import java.net.*; class TCPClient { 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()); Create input stream Create client socket, connect to server Create output stream attached to socket

2: Application Layer13 Example: Java client (TCP), cont. 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(); } Create input stream attached to socket Send line to server Read line from server

2: Application Layer14 Example: Java server (TCP) import java.io.*; import java.net.*; class TCPServer { 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())); Create welcoming socket at port 6789 Wait, on welcoming socket for contact by client Create input stream, attached to socket

2: Application Layer15 Example: Java server (TCP), cont DataOutputStream outToClient = new DataOutputStream (connectionSocket.getOutputStream()); clientSentence = inFromClient.readLine(); capitalizedSentence = clientSentence.toUpperCase() + '\n'; outToClient.writeBytes(capitalizedSentence); } Read in line from socket Create output stream, attached to socket Write out line to socket End of while loop, loop back and wait for another client connection

2: Application Layer16 Socket programming with UDP 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 UDP: transmitted data may be received out of order, or lost application viewpoint UDP provides unreliable transfer of groups of bytes (“datagrams”) between client and server

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

2: Application Layer18 Example: Java client (UDP) Output: sends packet (TCP sent “byte stream”) Input: receives packet (TCP received “byte stream”) Client process client UDP socket

2: Application Layer19 Example: Java client (UDP) import java.io.*; import java.net.*; 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(); Create input stream Create client socket Translate hostname to IP address using DNS

2: Application Layer20 Example: Java client (UDP), cont. 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(); } Create datagram with data-to-send, length, IP addr, port Send datagram to server Read datagram from server

2: Application Layer21 Example: Java server (UDP) import java.io.*; import java.net.*; 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); Create datagram socket at port 9876 Create space for received datagram Receive datagram

2: Application Layer22 Example: Java server (UDP), cont String sentence = new String(receivePacket.getData()); InetAddress IPAddress = receivePacket.getAddress(); int port = receivePacket.getPort(); String capitalizedSentence = sentence.toUpperCase(); sendData = capitalizedSentence.getBytes(); DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, port); serverSocket.send(sendPacket); } Get IP addr port #, of sender Write out datagram to socket End of while loop, loop back and wait for another datagram Create datagram to send to client

2: Application Layer23 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 asssumes transport infrastructure on other side of door which brings message to socket at receiving process 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 r API: (1) choice of transport protocol; (2) ability to fix a few parameters

2: Application Layer24 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 Q: does the IP address of the host on which the process runs suffice for identifying the process? r Answer: No, many processes can be running on same host r Identifier includes both the IP address and port numbers associated with the process on the host. r Example port numbers: m HTTP server: 80 m Mail server: 25

2: Application Layer25 DNS: Domain Name System People: many identifiers: m SSN, name, passport # Internet hosts, routers: m IP address (32 bit) - used for addressing datagrams m “name”, e.g., gaia.cs.umass.edu - 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) m note: core Internet function, implemented as application-layer protocol m complexity at network’s “edge”

2: Application Layer26 DNS name servers r no server has all name- to-IP address mappings 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!

2: Application Layer27 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

2: Application Layer28 Simple DNS example host surf.eurecom.fr wants IP address of gaia.cs.umass.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.umass.edu, if necessary requesting host surf.eurecom.fr gaia.cs.umass.edu root name server authorititive name server dns.umass.edu local name server dns.eurecom.fr

2: Application Layer29 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 gaia.cs.umass.edu root name server local name server dns.eurecom.fr authoritative name server dns.cs.umass.edu intermediate name server dns.umass.edu 7 8

2: Application Layer30 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 gaia.cs.umass.edu root name server local name server dns.eurecom.fr authoritative name server dns.cs.umass.edu intermediate name server dns.umass.edu 7 8 iterated query

2: Application Layer31 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

2: Application Layer32 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

2: Application Layer33 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 is really servereast.backup2.ibm.com  value is cannonical name r Type=MX  value is name of mailserver associated with name

2: Application Layer34 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