Application Layer
Ì conceptual +

implementation aspects of network application protocols r client server paradigm r service models Ì learn about protocols by examining popular application-level protocols

More goals Ì specific protocols:
r r r r r

http ftp SMTP pop DNS

Ì programming network


socket programming


Applications and application-layer protocols
Application: communicating, distributed processes r running in network hosts in “user space” r exchange messages to implement app r e.g., email, file transfer, the Web Application-layer protocols r one “piece” of an app r define messages exchanged by apps and actions taken r user services provided by lower layer protocols
application transport network data link physical

application transport network data link physical

application transport network data link physical


Client-server paradigm
Typical network app has two pieces: client and server Client: Ì initiates contact with server (“speaks first”) Ì typically requests service from server, Ì e.g.: request WWW page, send email Server: Ì provides requested service to client Ì e.g., sends requested WWW page, receives/stores received email
application transport network data link physical


application transport network data link physical


Application-layer protocols (cont).
API: application programming interface Ì defines interface between application and transport layer Ì socket: Internet API

Q: how does a process “identify” the other process with which it wants to communicate?

two processes communicate by sending data into socket, reading data out of socket


IP address of host running other process “port number” - allows receiving host to determine to which local process the message should be delivered

… lots more on this later.

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

Ì some apps (e.g., Internet

Ì some apps (e.g., multimedia)

require minimum amount of bandwidth to be “effective” Ì other apps (“elastic apps”) make use of whatever bandwidth they get

telephony, interactive games) require low delay to be “effective”


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


Services provided by Internet transport protocols
TCP service:
Ì connection-oriented: setup Ì Ì Ì

UDP service:
Ì unreliable data transfer


required between client, server 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

between sending and receiving process Ì does not provide: connection setup, reliability, flow control, congestion control, timing, or bandwidth guarantee Q: why bother? Why is there a UDP?


Internet apps: their protocols and transport protocols
Application e-mail remote terminal access Web file transfer streaming multimedia remote file server Internet telephony Application layer protocol smtp [RFC 821] telnet [RFC 854] http [RFC 2068] ftp [RFC 959] proprietary (e.g. RealNetworks) NSF proprietary (e.g., Vocaltec) Underlying transport protocol TCP TCP TCP TCP TCP or UDP TCP or UDP typically UDP


WWW: the http protocol
http: hypertext transfer protocol
Ì WWW’s application layer
htt pr

protocol Ì client/server model r client: browser that requests, receives, “displays” WWW objects r server: WWW server sends objects in response to requests Ì http1.0: RFC 1945 Ì http1.1: RFC 2068

PC running Explorer

htt pr


esp o



p htt

ue eq r

se on p res


Server running NCSA Web server

Mac running Navigator


The http protocol: more
http: TCP transport service:
Ì client initiates TCP connection

http is “stateless”
Ì server maintains no

(creates socket) to server, port 80 Ì server accepts TCP connection from client Ì http messages (applicationlayer protocol messages) exchanged between browser (http client) and WWW server (http server) Ì TCP connection closed

information about past client requests Protocols that maintain “state” are complex! Ì past history (state) must be maintained Ì if server/client crashes, their views of “state” may be inconsistent, must be reconciled



http example
Suppose user enters URL
www.someSchool.edu/someDepartment/home.index 1a. http client initiates TCP
connection to http server (process) at www.someSchool.edu. Port 80 is default for http server. (contains text, references to 10 jpeg images)

1b. http server at host
www.someSchool.edu waiting for TCP connection at port 80. “accepts” connection, notifying client

2. http client sends http request
message (containing URL) into TCP connection socket

3. http server receives request
message, forms response message containing requested object (someDepartment/home.index), sends message into socket


http example (cont.)
4. http server closes TCP 5. http client receives response
message containing html file, displays html. Parsing html file, findis10 referenced jpeg objects connection.

6. Steps 1-5 repeated for each of


10 jpeg objects
Ì non-persistent connection: one object in each TCP connection

some browsers create multiple TCP connections simultaneously - one per object Ì persistent connection: multiple objects transferred within one TCP connection

http message format: request
Ì two types of http messages: request, response Ì http request message: r ASCII (human-readable format)
request line (GET, POST, HEAD commands)

GET /somedir/page.html HTTP/1.1 Connection: close User-agent: Mozilla/4.0 header Accept: text/html, image/gif,image/jpeg lines Accept-language:fr (extra carriage return, line feed)

Carriage return, line feed indicates end of message


http request message: general format


http message format: reply
status line (protocol status code status phrase) header lines HTTP/1.1 200 OK Connection: close Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html data data data data data ...

data, e.g., requested html file


http reply status codes
In first line in server->client response message. A few sample codes: 200 OK

request succeeded, requested object later in this message requested object moved, new location specified later in this message (Location:) request message not understood by server requested document not found on this server

301 Moved Permanently

400 Bad Request

404 Not Found

505 HTTP Version Not Supported

Trying out http (client side) for yourself
1. Telnet to your favorite WWW server:
telnet www.eurecom.fr 80 Opens TCP connection to port 80 (default http server port) at www.eurecom.fr. Anything typed in sent to port 80 at www.eurecom.fr

2. Type in a GET http request:
GET /~ross/index.html HTTP/1.0

By typing this in (hit carriage return twice), you send this minimal (but complete) GET request to http server

3. Look at response message sent by http server!

User-server interaction: authentication
Authentication goal: control access to server documents Ì stateless: client must present authorization in each request Ì authorization: typically name, password r authorization: header line in request r if no authorization presented, server refuses access, sends
WWW authenticate:



usual http request msg 401: authorization req. WWW authenticate: usual http request msg + Authorization:line usual http response msg usual http request msg + Authorization:line usual http response msg

header line in response


User-server interaction: cookies
Ì server sends “cookie” to

usual http request msg usual http response +


client in response
Set-cookie: #
Ì client present cookie in

later requests
cookie: #
Ì server matches presented-

Set-cookie: #
usual http request msg

cookie with server-stored cookies r authentication r remembering user preferences, previous choices

cookie: #
usual http response msg usual http request msg

cookiespectific action cookiespectific action

cookie: #
usual http response msg

User-server interaction: conditional GET
Ì Goal: don’t send object if

http request msg
If-modified-since: <date>

object not modified

client has up-to-date stored (cached) version Ì client: specify date of cached copy in http request
If-modified-since: <date>
Ì server: response contains no

http response
HTTP/1.0 304 Not Modified

object if cached copy up-todate:
HTTP/1.0 304 Not Modified

http request msg
If-modified-since: <date>

http response
HTTP/1.1 200 OK …

object modified


Web Caches (proxy server)
Goal: satisfy client request without involving origin server
Ì user sets browser:
origin server
htt pr equ

WWW accesses via web cache Ì client sends all http requests to web cache


if object at web cache, web cache immediately returns object in http response else requests object from origin server, then returns http response to client

client http




Proxy server

u req se on ttp p h res tp ht

se est

st que e se pr t on p ht res tp ht htt pr equ htt est pr esp ons e


origin server

Why WWW Caching?
Assume: cache is “close” to client (e.g., in same network) Ì smaller response time: cache “closer” to client Ì decrease traffic to distant servers

origin servers
public Internet

1.5 Mbps access link institutional network 10 Mbps LAN

link out of institutional/local ISP network often bottleneck

institutional cache

ftp: the file transfer protocol
FTP FTP user client interface local file system file transfer FTP server remote file system

user at host

Ì transfer file to/from remote host Ì client/server model

client: side that initiates transfer (either to/from remote) r server: remote host Ì ftp: RFC 959 Ì ftp server: port 21

ftp: separate control, data connections
Ì ftp client contacts ftp server at

port 21, specifying TCP as transport protocol Ì two parallel TCP connections opened: r control: exchange commands, responses between client, server. “out of band control” r data: file data to/from server Ì ftp server maintains “state”: current directory, earlier authentication

TCP control connection port 21

FTP client

TCP data connection port 20

FTP server


ftp commands, responses
Sample commands:
Ì sent as ASCII text over

Sample return codes
Ì status code and phrase (as Ì Ì

control channel Ì USER username Ì PASS password
Ì LIST return list of file in

current directory
Ì RETR filename retrieves

(gets) file
Ì STOR filename stores


(puts) file onto remote host

in http) 331 Username OK, password required 125 data connection already open; transfer starting 425 Can’t open data connection 452 Error writing file


Electronic Mail
Three major components:
Ì user agents Ì mail servers Ì simple mail transfer protocol:
mail server user agent

outgoing message queue user mailbox

smtp User Agent Ì a.k.a. “mail reader” Ì composing, editing, reading mail messages Ì e.g., Eudora, pine, elm, Netscape Messenger Ì outgoing, incoming messages stored on server

mail server

user agent mail server user agent

user agent

user agent

user agent


Electronic Mail: mail servers
Mail Servers
Ì mailbox contains incoming
user agent mail server user agent mail server user agent

messages (yet ot be read) for user Ì message queue of outgoing (to be sent) mail messages Ì smtp protocol between mail server to send email messages r client: sending mail server r “server”: receiving mail server

mail server

user agent

user agent

user agent


Electronic Mail: smtp [RFC 821]
Ì uses tcp to reliably transfer email msg from client to server,

port 25 Ì direct transfer: sending server to receiving server Ì three phases of transfer r handshaking (greeting) r transfer r closure Ì command/response interaction r commands: ASCI text r response: status code and phrase


Sample smtp interaction
S: C: S: C: S: C: S: C: S: C: C: C: S: C: S: 220 hamburger.edu HELO crepes.fr 250 Hello crepes.fr, pleased to meet you MAIL FROM: <alice@crepes.fr> 250 alice@crepes.fr... Sender ok RCPT TO: <bob@hamburger.edu> 250 bob@hamburger.edu ... Recipient ok DATA 354 Enter mail, end with "." on a line by itself Do you like ketchup? How about pickles? . 250 Message accepted for delivery QUIT 221 hamburger.edu closing connection

smtp: final words
try smtp interaction for yourself:
Ì telnet servername 25 Ì see 220 reply from server Ì enter HELO, MAIL FROM,

Comparison with http
Ì http: pull Ì email: push Ì both have ASCII

RCPT TO, DATA, QUIT commands above lets you send email without using email client (reader)

command/response interaction, status codes
Ì http: multiple objects in file

sent in separate connections Ì smtp: multiple message parts sent in one connection


Mail message format
smtp: protocol for exchanging email msgs RFC 822: standard for text message format: Ì header lines, e.g.,
To: r From: r Subject: different from smtp commands!


blank line


Ì body


the “message”, ASCII characters only

Ì line containing only `.’

Message format: multimedia extensions
Ì MIME: multimedia mail extension, RFC 2045, 2056 Ì additional lines in msg header declare MIME content type

MIME version method used to encode data multimedia data type, subtype, parameter declaration encoded data

From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data .

MIME types
Ì example subtypes: plain,

Ì example subtypes:


mpeg, quicktime

Ì example subtypes: jpeg,

Ì other data that must be


Ì exampe subtypes: basic (8-

bit mu-law encoded), 32kadpcm (32 kbps coding)

processed by reader before “viewable” Ì example subtypes: msword, octetstream


Mail access protocols
user agent




user agent

sender’s mail server

receiver’s mail server

Ì SMTP: delivery/storage to receiver’s server Ì Mail access protocol: retrieval from server


POP: Post Office Protocol [RFC 1939] • authorization (agent <-->server) and download IMAP: Internet Mail Access Protocol [RFC 1730] • more features (more complex) • manipulation of stored msgs on server


POP3 protocol
authorization phase
Ì client commands:

S: C: S: C: S: C: S: S: S: C: S: S: C: C: S: S: C: C: S:

+OK POP3 server ready user alice +OK pass hungry +OK user successfully logged list 1 498 2 912 . retr 1 <message 1 contents> . dele 1 retr 2 <message 1 contents> . dele 2 quit +OK POP3 server signing off


user: declare username r pass: password Ì server responses r +OK r -ERR

transaction phase, client:
Ì list: list message numbers Ì retr: retrieve message by

number Ì dele: delete Ì quit


DNS: Domain Name System
People: many identifiers:

Domain Name System:
Ì distributed database

SSN, name, Passport # IP address (32 bit) - used for addressing datagrams “name”, e.g., gaia.cs.umass.edu used by humans

Internet hosts, routers:


Q: map between IP addresses and name ?

implemented in hierarchy of many name servers Ì application-layer protocol host, routers, name servers to communicate to resolve names (address/name translation) r note: core Internet function implemented as applicationlayer protocol r complexity at network’s “edge”

DNS name servers
Why not centralize DNS? Ì single point of failure Ì traffic volume Ì distant centralized database Ì maintenance doesn’t scale!
Ì no server has all name-to-

IP address mappings local name servers:


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

authoritative name server:


DNS: Root name servers
Ì contacted by local name

server that can not resolve name Ì root name server: r contacts authoritative name server if name mapping not known r gets mapping r returns mapping to local name server Ì ~ dozen root name servers worldwide

Simple DNS example

root name server

host surf.eurecom.fr wants 2 IP address of 5 gaia.cs.umass.edu 1. Contacts its local DNS server, dns.eurecom.fr 2. dns.eurecom.fr contacts local name server root name server, if dns.eurecom.fr necessary 1 6 3. root name server contacts authoritative name server, dns.umass.edu, if necessary requesting host



authorititive name server dns.umass.edu



DNS example
Root name server:
Ì may not know

root name server

2 7

6 3

authoratiative name server Ì may know intermediate name server: who to contact to find authoritative name server

local name server

intermediate name server dns.umass.edu





requesting host

authoritative name server dns.cs.umass.edu


DNS: iterated queries
recursive query:
Ì puts burden of name

root name server iterated query 3 4 7


resolution on contacted name server Ì heavy load?

iterated query:
Ì contacted server

local name server

intermediate name server dns.umass.edu

replies with name of server to contact Ì “I don’t know this name, but ask this server”





requesting host

authoritative name server dns.cs.umass.edu


DNS: caching and updating records
Ì once (any) name server learns mapping, it caches

mapping r cache entries timeout (disappear) after some time Ì update/notify mechanisms under design by IETF

RFC 2136


DNS records
DNS: distributed db storing resource records (RR) RR format:
Ì Type=A r name is hostname r value is IP address Ì Type=NS r name is domain (e.g. foo.com) r value is IP address of authoritative name server for this domain
(name, value, type,ttl)

Ì Type=CNAME r name is an alias name for some “cannonical” (the real) name r value is cannonical name Ì Type=MX r value is hostname of mailserver associated with name

DNS protocol, messages
DNS protocol : query and repy messages, both with same message format msg header
Ì identification: 16 bit # for

query, repy to query uses same # Ì flags: r query or reply r recursion desired r recursion available r reply is authoritative


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


Socket programming
Goal: learn how to build client/server application that communicate using sockets Socket API
Ì introduced in BSD4.1 UNIX,

a host-local, applicationcreated/owned, OS-controlled interface (a “door”) into which application process can both send and receive messages to/from another (remote or local) application process

1981 Ì explicitly created, used, released by apps Ì client/server paradigm Ì two types of transport service via socket API: r unreliable datagram r reliable, byte streamoriented


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 controlled by application developer controlled by operating system

process socket TCP with buffers, variables

process socket TCP with buffers, variables


host or server

host or server

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 Ì When contacted by client, server TCP creates new socket for server process to communicate with client r allows server to talk with multiple clients application viewpoint

TCP provides reliable, in-order transfer of bytes (“pipe”) between client and server

Socket programming with TCP
Example client-server app: Ì client reads line from standard input (inFromUser stream) , sends to server via socket (outToServer stream) Ì server reads line from socket Ì server converts line to uppercase, sends back to client Ì client reads, prints modified line from socket (inFromServer stream) Input stream: sequence of bytes into process Output stream: sequence of bytes out of process


client socket



Client/server socket interaction: TCP
Server (running on hostid)
create socket, port=x, for incoming request: welcomeSocket = ServerSocket() wait for incoming connection request connection connectionSocket = welcomeSocket.accept() read request from connectionSocket write reply to connectionSocket close connectionSocket




create socket, connect to hostid, port=x clientSocket = Socket() send request using clientSocket

read reply from connectionSocket close clientSocket 50

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

Example: Java client (TCP), cont.
Create input stream attached to socket BufferedReader inFromServer = new BufferedReader(new InputStreamReader(clientSocket.getInputStream())); sentence = inFromUser.readLine(); Send line to server Read line from server outToServer.writeBytes(sentence + '\n'); modifiedSentence = inFromServer.readLine(); System.out.println("FROM SERVER: " + modifiedSentence); clientSocket.close(); } }

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


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


Socket programming with UDP
UDP: no “connection” between client and server Ì no handshaking Ì sender explicitly attaches IP address and port of destination Ì server must extract IP address, port of sender from received datagram 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


Client/server socket interaction: UDP
Server (running on hostid)
create socket, port=x, for incoming request: serverSocket = DatagramSocket()

create socket, clientSocket = DatagramSocket() Create, address (hostid, port=x, send datagram request using clientSocket

read request from serverSocket write reply to serverSocket specifying client host address, port umber

read reply from clientSocket close clientSocket


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

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(); } }

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) {

Create datagram socket at port 9876

Create space for received datagram Receive datagram

DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); serverSocket.receive(receivePacket);

Example: Java server (UDP), cont
String sentence = new String(receivePacket.getData());

Get IP addr port #, of sender

InetAddress IPAddress = receivePacket.getAddress(); int port = receivePacket.getPort(); String capitalizedSentence = sentence.toUpperCase(); sendData = capitalizedSentence.getBytes();

Create datagram to send to client Write out datagram to socket

DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, port); serverSocket.send(sendPacket); } }

End of while loop, loop back and wait for another client connection


Chapter 2: Summary
Our study of network apps now complete!
Ì application service Ì specific protocols: r http r ftp r smtp, pop3 r dns Ì socket programming r client/server implementation r using tcp, udp sockets


reliability, bandwidth, delay

Ì client-server paradigm Ì Internet transport

service model


connection-oriented, reliable: TCP unreliable, datagrams: UDP


Chapter 2: Summary
Most importantly: learned about protocols
Ì typical request/reply

message exchange:

Ì control vs. data msgs Ì Ì Ì Ì Ì


client requests info or service server responds with data, status code

Ì message formats: r headers: fields giving info about data r data: info being communicated

in-based, out-of-band centralized vs. decentralized stateless vs. stateful reliable vs. unreliable msg transfer “complexity at network edge” security: authentication


Sign up to vote on this title
UsefulNot useful