Application Layer

2: Application Layer 1
Network applications: some jargon

Process: program running user agent: interfaces

within a host. with user “above” and
r within same host, two network “below”.
processes communicate r implements user
using interprocess interface &
communication (defined application-level
by OS). protocol
r processes running in m Web: browser
different hosts m E-mail: mail reader
communicate with an m streaming audio/video:
application-layer media player
protocol
2: Application Layer 2
Applications and application-layer protocols

Application: communicating, application

transport
distributed processes network
data link
m e.g., e-mail, Web, P2P file physical

sharing, instant messaging

m running in end systems
(hosts)
m exchange messages to
implement application
Application-layer protocols
m one “piece” of an app application
application
transport
transport
m define messages network
network
data link
exchanged by apps and data link
physical
physical

actions taken
m use communication services
provided by lower layer
protocols (TCP, UDP)
2: Application Layer 3
App-layer protocol defines
r Types of messages Public-domain protocols:
exchanged, eg, request r defined in RFCs
& response messages r allows for
r Syntax of message interoperability
types: what fields in r eg, HTTP, SMTP
messages & how fields
are delineated Proprietary protocols:
r eg, BitTorrent
r Semantics of the
fields, ie, meaning of
information in fields
r Rules for when and
how processes send &
respond to messages 2: Application Layer 4
Client-server paradigm
Typical network app has two application

pieces: client and server

transport
network
data link
physical

Client: request
r initiates contact with server
(“speaks first”)
r typically requests service from
server,
reply
r Web: client implemented in
browser; e-mail: in mail reader application
transport

Server:
network
data link
physical
r provides requested service to client
r e.g., Web server sends requested Web
page, mail server delivers e-mail

2: Application Layer 5
HTTP Client/Server Eg

HTTP: hypertext HT
transfer protocol
TP
req
HT ues
TP t
r Client/server model PC running res
pon
m Client: browser
Chrome se
that
requests, receives, ue
st
“displays” Web objects r eq
e
T TP o ns
H p Web Server
m Server: Web server P res
T e.g., Apache HTTP
HT
sends objects in server, nginx, etc.
response to requests
Mac running
r HTTP 1.0: RFC 1945
Safari
r HTTP 1.1: RFC 2068

6
 Processes communicating across network
host or host or
r process sends/receives server server
messages to/from its
socket controlled by
app developer
r socket analogous to door process process

m sending process shoves socket socket

message out door TCP with TCP with
Internet buffers,
buffers,
m sending process asssumes variables variables
transport infrastructure
on other side of door which
controlled
brings message to socket by OS
at receiving process

2: Application Layer 7
Addressing processes:
r For a process to r Identifier includes
receive messages, it both the IP address
must have an identifier and port numbers
r Every host has a unique associated with the
32-bit IP address process on the host.
r Q: does the IP address r Example port numbers:
of the host on which m HTTP server: 80
the process runs m Mail server: 25
suffice for identifying r More on this later
the process?
r Answer: No, many
processes can be
running on same host
2: Application Layer 8
What transport service does an app need?
Data loss
r some apps (e.g., audio) can
tolerate some loss
r other apps (e.g., file
transfer, telnet) require
100% reliable data
transfer
Timing
r some apps (e.g.,
Internet telephony,
interactive games)
require low delay to be
“effective”
Bandwidth
r some apps (e.g.,
multimedia) require
minimum amount of
bandwidth to be
“effective”
r other apps (“elastic
apps”) make use of
whatever bandwidth
they get
2: Application Layer 9
 Transport service requirements of common apps

Application Data loss Bandwidth Time Sensitive

file transfer no loss elastic no

e-mail no loss elastic no
Web documents no loss elastic no
real-time audio/video loss-tolerant audio: 5kbps-1Mbps yes, 100’s msec
video:10kbps-5Mbps
stored audio/video loss-tolerant same as above yes, few secs
interactive games loss-tolerant few kbps up yes, 100’s msec
instant messaging no loss elastic yes and no

2: Application Layer 10
Internet transport protocols services
TCP service:
r connection-oriented: setup
required between client and
server processes
r reliable transport between
sending and receiving process
r flow control: sender won’t
overwhelm receiver
r congestion control: throttle
sender when network
overloaded
r does not provide timing: no
minimum bandwidth
guarantees
UDP service:
r unreliable data transfer
between sending and
receiving process
r does not provide:
connection setup,
reliability, flow control,
congestion control, timing,
or bandwidth guarantee
Q: why bother? Why is
there a UDP?
2: Application Layer 11
Internet apps: application, transport protocols

Application Underlying
Application layer protocol transport protocol

e-mail SMTP [RFC 5321] TCP

remote terminal access Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
file transfer FTP [RFC 959] TCP
streaming multimedia HTTP TCP
(e.g. YouTube)
Internet telephony SIP, RTP or proprietary
(e.g., Skype) UDP or TCP

Session Initiation Protocol (SIP) is a signaling protocol used for initiating, maintaining, modifying and
terminating real-time sessions that involve video, voice, messaging and other communications applications and
services between two or more endpoints on IP networks (Whatis.com). The Real-Time Transport Protocol (RTP)
is an Internet protocol standard that specifies a way for programs to manage the real-time transmission of
multimedia data over either unicast or multicast network services. (techtarget)
2: Application Layer 12
Electronic Mail outgoing
message queue
user mailbox
user
Three major components: agent
r user agents mail
user
server
r mail servers agent
r simple mail transfer SMTP mail
protocol: SMTP server user
SMTP agent
User Agent
r a.k.a. “mail reader” SMTP
mail user
r composing, editing, reading agent
server
mail messages
r e.g., Eudora, Outlook, elm user
agent
r outgoing, incoming messages
user
stored on server agent

2: Application Layer 13
Sample SMTP interaction
At start, telnet to server.

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

2: Application Layer 14
Mail message format
SMTP: protocol for
exchanging email msgs header
RFC 822: standard for text blank
message format (so that line
receiving UA can render
the email):
r header lines, e.g., body
m To:
m From:
m Subject:
different from SMTP
commands!
r body
m the “message”, ASCII
characters only

2: Application Layer 15
 Message format: multimedia extensions
r MIME: multimedia mail extension, RFC 2045, 2056
r additional lines in msg header declare MIME content
type

From: alice@crepes.fr
MIME version To: bob@hamburger.edu
Subject: Picture of yummy crepe.
method used MIME-Version: 1.0
to encode data Content-Transfer-Encoding: base64
Content-Type: image/jpeg
multimedia data
type, subtype, base64 encoded data .....
parameter declaration .........................
......base64 encoded data
encoded data

2: Application Layer 16
Mail access protocols
SMTP SMTP access user
user
agent protocol agent

sender’s mail receiver’s mail

server server

r SMTP: delivery/storage to receiver’s server

r Mail access protocol: retrieval from server
m POP: Post Office Protocol [RFC 1939]
• authorization (agent <-->server) and download
m IMAP: Internet Mail Access Protocol [RFC 1730]
• more features (more complex)
• manipulation of stored msgs on server
m HTTP: Hotmail , Yahoo! Mail, etc.

2: Application Layer 17
POP3 protocol S: +OK POP3 server ready
C: user bob
authorization phase S: +OK
C: pass hungry
r client commands: S: +OK user successfully logged on
m user: declare username
C: list
m pass: password S: 1 498
r server responses S: 2 912
S: .
m +OK
C: retr 1
m -ERR S: <message 1 contents>
transaction phase, client: S: .
C: dele 1
r list: list message numbers C: retr 2
r retr: retrieve message by S: <message 2 contents>
number S: .
C: dele 2
r dele: delete
C: quit
r quit S: +OK POP3 server signing off
2: Application Layer 18
POP3 (more) and IMAP
More about POP3 IMAP
r Previous example uses r Keep all messages in
“download and delete” one place: the server
mode. r Allows user to
r Bob cannot re-read e- organize messages in
mail if he changes folders
client r IMAP keeps user state
r “Download-and-keep”: across sessions:
copies of messages on m names of folders and
different clients mappings between
message IDs and folder
r POP3 is stateless
name
across sessions

2: Application Layer 19
Socket programming
goal: learn how to build client/server applications
that communicate using sockets
socket: door between application process and
end-end-transport protocol

application application
socket controlled by
process process app developer

transport transport
network network controlled
link link by OS
Internet
physical physical

Application Layer 2-20

 Socket programming

Two socket types for two transport services:

m UDP: unreliable datagram

m TCP: reliable, byte stream-oriented

Application Example:
1. Client reads a line of characters (data) from its
keyboard and sends the data to the server.
2. The server receives the data and converts
characters to uppercase.
3. The server sends the modified data to the client.
4. The client receives the modified data and displays
the line on its screen.

Application Layer 2-21

Socket programming with UDP
UDP: no “connection” between client &
server
r no handshaking before sending data
r sender explicitly attaches IP destination address and port
# to each packet
r rcvr extracts sender IP address and port# from received
packet

UDP: transmitted data may be lost or

received out-of-order
Application viewpoint:
r UDP provides unreliable transfer of groups of bytes
(“datagrams”) between client and server

Application Layer 2-22

 datagram
service
Client/server socket interaction: (SOCK_DGRAM)

UDP
server (running on serverIP) client
create socket:
create socket, port= x: clientSocket =
serverSocket = socket(AF_INET,SOCK_DGRAM)
socket(AF_INET,SOCK_DGRAM)
Create datagram with server IP and
IP address port=x; send datagram via
family read datagram from clientSocket
serverSocket
(AF_INET)
write reply to
serverSocket read datagram from
specifying clientSocket
client address,
port number close
clientSocket

Application 2-23
 Example app: UDP client Documentation
https://docs.python.org/

Python UDPClient
include Python’s socket
library from socket import *
serverName = ‘localhost’
serverPort = 12000
create UDP socket for
clientSocket = socket(socket.AF_INET,
server socket.SOCK_DGRAM)
get user keyboard message = raw_input(’Input lowercase sentence:’) #string
input
Attach server name, port clientSocket.sendto(message,(serverName, serverPort))
to message; send into modifiedMessage, serverAddress =
socket
read reply characters from clientSocket.recvfrom(2048)
socket into string
print modifiedMessage address
print out received string
and close socket
clientSocket.close()
raw_input([prompt])If the prompt argument is present, it is written to standard output without a trailing newline.
The function then reads a line from input, converts it to a string (stripping a trailing newline), and returns that.
socket.sendto(string, address) Send data to the socket. The socket should not be connected to a remote socket,
since the destination socket is specified by address. socket.recvfrom(bufsize)-Receive data from the socket.
The return value is a pair (string, address) where string is a string representing the data received and address is
the address of the socket sending the data.
Application Layer 2-24
 Example app: UDP server
Python UDPServer
from socket import *
serverPort = 12000
create UDP socket
serverSocket = socket(AF_INET, SOCK_DGRAM)
bind socket to local port serverSocket.bind(('‘'‘ , serverPort))
number 12000 print “The server is ready to receive”
while 1:
loop forever message, clientAddress = serverSocket.recvfrom(2048)
Read from UDP socket modifiedMessage = message.upper()
into message, getting
client’s address (client IP
serverSocket.sendto(modifiedMessage, clientAddress)
and port)
send upper case string
back to this client

socket.bind(address). Bind the socket to address.

Application Layer 2-25

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

Application Layer 2-26

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

wait for incoming create socket,

connection request
TCP connect to hostid, port=x
connectionSocket = connection setup clientSocket = socket()
serverSocket.accept()

send request using

read request from clientSocket
connectionSocket

write reply to
connectionSocket read reply from
clientSocket
close
connectionSocket close
clientSocket

Application Layer 2-27

 Example app: TCP client
Python TCPClient
from socket import *
serverName = ’servername’
create TCP socket for serverPort = 12000
server, remote port
12000 clientSocket = socket(AF_INET, SOCK_STREAM)
No need to attach server clientSocket.connect((serverName,serverPort))
name, port
sentence = raw_input(‘Input lowercase sentence:’)
clientSocket.send(sentence)
modifiedSentence = clientSocket.recv(1024)
print ‘From Server:’, modifiedSentence
clientSocket.close()

socket.recv(bufsize) Receive data from the socket. The return value is a string representing the data received. The
maximum amount of data to be received at once is specified by bufsize.

Application Layer 2-28

 Example app: TCP server
create TCP welcoming
socket
server begins listening for
incoming TCP requests
loop forever
server waits on accept()
for incoming requests, new
socket created on return
read bytes from socket (but
not address as in UDP)
close connection to this
client (but not welcoming
socket)
Python TCPServer
from socket import *
serverPort = 12000
serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind((‘’,serverPort))
serverSocket.listen(1)
print ‘The server is ready to receive’
while 1:
connectionSocket, addr = serverSocket.accept()
sentence = connectionSocket.recv(1024)
capitalizedSentence = sentence.upper()
connectionSocket.send(capitalizedSentence)
connectionSocket.close()
Application Layer 2-
29
Software

Version may not

be exact

You need to
learn to write
Python network
Programming
code

Application Layer 2-30