Thanks and enjoy! JFK/KWR Chapter 2webhost.bridgew.edu/sattar/CS430/misc/pdf/CH2.pdf · 2.8 Socket...
60
Chapter 2 Application Layer 2: Application Layer 1 Computer Networking: A Top Down Approach, 5 th edition. Jim Kurose, Keith Ross Addison-Wesley, April 2009. A note on the use of these ppt slides: We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following: If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!) If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material. Thanks and enjoy! JFK/KWR All material copyright 1996-2009 J.F Kurose and K.W. Ross, All Rights Reserved 2: Application Layer 2
Transcript of Thanks and enjoy! JFK/KWR Chapter 2webhost.bridgew.edu/sattar/CS430/misc/pdf/CH2.pdf · 2.8 Socket...
Chapter 2
Application Layer
2: A
pplication Layer1
Com
puter Netw
orking: A Top D
own A
pproach,
5thedition.
Jim Kurose, K
eith Ross
Addison-W
esley, April
2009.
A n
ote
on
the
use
of th
ese
pp
t slid
es:
We’re
ma
kin
g th
ese
slid
es fre
ely
ava
ilab
le to
all (fa
cu
lty, stu
de
nts
, rea
de
rs).
Th
ey’re
in P
ow
erP
oin
t form
so
yo
u c
an
ad
d, m
od
ify, an
d d
ele
te s
lide
s
(inclu
din
g th
is o
ne
) an
d s
lide
co
nte
nt to
su
it yo
ur n
ee
ds. T
he
y o
bvio
usly
rep
rese
nt a
lot
of w
ork
on
ou
r pa
rt. In re
turn
for u
se
, we
on
ly a
sk th
e
follo
win
g:
�If y
ou
use
the
se
slid
es (e
.g., in
a c
lass) in
su
bsta
ntia
lly u
na
ltere
d fo
rm,
tha
t yo
u m
en
tion
the
ir so
urc
e (a
fter a
ll, we
’d lik
e p
eo
ple
to u
se
ou
r bo
ok!)
�If y
ou
po
st a
ny s
lide
s in
su
bsta
ntia
lly u
na
ltere
d fo
rm o
n a
ww
w s
ite, th
at
yo
u n
ote
tha
t the
y a
re a
da
pte
d fro
m (o
r pe
rha
ps id
en
tica
l to) o
ur s
lide
s, a
nd
no
te o
ur c
op
yrig
ht o
f this
ma
teria
l.
Th
an
ks a
nd
en
joy! J
FK
/KW
R
All m
ate
rial c
op
yrig
ht 1
99
6-2
009
J.F
Ku
rose
an
d K
.W. R
oss, A
ll Rig
hts
Re
se
rve
d
2: A
pplication Layer2
Chapter 2
: Application layer
r2.1 Principles of netw
ork applications
r2.2 W
eb and
HTTP
r2.3 FTP
r2.4 Electronic M
ail
r2.6 P2
P applications
r2.7 Socket program
ming
with
UDP
r2.8 Socket program
ming
with
TCP
2: A
pplication Layer3
r2.4 Electronic M
ail�SMTP, PO
P3, IM
AP
r2.5 DNS
with
TCP
Chapter 2
: Application Layer
Our goals:
rconceptual, implem
entation aspects of netw
ork application protocols
transport-layer
rlearn ab
out protocols by ex
amining popular
application-level protocols�HTTP
FTP
2: A
pplication Layer4
�transport-layer service m
odels
�client-server parad
igm
�peer-to-peer parad
igm
�FTP
�SMTP / PO
P3 / IM
AP
�DNS
rprogram
ming netw
ork applications
�socket A
PI
Som
e network apps
re-m
ail
rweb
rinstant m
essaging
rrem
ote login
P2P file sh
aring
rsocial netw
orks
rvoice over IP
rreal-tim
e video
conferencing
rgrid
computing
2: A
pplication Layer5
rP2P file sh
aring
rmulti-user netw
ork gam
es
rstream
ing stored vid
eo clips
rgrid
computing
Creating a netw
ork app
write program
s that
�run on (d
ifferent) end system
s�com
municate over netw
ork
�e.g., w
eb server softw
are com
municates w
ith brow
ser
applicationtransportnetw
orkdata linkphysical
2: A
pplication Layer6
communicates w
ith brow
ser softw
are
No need
to write softw
are for netw
ork-core devices
�Netw
ork-core devices d
o not run user applications
�applications on end
systems
allows for rapid
app developm
ent, propagation
applicationtransportnetw
orkdata linkphysical
applicationtransportnetw
orkdata linkphysical
Chapter 2
: Application layer
r2.1 Principles of netw
ork applications
r2.2 W
eb and
HTTP
r2.3 FTP
r2.4 Electronic M
ail
r2.6 P2
P applications
r2.7 Socket program
ming
with
UDP
r2.8 Socket program
ming
with
TCP
2: A
pplication Layer7
r2.4 Electronic M
ail�SMTP, PO
P3, IM
AP
r2.5 DNS
with
TCP
Application arch
itectures
rClient-server�Includ
ing data centers / cloud
computing
rPeer-to-peer (P2
P)
rHybrid
of client-server and P2
P
2: A
pplication Layer8
rHybrid
of client-server and P2
P
Client-server arch
itecture
server:
�alw
ays-on host
�perm
anent IP address
�server farm
s for scaling
2: A
pplication Layer9
scaling
clients:�com
municate w
ith server
�may b
e intermittently
connected
�may h
ave dynam
ic IP addresses
�do not com
municate
directly w
ith each
other
client/server
Google D
ata Centers
rEstim
ated cost of d
ata center: $600M
rGoogle spent $
2.4B in 2
007 on new
data
centers
rEach
data center uses 5
0-10
0 megaw
atts rEach
data center uses 5
0-10
0 megaw
atts of pow
er
Pure P2P arch
itecture
rno
always-on server
rarb
itrary end system
s directly com
municate
rpeers are interm
ittently connected
and ch
ange IP
peer-peer
2: A
pplication Layer11
connected and
change IP
addresses
High
ly scalable b
ut difficult to m
anage
Hybrid
of client-server and P2
PSkype
�voice-over-IP P2
P application�centralized
server: finding ad
dress of rem
ote party:
�client-client connection: d
irect (not through
server)
Instant messaging
2: A
pplication Layer1
2
Instant messaging
�chatting b
etween tw
o users is P2P
�centralized
service: client presence detection/location•user registers its IP ad
dress w
ith central
server when it com
es online•user contacts central server to find
IP addresses of b
uddies
Processes communicating
Process:program
running with
in a host.
rwith
in same h
ost, two
processes communicate
using inter-process
Client process:
process that initiates
communication
Server process:
process that w
aits to be
contacted2: A
pplication Layer1
3
using inter-process com
munication
(defined
by O
S).
rprocesses in d
ifferent hosts com
municate b
y exchanging m
essages
that w
aits to be
contacted
rNote: applications w
ith
P2P arch
itectures have
client processes &
server processes
Sockets
rprocess send
s/receives messages to/from
its socket
rsocket analogous to d
oor�send
ing process shoves
pro
cess
sock
et
ho
st or
server
pro
cess
sock
et
ho
st or
server
con
trolled
by
app
dev
elop
er
2: A
pplication Layer1
4
�send
ing process shoves
message out d
oor
�send
ing process relies on transport infrastructure on oth
er side of d
oor which
brings m
essage to socket at receiving process
TC
P w
ith
bu
ffers,
variab
les
TC
P w
ith
bu
ffers,
variab
les
Intern
et
con
trolled
by O
S
rAPI: (1) ch
oice of transport protocol; (2) ab
ility to fix
a few param
eters (lots more on th
is later)
Addressing processes
rto receive m
essages, process m
ust have
identifierrhost d
evice has unique
32-bit IP ad
dress
rExercise:
use ipconfig
rQ:does IP ad
dress of
host on w
hich
process runs suffice for identifying th
e process?
�A:No, m
anyprocesses
can be running on
same
2: A
pplication Layer1
5
rExercise:
use ipconfig
from com
mand
prompt to
get your IP address
(Wind
ows)
same
rIdentifier
includes b
oth
IP address
and port
numbers
associated with
process on h
ost.
rExam
ple port numbers:
�HTTP server: 8
0
�Mail server: 2
5
App-layer protocol d
efines
rTypes of m
essages exchanged
, �e.g., request, response
rMessage syntax
:�what field
s in messages &
Public-d
omain protocols:
rdefined
in RFCs
rallow
s for interoperab
ility
re.g., H
TTP, S
MTP,
2: A
pplication Layer1
6
�what field
s in messages &
how field
s are delineated
rMessage sem
antics �meaning of inform
ation in field
s
rRules for w
hen and
how
processes send &
respond to m
essages
re.g., H
TTP, S
MTP,
BitT
orrent
Proprietary protocols:
re.g., S
kype, ppstream
What transport service d
oes an app need?
Data loss
rsom
e apps (e.g., audio) can
tolerate some loss
roth
er apps (e.g., file transfer, telnet) require 100% reliab
le data
transfer
Through
put
rsom
e apps (e.g., multim
edia) require
minim
um am
ount of through
put to be
“effective”
2: A
pplication Layer1
7
transferTiming
rsom
e apps (e.g., Internet teleph
ony, interactive gam
es) require low
delay to b
e “effective”
roth
er apps (“elastic apps”) make use of w
hatever
through
put they get
Security
rEncryption, d
ata integrity, …
Transport service requirem
ents of common apps
Ap
plic
atio
n
file tra
nsfe
re
-ma
ilW
eb
do
cu
me
nts
rea
l-time
au
dio
/vid
eo
Da
ta lo
ss
no
loss
no
loss
no
loss
loss-to
lera
nt
Th
rou
gh
pu
t
ela
stic
ela
stic
ela
stic
au
dio
: 5kb
ps-1
Mb
ps
Tim
e S
en
sitiv
e
no
no
no
ye
s, 1
00
’s m
se
c
2: A
pplication Layer1
8
rea
l-time
au
dio
/vid
eo
sto
red
au
dio
/vid
eo
inte
ractiv
e g
am
es
insta
nt m
essa
gin
g
loss-to
lera
nt
loss-to
lera
nt
loss-to
lera
nt
no
loss
au
dio
: 5kb
ps-1
Mb
ps
vid
eo
:10
kb
ps-5
Mbp
ssa
me
as a
bo
ve
fe
w k
bp
s u
pe
lastic
ye
s, 1
00
’s m
se
c
ye
s, fe
w s
ecs
ye
s, 1
00
’s m
se
cye
s a
nd
no
Internet transport protocols services
TCP service:
rconnection-oriented:
setup required
betw
een client and
server processes
rreliable transport b
etween
sending and
receiving process
UDP service:
runreliab
le data transfer
betw
een sending and
receiving process
rdoes not provid
e: connection setup,
2: A
pplication Layer1
9
sending and
receiving process
rflow
control:send
er won’t
overwhelm
receiver
rcongestion control:
throttle
sender w
hen netw
ork overload
ed
rdoes not provide:
timing,
minim
um th
roughput
guarantees, security
connection setup, reliab
ility, flow control,
congestion control, timing,
through
put guarantee, or security
Q:why b
other? W
hy is
there a U
DP?
Internet apps: application, transport protocols
Ap
plic
atio
n
e-m
ail
rem
ote
term
ina
l acce
ss
We
b
file tra
nsfe
r
Ap
plic
atio
nla
ye
r pro
toc
ol
SM
TP
[RF
C 2
82
1]
Te
lne
t [RF
C 8
54
]H
TT
P [R
FC
26
16
]F
TP
[RF
C 9
59
]
Un
de
rlyin
gtra
ns
po
rt pro
toc
ol
TC
PT
CP
TC
PT
CP2: A
pplication Layer2
0
file tra
nsfe
rstre
am
ing
mu
ltime
dia
Inte
rne
t tele
ph
on
y
FT
P [R
FC
95
9]
HT
TP
(eg
Yo
utu
be
), R
TP
[RF
C 1
88
9]
SIP
, RT
P, p
rop
rieta
ry(e
.g., S
kyp
e)
TC
PT
CP
or U
DP
typ
ica
lly U
DP
Chapter 2
: Application layer
r2.1 Principles of netw
ork applications
r2.2 W
eb and
HTTP
r2.3 FTP
r2.4 Electronic M
ail
r2.6 P2
P applications
r2.7 Socket program
ming
with
UDP
r2.8 Socket program
ming
with
TCP
2: A
pplication Layer2
1
r2.4 Electronic M
ail�SMTP, PO
P3, IM
AP
r2.5 DNS
with
TCP
Web and
HTTP
First som
e jargon
rWeb page
consists of objects
rObject can b
e HTML file, J
PEG im
age, Java
applet, audio file,…
rWeb page consists of b
ase HTML-file
which
2: A
pplication Layer2
2
rWeb page consists of b
ase HTML-file
which
includ
es several referenced ob
jects
rEach
object is ad
dressab
le by a U
RL
rExam
ple URL:
www.someschool.edu/someDept/pic.gif
host nam
epath
name
HTTP overview
HTTP: h
ypertext
transfer protocolr
Web’s application layer
protocol
rclient/server m
odel
PC running
Explorer
2: A
pplication Layer2
3
�client:
brow
ser that
requests, receives, “displays” W
eb ob
jects
�server:
Web server
sends ob
jects in response to requests
Server
runningApach
e Web
server
Mac runningNavigator
HTTP overview
(continued)
Uses T
CP:
rclient initiates T
CP
connection (creates socket) to server, port 8
0
rserver accepts T
CP
connection from client
HTTP is “stateless”
rserver m
aintains no inform
ation about
past client requests
Protocols that m
aintain aside
2: A
pplication Layer2
4
connection from client
rHTTP m
essages (application-layer protocol m
essages) exchanged
betw
een brow
ser (HTTP client) and
Web
server (HTTP server)
rTCP connection closed
Protocols that m
aintain “state” are com
plex!
rpast h
istory (state) must
be m
aintained
rif server/client crash
es, their view
s of “state” may
be inconsistent, m
ust be
reconciled
aside
HTTP connections
Nonpersistent H
TTP
rAt m
ost one object is
sent over a TCP
connection.
Persistent HTTP
rMultiple ob
jects can be sent over single TCP connection
betw
een client and
2: A
pplication Layer2
5
betw
een client and
server.
Nonpersistent H
TTP
Suppose user enters U
RL
www.someSchool.edu/someDepartment/home.index
1a.H
TTP client initiates T
CP
connection to HTTP server
(process) at w
ww
.som
eS
choo
l.edu o
n p
ort 8
0
1b.H
TTPserver at h
ost w
ww
.som
eS
ch
ool.e
du waiting
for TCP connection at port 8
0.
“accepts” connection, notifying
(conta
ins te
xt,
refe
rences to
10
jpeg im
ages)
2: A
pplication Layer2
6
2.H
TTPclient send
s HTTP
request message
(containing URL) into T
CP connection
socket. Message ind
icates that client w
ants object
som
eD
epartm
ent/h
om
e.in
dex
for TCP connection at port 8
0.
“accepts” connection, notifying client
3.H
TTPserver receives request
message, form
s response message
containing requested
object, and
sends m
essage into its socket
time
Nonpersistent H
TTP (cont.)
5.H
TTP client receives response
message containing h
tml file,
displays h
tml. Parsing h
tml
file, finds 10
referenced jpeg
objects
4.H
TTPserver closes T
CP
connection.
time
2: A
pplication Layer2
7
objects
6.Steps 1-5
repeated for each
of 10
jpeg objects
timeNon-Persistent H
TTP: R
esponse time
Definition of R
TT:tim
e for a sm
all packet to travel from
client to server and
back.
Response tim
e:
rone R
TT to initiate T
CP
initiate TCP
connectionRTT
request
2: A
pplication Layer2
8
rone R
TT to initiate T
CP
connection
rone R
TT for H
TTP
request and first few
bytes of H
TTP response
to return
rfile transm
ission time
total = 2RTT+transm
it time
time to
transmit
file
requestfile
RTT
filereceivedtim
etim
e
Persistent HTTP
Nonpersistent H
TTP issues:
rrequires 2
RTTs per ob
ject
rOS overh
ead for each
TCP
connection
rbrow
sers often open parallel TCP connections to fetch
Persistent HTTP
rserver leaves connection open after send
ing response
rsub
sequent HTTP m
essages betw
een same
client/server sent over
2: A
pplication Layer2
9
TCP connections to fetch
referenced
objects
betw
een same
client/server sent over open connection
rclient send
s requests as soon as it encounters a referenced
object
ras little as one R
TT for all
the referenced
objects
HTTP request m
essage
rtwo types of H
TTP m
essages: request, responserHTTP request m
essage:�ASCII (h
uman-read
able form
at)
request line(GET, PO
ST,
2: A
pplication Layer3
0
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
User-agent: Mozilla/4.0
Connection: close
Accept-language:fr
(extra
ca
rriag
e re
turn
, line
fee
d)
request line(GET, PO
ST,
HEAD com
mand
s)
head
erlines
Carriage return, line feed
ind
icates end
of message
HTTP request m
essage: general format
2: A
pplication Layer3
1
Upload
ing form input
Post meth
od:
rWeb page often
includes form
input
rInput is upload
ed to
server in entity body
URL m
ethod:
rUses G
ET meth
od
rInput is upload
ed in
2: A
pplication Layer3
2
server in entity body
rInput is upload
ed in
URL field
of request line:
www.somesite.com/animalsearch?monkeys&banana
Meth
od types
HTTP/1.0
rGET
rPO
ST
rHEAD
asks server to leave
HTTP/1.1
rGET, PO
ST, H
EAD
rPU
T�upload
s file in entity body to path
specified
2: A
pplication Layer3
3
�asks server to leave requested
object out of
response
body to path
specified
in URL field
rDELETE
�deletes file specified
in the U
RL field
HTTP response m
essage
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 …...
status line(protocolstatus cod
estatus ph
rase)
head
erlines
2: A
pplication Layer3
4
Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html
data data data data data ...
lines
data, e.g., requestedHTML file
HTTP response status cod
es
200 OK
�request succeed
ed, requested
object later in th
is message
301 Moved Permanently
In first line in server->client response message.
A few
sample cod
es:
2: A
pplication Layer3
5
301 Moved Permanently
�requested
object m
oved, new
location specified later in
this m
essage (Location:)
400 Bad Request
�request m
essage not understood
by server
404 Not Found
�requested
docum
ent not found on th
is server
505 HTTP Version Not Supported
Trying out H
TTP (client sid
e) for yourself
1. Telnet to your favorite W
eb server:
Opens T
CP connection to port 8
0(default H
TTP server port) at cis.poly.ed
u.Anyth
ing typed in sent
to port 80 at cis.poly.ed
u
telnet cis.poly.edu 80
2: A
pplication Layer3
6
2. Type in a G
ET HTTP request:
GET /~ross/ HTTP/1.1
Host: cis.poly.edu
By typing th
is in (hit carriage
return twice), you send
this m
inimal (b
ut complete)
GET request to H
TTP server
3. Look at response m
essage sent by H
TTP server!
User-server state: cookies
Many m
ajor Web sites
use cookiesFour com
ponents:1) cookie h
eader line of
HTTP response
message
2) cookie h
eader line in
Exam
ple:
rSusan alw
ays access Internet alw
ays from PC
rvisits specific e-com
merce site for first
time
2: A
pplication Layer3
7
2) cookie h
eader line in
HTTP request
message
3) cookie file kept on user’s h
ost, managed
by
user’s brow
ser4) b
ack-end datab
ase at Web site
time
rwhen initial H
TTP
requests arrives at site, site creates:
�unique ID
�entry in b
ackend
datab
ase for ID
Cookies: keeping “state” (cont.)
clientserver
cookie file
eb
ay 8
73
4usual h
ttp request msg
Amazon server
creates ID1678 for user
createentry
usual http response
Set-cookie: 1678
eb
ay 8
73
4
am
azo
n 1
67
8
2: A
pplication Layer3
8
usual http response m
sg
usual http response m
sg
one week later:
usual http request m
sgcookie: 1678
cookie-specificaction
access
am
azo
n 1
67
8
usual http request m
sgcookie: 1678
cookie-spectificaction
accesse
ba
y 8
73
4
am
azo
n 1
67
8
backenddatab
ase
Cookies (continued
)
What cookies can b
ring:
rauth
orization
rshopping carts
rrecom
mend
ations
ruser session state
Cookies and
privacy:
rcookies perm
it sites to learn a lot ab
out you
ryou m
ay supply name
and e-m
ail to sites
aside
2: A
pplication Layer3
9
ruser session state (W
eb e-m
ail)
and e-m
ail to sites
How to keep “state”:
rprotocol end
points: maintain state
at sender/receiver over m
ultiple transactions
rcookies: h
ttp messages carry state
Web cach
es (proxy server)
ruser sets b
rowser:
Web accesses via
cache
rbrow
ser sends all
Goal:
satisfy client request with
out involving origin server
client
Proxy
server
origin server
2: A
pplication Layer4
0
rbrow
ser sends all
HTTP requests to
cache
�object in cach
e: cache
returns object
�else cach
e requests object from
origin server, th
en returns object to client
clientserver
clientorigin server
More ab
out Web cach
ing
rcach
e acts as both
client and
server
rtypically cach
e is installed
by IS
P (university, com
pany,
Why W
eb cach
ing?
rred
uce response time
for client request
rred
uce traffic on an institution’s access
2: A
pplication Layer4
1
(university, company,
residential IS
P)institution’s access link.
rInternet d
ense with
cach
es: enables “poor”
content providers to
effectively deliver
content (but so d
oes P2P file sh
aring)
Cach
ing exam
ple
Assum
ptionsr
average object size =
1,000,000 bits
ravg. request rate from
institution’s b
rowsers to origin
servers = 15/sec
originservers
public
Internet15 Mbps
2: A
pplication Layer4
2
servers = 15/sec
rdelay from
institutional router to any origin server and
back
to router = 2 sec
Consequences
rutilization on LA
N = 15
%
rutilization on access link = 10
0%
rtotal d
elay = Internet delay +
access delay + LA
N delay
= 2 sec + m
inutes + millisecond
s
institutionalnetw
ork100 Mbps LA
N
15 Mbps
access link
institutionalcach
e
Cach
ing exam
ple (cont)
possible solution
rincrease b
andwidth of access
link to, say, 100 Mbps
consequencer
utilization on LAN = 15
%
rutilization on access link = 15
%
originservers
public
Internet100 Mbps
2: A
pplication Layer4
3
rutilization on access link = 15
%
rTotal d
elay = Internet delay +
access delay + LA
N delay
= 2 sec + m
secs+ m
secs
roften a costly upgrad
e
institutionalnetw
ork100 Mbps LA
N
100 Mbps
access link
institutionalcach
e
Cach
ing exam
ple (cont)
possible solution: install
cache
rsuppose h
it rate is 0.4
consequencer
40% requests w
ill be
satisfied alm
ost immediately
60% requests satisfied
by
originservers
public
Internet15 Mbps
2: A
pplication Layer4
4
satisfied alm
ost immediately
r60% requests satisfied
by
origin serverr
utilization of access link red
uced to 6
0%, resulting in
negligible d
elays (say 10
msec)
rtotal avg d
elay = Internet delay + access d
elay + LAN
delay = .6
*(2.01) secs +
.4*m
illiseconds < 1.4
secs
institutionalnetw
ork100 Mbps LA
N
15 Mbps
access link
institutionalcach
e
Cond
itional GET
rGoal:
don’t send
object if
cache h
as up-to-date cach
ed
version
rcach
e: specify date of
cached copy in H
TTP request
If-modified-since:
cache
server
HTTP request m
sgIf-modified-since:
<date>
HTTP response
object not
modified
2: A
pplication Layer4
5
If-modified-since:
<date>
rserver: response contains no object if cach
ed copy is up-
to-date:
HTTP/1.0 304 Not
Modified
HTTP/1.0
304 Not Modified
HTTP request m
sgIf-modified-since:
<date>
HTTP response
HTTP/1.0 200 OK
<data>
object
modified
Chapter 2
: Application layer
r2.1 Principles of netw
ork applications
r2.2 W
eb and
HTTP
r2.3 FTP
r2.4 Electronic M
ail
r2.6 P2
P applications
r2.7 Socket program
ming
with
UDP
r2.8 Socket program
ming
with
TCP
2: A
pplication Layer4
6
r2.4 Electronic M
ail�SMTP, PO
P3, IM
AP
r2.5 DNS
with
TCP
FTP: th
e file transfer protocol
file transferFTP
server
FTP
userinterface
FTP
client
local filesystem
remote file
system
user at h
ost
2: A
pplication Layer4
7
rtransfer file to/from
remote h
ost
rclient/server m
odel
�client:
side th
at initiates transfer (either to/from
rem
ote)
�server:
remote h
ost
rftp: R
FC 959
rftp server: port 2
1
system
FTP: separate control, d
ata connections
rFTP client contacts F
TP server
at port 21, T
CP is transport
protocol
rclient auth
orized over control
connection
rclient b
rowses rem
ote
FTP
clientFTP
server
TCP control connection
port 21
TCP d
ata connectionport 2
0
2: A
pplication Layer4
8
rclient b
rowses rem
ote directory b
y sending com
mand
s over control connection.
rwhen server receives file
transfer command
, server opens 2
ndTCP connection (for
file) to client
rafter transferring one file, server closes d
ata connection.
rserver opens anoth
er TCP
data connection to transfer anoth
er file.
rcontrol connection: “out of band
”
rFTP server m
aintains “state”: current d
irectory, earlier auth
entication
FTP com
mand
s, responses
Sam
ple command
s:r
sent as ASCII tex
t over control ch
annelr
USER username
rPASS password
Sam
ple return codes
rstatus cod
e and ph
rase (as in H
TTP)
r331 Username OK,
password required
125 data connection
2: A
pplication Layer4
9
rLISTreturn list of file in
current directory
rRETR filenameretrieves
(gets) file
rSTOR filenamestores
(puts) file onto remote
host
r125 data connection
already open;
transfer starting
r425 Can’t open data
connection
r452 Error writing
file
Chapter 2
: Application layer
r2.1 Principles of netw
ork applications
r2.2 W
eb and
HTTP
r2.3 FTP
r2.4 Electronic M
ail
r2.6 P2
P applications
r2.7 Socket program
ming
with
UDP
r2.8 Socket program
ming
with
TCP
2: A
pplication Layer5
0
r2.4 Electronic M
ail�SMTP, PO
P3, IM
AP
r2.5 DNS
with
TCP
Electronic M
ail
Three m
ajor components:
ruser agents
rmail servers
rsim
ple mail transfer
protocol: SMTP
user mailb
ox
outgoing message queue
server
useragent
user
server
useragent
SMTP
SMTP
2: A
pplication Layer5
1
User A
gent
ra.k.a. “m
ail reader”
rcom
posing, editing, read
ing mail m
essages
re.g., E
udora, O
utlook, elm,
Mozilla T
hund
erbird
routgoing, incom
ing messages
stored on server
serveruseragent
useragent
server
useragent
useragent
SMTP
SMTP
Electronic M
ail: mail servers
Mail S
erversr
mailb
oxcontains incom
ing messages for user
rmessage
queueof outgoing
(to be sent) m
ail messages
SMTP protocolb
etween m
ail
server
useragent
user
server
useragent
SMTP
2: A
pplication Layer5
2
rSMTP protocolb
etween m
ail servers to send
messages
�client: send
ing mail
server
�“server”: receiving m
ail server
serveruseragent
useragent
server
useragent
useragent
SMTP
SMTP
Electronic M
ail: SMTP [R
FC 2821]
ruses T
CP to reliab
ly transfer email m
essage from client
to server, port 25
rdirect transfer: send
ing server to receiving server
rthree ph
ases of transfer
�hand
shaking (greeting)
transfer of messages
2: A
pplication Layer5
3
�transfer of m
essages
�closure
rcom
mand
/response interaction
�com
mand
s:ASCII tex
t
�response:
status code and
phrase
rmessages m
ust be in 7
-bit A
SCII
Scenario: A
lice sends m
essage to Bob
1) Alice uses U
A to com
pose message and
“to” [email protected]
2) A
lice’s UA send
s message
to her m
ail server; message
placed in m
essage queue
3) C
lient side of S
MTP opens
TCP connection w
ith Bob’s
4) S
MTP client send
s Alice’s
message over th
e TCP
connection
5) B
ob’s m
ail server places the
message in B
ob’s m
ailbox
6) B
ob invokes h
is user agent to read
message
2: A
pplication Layer5
4
3) C
lient side of S
MTP opens
TCP connection w
ith Bob’s
mail server
to read message
useragent
server
serveruseragent
1
23
45
6
Sam
ple SMTP interaction
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <[email protected]>
S: 250 [email protected]... Sender ok
C: RCPT TO: <[email protected]>
S: 250 [email protected] ... Recipient ok
2: A
pplication Layer5
5
S: 250 [email protected] ... 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
Try S
MTP interaction for yourself:
rtelnet servername 25
rsee 2
20 reply from
server
renter H
ELO
, MAIL F
ROM, RCPT TO, D
ATA, Q
UIT
com
mand
s
above lets you send
email w
ithout using em
ail client
2: A
pplication Layer5
6
above lets you send
email w
ithout using em
ail client (read
er)
SMTP: final w
ords
rSMTP uses persistent
connections
rSMTP requires m
essage (head
er & body) to b
e in 7-
bit A
SCII
rSMTP server uses
Com
parison with
HTTP:
rHTTP: pull
rSMTP: push
rboth
have A
SCII
command
/response
2: A
pplication Layer5
7
rSMTP server uses
CRLF.CRLFto d
etermine
end of m
essage
command
/response interaction, status cod
es
rHTTP: each
object
encapsulated in its ow
n response m
sg
rSMTP: m
ultiple objects
sent in multipart m
sg
Mail m
essage format
SMTP: protocol for
exchanging em
ail msgs
RFC 822: stand
ard for tex
t message form
at:
rhead
er lines, e.g.,�
To:
head
er
body
blankline
2: A
pplication Layer5
8
�To:
�From
:
�Subject:
differentfrom
SMTP
commands!
rbody
�the “m
essage”, ASCII
characters only
body
Mail access protocols
rSMTP: d
elivery/storage to receiver’s server
useragent
sender’s m
ail server
useragent S
MTP
SMTP
accessprotocol
receiver’s mail
server
2: A
pplication Layer5
9
rSMTP: d
elivery/storage to receiver’s server
rMail access protocol: retrieval from
server
�PO
P: Post Office Protocol [R
FC 19
39]
•auth
orization (agent <-->server) and download
�IM
AP: Internet M
ail Access Protocol [R
FC 17
30]
•more features (m
ore complex
)
•manipulation of stored
msgs on server
�HTTP: gm
ail, Hotm
ail, Yahoo! M
ail, etc.
POP3 protocol
authorization ph
aser
client command
s: �user:declare usernam
e
�pass:passw
ord
rserver responses
+OK
C: list
S: 1 498
S: 2 912
S: .
S: +OK POP3 server ready
C: user bob
S: +OK
C: pass hungry
S: +OK
user successfully logged on
2: A
pplication Layer6
0
�+OK
�-ERR
transaction phase, client:
rlist:list m
essage numbers
rretr:retrieve m
essage by
number
rdele:delete
rquit
S: .
C: retr 1
S: <message 1 contents>
S: .
C: dele 1
C: retr 2
S: <message 1 contents>
S: .
C: dele 2
C: quit
S: +OK POP3 server signing off
POP3 (m
ore) and IM
AP
More ab
out POP3
rPrevious ex
ample uses
“download
and delete”
mode.
rBob cannot re-read
e-mail if h
e changes
IMAP
rKeep all m
essages in one place: th
e server
rAllow
s user to organize m
essages in fold
ers
2: A
pplication Layer6
1
mail if h
e changes
client
r“Download
-and-keep”:
copies of messages on
different clients
rPO
P3 is stateless
across sessions
folders
rIM
AP keeps user state
across sessions:�nam
es of folders and
mappings b
etween
message ID
s and fold
er nam
e
Chapter 2
: Application layer
r2.1 Principles of netw
ork applications
r2.2 W
eb and
HTTP
r2.3 FTP
r2.4 Electronic M
ail
r2.6 P2
P applications
r2.7 Socket program
ming
with
UDP
r2.8 Socket program
ming
with
TCP
2: A
pplication Layer6
2
r2.4 Electronic M
ail�SMTP, PO
P3, IM
AP
r2.5 DNS
with
TCP
DNS: D
omain N
ame S
ystem
People:many id
entifiers:�SSN, nam
e, passport #
Internet hosts, routers:
�IP ad
dress (3
2 bit) -
used for ad
dressing
Dom
ain Nam
e System
:r
distributed databaseimplem
ented in h
ierarchy of
many nam
e serversr
application-layer protocolhost, routers, nam
e servers to
2: A
pplication Layer6
3
used for ad
dressing
datagram
s
�“nam
e”, e.g., ww.yah
oo.com -used
by
hum
ans
Q:map b
etween IP
addresses and
name ?
host, routers, nam
e servers to com
municate to resolve
names
(address/nam
e translation)
�note: core Internet function, im
plemented
as application-layer protocol
�com
plexity at netw
ork’s “ed
ge”
DNS
Why not centralize D
NS?
rsingle point of failure
rtraffic volum
e
rdistant centralized
datab
ase
DNS services
rhostnam
e to IP address translation
rhost aliasing�Canonical, alias nam
es
2: A
pplication Layer6
4
datab
ase
rmaintenance
doesn’t scale!
�Canonical, alias nam
es
rmail server aliasing
rload
distrib
ution�replicated
Web
servers: set of IP addresses for one
canonical name
Root D
NS
Serv
ers
com
DN
S s
erv
ers
org
DN
S s
erv
ers
edu D
NS
serv
ers
poly.e
du
DN
S s
erv
ers
um
ass.e
du
DN
S s
erv
ers
yahoo.c
om
DN
S s
erv
ers
am
azon.c
om
DN
S s
erv
ers
pbs.o
rg
DN
S s
erv
ers
Distrib
uted, H
ierarchical D
atabase
2: A
pplication Layer6
5
DN
S s
erv
ers
DN
S s
erv
ers
Client w
ants IP for www.am
azon.com; 1
stapprox
:
rclient queries a root server to find
com DNS server
rclient queries com
DNS server to get am
azon.com
DNS server
rclient queries am
azon.com DNS server to get IP
address for w
ww.am
azon.com
DNS: R
oot name servers
rcontacted
by local nam
e server that can not resolve nam
e
rroot nam
e server:
�contacts auth
oritative name server if nam
e mapping not know
n
�gets m
apping
�returns m
apping to local name server
a V
eris
ign, D
ulle
s, V
A
2: A
pplication Layer6
6
13 root nam
e servers w
orldwide
b U
SC
-ISI M
arin
a d
el R
ey, C
A
l ICA
NN
Los A
ngele
s, C
A
e N
AS
A M
t Vie
w, C
A
f Inte
rnet S
oftw
are
C. P
alo
Alto
,
CA
(an
d 3
6 o
the
r loca
tion
s)
i Auto
nom
ica, S
tockholm
(plu
s
28 o
ther lo
catio
ns)
k R
IPE
London (a
lso 1
6 o
ther lo
catio
ns)
m W
IDE
Tokyo
(als
o S
eoul,
Paris
, SF
)
a V
eris
ign, D
ulle
s, V
A
c C
ogent, H
ern
don, V
A (a
lso L
A)
d U
Maryla
nd C
olle
ge P
ark
, MD
g U
S D
oD
Vie
nna, V
A
h A
RL A
berd
een, M
Dj V
eris
ign
, ( 21
loca
tion
s)
TLD
and Auth
oritative Servers
rTop-level d
omain (T
LD) servers:
�responsib
le for com, org, net, ed
u, etc, and all
top-level country dom
ains uk, fr, ca, jp.�Netw
ork Solutions m
aintains servers for com TLD
�Educause for ed
u TLD
2: A
pplication Layer6
7
�Educause for ed
u TLD
rAuth
oritative DNS servers:
�organization’s D
NS servers, provid
ing auth
oritative hostnam
e to IP mappings for
organization’s servers (e.g., Web, m
ail).�can b
e maintained
by organization or service
provider
Local Nam
e Server
rdoes not strictly b
elong to hierarch
y
reach
ISP (resid
ential ISP, com
pany, university) h
as one.�also called
“default nam
e server”
2: A
pplication Layer6
8
also called “d
efault name server”
rwhen h
ost makes D
NS query, query is sent
to its local DNS server
�acts as prox
y, forward
s query into hierarch
y
root DNS server
local DNS server
dn
s.p
oly.e
du 2
3
45
TLD
DNS server
DNS nam
e resolution ex
ample
rHost at cis.poly.ed
u wants IP ad
dress for
gaia.cs.umass.ed
u
iterated query:
2: A
pplication Layer6
9
requesting host
cis
.po
ly.ed
u
ga
ia.c
s.u
ma
ss
.ed
u
dn
s.p
oly.e
du
16
authoritative D
NS server
dn
s.c
s.u
ma
ss
.ed
u
78
iterated query:
rcontacted
server replies w
ith nam
e of server to contact
r“I d
on’t know th
is nam
e, but ask th
is server”
root DNS server
local DNS server
2
67
TLD
DNS server
3recursive query:r
puts burd
en of name
resolution on contacted
name
server
heavy load
?
DNS nam
e resolution ex
ample
2: A
pplication Layer7
0
requesting host
cis
.po
ly.ed
u
ga
ia.c
s.u
ma
ss
.ed
u
local DNS server
dn
s.p
oly.e
du
1
45
authoritative D
NS server
dn
s.c
s.u
ma
ss
.ed
u
8
rheavy load
?
DNS: cach
ing and upd
ating records
ronce (any) nam
e server learns mapping, it caches
mapping
�cach
e entries timeout (d
isappear) after some
time
�TLD
servers typically cached in local nam
e servers
2: A
pplication Layer7
1
�TLD
servers typically cached in local nam
e servers•Thus root nam
e servers not often visited
rupd
ate/notify mech
anisms und
er design b
y IETF
�RFC 2136
�http://w
ww.ietf.org/h
tml.ch
arters/dnsind
-charter.h
tml
DNS record
s
DNS:distrib
uted db storing resource record
s (RR)
RR form
at: (name, value, type, ttl)
rType=A�nameis h
ostname
rType=C
NAME
�nameis alias nam
e for some
2: A
pplication Layer7
2
rType=N
S�nameis d
omain (e.g.
foo.com)
�valueis h
ostname of
authoritative nam
e server for th
is dom
ain
nameis h
ostname
�valueis IP ad
dress
�nameis alias nam
e for some
“canonical” (the real) nam
ewww.ibm.com is really
servereast.backup2.ibm.com
�valueis canonical nam
e
rType=M
X�valueis nam
e of mailserver
associated with
name
DNS protocol, m
essages
DNS protocol :query
and reply
messages, b
oth with
sam
e message form
at
msg h
eader
ridentification:
16 bit #
for query, reply to query uses sam
e #
2: A
pplication Layer7
3
for query, reply to query uses sam
e #
rflags:
�query or reply
�recursion d
esired
�recursion availab
le
�reply is auth
oritative
DNS protocol, m
essages
Nam
e, type fields
for a query
RRs in response
to query
2: A
pplication Layer7
4
to query
records for
authoritative servers
additional “h
elpful”info th
at may b
e used
Inserting records into D
NS
rexam
ple: new startup “N
etwork U
topia”rregister nam
e networkuptopia.com
at DNS registrar
(e.g., Netw
ork Solutions)
�provid
e names, IP ad
dresses of auth
oritative name server
(primary and
secondary)
�registrar inserts tw
o RRs into com
TLD
server:
2: A
pplication Layer7
5
registrar inserts two R
Rs into com
TLD
server:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
rcreate auth
oritative server Type A
record for
www.netw
orkuptopia.com; T
ype MX record
for netw
orkutopia.comrHow do people get IP ad
dress of your W
eb site?
Chapter 2
: Application layer
r2.1 Principles of netw
ork applications
r2.2 W
eb and
HTTP
r2.3 FTP
r2.4 Electronic M
ail
r2.6 P2
P applications
r2.7 Socket program
ming
with
UDP
r2.8 Socket program
ming
with
TCP
2: A
pplication Layer7
6
r2.4 Electronic M
ail�SMTP, PO
P3, IM
AP
r2.5 DNS
with
TCP
Pure P2P arch
itecture
rno
always-on server
rarb
itrary end system
s directly com
municate
rpeers are interm
ittently connected
and ch
ange IP
peer-peer
2: A
pplication Layer7
7
connected and
change IP
addresses
rThree topics:
�File d
istribution
�Search
ing for information
�Case S
tudy: S
kype
File D
istribution: S
erver-Client vs P2
P
Question
: How much
time to d
istribute file
from one server to N
peers?
Server
us :
se
rve
r up
loa
d
ba
nd
wid
th
ui :
pe
er i u
plo
ad
b
an
dw
idth
2: A
pplication Layer7
8
us
u2
d1
d2
u1
uN
dN
Netw
ork (with
abund
ant band
width)
File, size F
ba
nd
wid
th
di :
pe
er i d
ow
nlo
ad
b
an
dw
idth
File d
istribution tim
e: server-client
us
u2
d1
d2
u1
uN
dN
Server
Netw
ork (with
abund
ant band
width)
Frserver sequentially send
s N copies:
�NF/u
s time
rclient i takes F
/di
time to d
ownload
2: A
pplication Layer7
9
uN
client i takes F/d
i
time to d
ownload
increases linearly in N(for large N
)
= dcs= m
ax {NF/u
s , F/m
in(di )}
i
Time to d
istribute F
to Nclients using
client/server approach
File d
istribution tim
e: P2P
us
u2
d1
d2
u1
uN
dN
Server
Netw
ork (with
abund
ant band
width)
Frserver m
ust send one
copy: F/u
s time
rclient i takes F
/di tim
e to d
ownload
rNF bits m
ust be
2: A
pplication Layer8
0
uN
rNF bits m
ust be
download
ed (aggregate)
rfastest possib
le upload rate: u
s+ Σ
ui
dP2P= m
ax {F/u
s , F/m
in(di ), N
F/(u
s+ Σ
ui )}
i
2.5 3
3.5
Minimum Distribution TimeP
2P
Clie
nt-S
erve
r
Server-client vs. P2
P: exam
ple
Client upload
rate = u, F/u = 1 h
our, us= 10
u, dmin≥ u
s
2: A
pplication Layer8
1
0
0.5 1
1.5 2
05
10
15
20
25
30
35
N
Minimum Distribution Time
File d
istribution: B
itTorrent
tracker:tracks peers
participating in torrenttorrent:
group of peers ex
changing
chunks of a file
rP2P file d
istribution
2: A
pplication Layer8
2
obtain list
of peers
trading
chunks
peer
BitT
orrent (1)
rfile d
ivided into 2
56KB chunks.
rpeer joining torrent:
�has no ch
unks, but w
ill accumulate th
em over tim
e
2: A
pplication Layer8
3
�registers w
ith tracker to get list of peers,
connects to subset of peers (“neigh
bors”)
rwhile d
ownload
ing, peer uploads ch
unks to other
peers.
rpeers m
ay come and
go
ronce peer h
as entire file, it may (selfish
ly) leave or (altruistically) rem
ain
BitT
orrent (2)
Pulling Chunks
rat any given tim
e, different peers h
ave different sub
sets of file ch
unks
periodically, a peer
Send
ing Chunks: tit-for-tat
rAlice send
s chunks to four
neighbors currently
sending h
er chunks at the
highest rate�re-evaluate top 4
every 10 secs
2: A
pplication Layer8
4
rperiod
ically, a peer (Alice) asks each
neigh
bor for list of
chunks th
at they h
ave.
rAlice send
s requests for h
er missing ch
unks
�rarest first
10 secs
revery 3
0 secs: rand
omly
select another peer,
starts sending ch
unks
�new
ly chosen peer m
ay join top 4
�“optim
istically unchoke”
BitT
orrent: Tit-for-tat
(1) Alice “optim
istically unchokes” B
ob(2) A
lice becom
es one of Bob’s top-four provid
ers; Bob reciprocates
(3) B
ob becom
es one of Alice’s top-four provid
ers2: A
pplication Layer8
5
With
high
er upload rate,
can find better trad
ing partners &
get file faster!
Distrib
uted Hash
Table (D
HT)
rDHT = d
istributed
P2P d
atabase
rDatab
ase has (key, value) pairs;
�key: ss num
ber; value: h
uman nam
e
�key: content type; value: IP ad
dress
�key: content type; value: IP ad
dress
rPeers query
DB with
key�DB returns values th
at match
the key
rPeers can also insert
(key, value) peers
DHT Id
entifiers
rAssign integer id
entifier to each peer in range
[0,2
n-1].�Each
identifier can b
e represented by n b
its.
rRequire each
key to be an integer in sam
e range.Require each
key to be an integer in sam
e range.
rTo get integer keys, h
ash original key.
�eg, key = h
(“Led Zeppelin IV
”)
�This is w
hy th
ey call it a distrib
uted “h
ash” tab
le
How to assign keys to peers?
rCentral issue:�Assigning (key, value) pairs to peers.
rRule: assign key to th
e peer that h
as the
closestID
.closest
ID.
rConvention in lecture: closest is th
e immediate successor of th
e key.
rEx: n=4
; peers: 1,3,4,5,8,10
,12,14
; �key = 13
, then successor peer = 14
�key = 15
, then successor peer = 1
1
3
4
12 15
Circular D
HT (1)
5
810
12
rEach
peer onlyaware of im
mediate successor
and pred
ecessor.
r“Overlay netw
ork”
Circle D
HT (2
)
0001
0011
1111
Who’s resp
for key 1110 ?
I am
O(N) m
essages
on avg to resolve
query, when th
ere
are N peers
0100
0101
1000
1010
1100
111
0
111
0
111
0
111
0
111
0
111
0
Define closest
as closestsuccessor
Circular D
HT with
Shortcuts
1
3
4
512 15
Who’s resp
for key 1110?
rEach
peer keeps track of IP addresses of pred
ecessor, successor, sh
ort cuts.r
Reduced
from 6 to 2
messages.
rPossib
le to design sh
ortcuts so O(log N
) neighbors, O
(log N) m
essages in query
5
810
12
Peer Churn1
3
4
512 15
•To h
andle peer ch
urn, require
each peer to know
the IP ad
dress
of its two successors.
•Each
peer periodically pings its
two successors to see if th
ey are still alive.
rPeer 5
abruptly leaves
rPeer 4
detects; m
akes 8 its im
mediate successor;
asks 8 who its im
mediate successor is; m
akes 8’s
immediate successor its second
successor.rWhat if peer 13
wants to join?
5
810
12
P2P C
ase study: S
kype
rinh
erently P2P: pairs
of users communicate.
rproprietary application-layer protocol (inferred
via
Skype clients (S
C)
Supernod
e
(SN)
Skype
login server
2: A
pplication Layer9
3
protocol (inferred via
reverse engineering)
rhierarch
ical overlay with
SNs
rInd
ex maps usernam
es to IP ad
dresses;
distrib
uted over S
Ns
(SN)
Peers as relays
rProb
lem when b
oth
Alice and
Bob are
behind
“NATs”.
�NAT prevents an outsid
e peer from
initiating a call to insid
er peer
2: A
pplication Layer9
4
to insider peer
rSolution:
�Using A
lice’s and Bob’s
SNs, R
elay is chosen
�Each
peer initiates session w
ith relay.
�Peers can now
com
municate th
rough
NATs via relay
Chapter 2
: Application layer
r2.1 Principles of netw
ork applications
r2.2 W
eb and
HTTP
r2.3 FTP
r2.4 Electronic M
ail
r2.6 P2
P applications
r2.7 Socket program
ming
with
UDP
r2.8 Socket program
ming
with
TCP
2: A
pplication Layer9
5
r2.4 Electronic M
ail�SMTP, PO
P3, IM
AP
r2.5 DNS
with
TCP
Socket program
ming
Socket A
PIr
introduced
in BSD4.1 U
NIX
, 1981
explicitly created
, used,
A application-created
, OS-controlled
interface
socket
Goal:
learn how to b
uild client/server application th
at com
municate using sockets
2: A
pplication Layer9
6
rexplicitly created
, used,
released by apps
rclient/server parad
igm
rtwo types of transport
service via socket API:
�UDP
�TCP
OS-controlled
interface (a “d
oor”) into which
application process can both
send and
receive
messages to/from
anoth
er application process
Socket program
ming b
asics
rServer m
ust be
runningbefore
client can send
anything to it.
Server m
ust have a
rSocket is locally
identified
with
a port num
ber
�Analogous to th
e apt #
in a build
ingrServer m
ust have a
socket(door)
through
which
it receives and
sends
segments
rSimilarly client
needs a socket
in a build
ing
rClient need
s to know
server IP address and
socket port num
ber.
2: A
pplication Layer9
7
Socket program
ming w
ith UDP
UDP: no “connection” b
etween
client and server
rno h
andshaking
rsend
er explicitly attach
es IP ad
dress and
port of destination to each
segment
application viewpoint
UDP provides unreliable
transfer
2: A
pplication Layer9
8
destination to each
segment
rOS attach
es IP address and
port of send
ing socket to each
segment
rServer can ex
tract IP address, port of send
er from
received segm
ent
UDP provides unreliable
transferof groups of bytes (“datagram
s”)betw
een client and server
Note:
the official term
inology
for a UDP packet is “d
atagram”.
In this class, w
e instead use “U
DP
segment”.
Running ex
ample
rClient:�User types line of tex
t
�Client program
sends line to server
rServer:
Server:
�Server receives line of tex
t
�Capitalizes all th
e letters
�Send
s modified
line to client
rClient:�Receives line of tex
t
�Displays
2: A
pplication Layer9
9
Client/server socket interaction: U
DP
Server (running on h
ostid)
cre
ate
socket,
clie
ntS
ocket =
D
ata
gra
mS
ocket()
Client
Cre
ate
data
gra
m w
ith s
erv
er IP
and
cre
ate
socket,
port=
x.
serv
erS
ocket =
D
ata
gra
mS
ocket()
2: A
pplication Layer1
00
clo
se
clie
ntS
ocket
read d
ata
gra
m fro
mclie
ntS
ocket
Cre
ate
data
gra
m w
ith s
erv
er IP
and
port=
x; s
end d
ata
gra
m v
iaclie
ntS
ocket
read d
ata
gra
m fro
mserv
erS
ocket
write
reply
toserv
erS
ocket
specify
ing
clie
nt a
ddre
ss,
port n
um
ber
Exam
ple: Java client (U
DP)
inFromUser
ke
yb
oa
rdm
on
itor
Pro
ce
ss
inp
ut
stre
am
sends
Input: receives packet (recall thatT
CP received
Client
process
2: A
pplication Layer1
01
sendPacket
to n
etw
ork
from
ne
two
rk
receivePacket
clie
ntS
ocke
t
UD
P
pa
cke
t
UD
P
pa
cke
t
UD
P
so
cke
t
Output: send
s packet (recall
that T
CP sent
“byte stream
”)
thatT
CP received
“byte stream
”)
client UDP
socket
Exam
ple: Java client (U
DP)
imp
ort ja
va
.io.*;
imp
ort ja
va
.ne
t.*;
cla
ss U
DP
Clie
nt {
pu
blic
sta
tic v
oid
ma
in(S
tring
arg
s[]) th
row
s E
xce
ptio
n
{ Bu
ffere
dR
ea
de
r inF
rom
Use
r =
Create
input stream
2: A
pplication Layer1
02
Bu
ffere
dR
ea
de
r inF
rom
Use
r =
ne
w B
uffe
red
Re
ad
er(n
ew
Inp
utS
trea
mR
ea
de
r(Syste
m.in
));
Da
tag
ram
So
cke
t clie
ntS
ocke
t = n
ew
Da
tag
ram
So
cke
t();
Ine
tAd
dre
ss IP
Ad
dre
ss =
Ine
tAd
dre
ss.g
etB
yN
am
e("h
ostn
am
e");
byte
[] se
nd
Da
ta =
ne
w b
yte
[10
24
];
byte
[] rece
ive
Da
ta =
ne
w b
yte
[10
24
];
Strin
g s
en
ten
ce
= in
Fro
mU
se
r.rea
dL
ine
();
se
nd
Da
ta =
se
nte
nce
.ge
tByte
s();
input stream
Create
client socket
Translate
hostnam
e to IP address using D
NS
Exam
ple: Java client (U
DP), cont.
Da
tag
ram
Pa
cke
t se
nd
Pa
cke
t =
ne
w D
ata
gra
mP
acke
t(se
nd
Da
ta, s
en
dD
ata
.len
gth
, IPA
dd
ress, 9
87
6);
clie
ntS
ocke
t.se
nd
(se
nd
Pa
cke
t);
Da
tag
ram
Pa
cke
t rece
ive
Pa
cke
t =
ne
w D
ata
gra
mP
acke
t(rece
ive
Da
ta, re
ce
ive
Da
ta.le
ng
th);
Create d
atagram
with
data-to-send
,length
, IP addr, port
Send
datagramto server
2: A
pplication Layer1
03
ne
w D
ata
gra
mP
acke
t(rece
ive
Da
ta, re
ce
ive
Da
ta.le
ng
th);
clie
ntS
ocke
t.rece
ive
(rece
ive
Pa
cke
t);
Strin
g m
od
ified
Se
nte
nce
=
ne
w S
tring
(rece
ive
Pa
cke
t.ge
tDa
ta());
Syste
m.o
ut.p
rintln
("FR
OM
SE
RV
ER
:" + m
od
ified
Se
nte
nce
);
clie
ntS
ocke
t.clo
se
();
}
}
Read
datagram
from server
Exam
ple: Java server (U
DP)
imp
ort ja
va
.io.*;
imp
ort ja
va
.ne
t.*;
cla
ss U
DP
Se
rve
r {
pu
blic
sta
tic v
oid
ma
in(S
tring
arg
s[]) th
row
s E
xce
ptio
n
{ Da
tag
ram
So
cke
t se
rve
rSo
cke
t = n
ew
Da
tag
ram
So
cke
t(98
76
);
Create
datagram
socketat port 9
876
2: A
pplication Layer1
04
Da
tag
ram
So
cke
t se
rve
rSo
cke
t = n
ew
Da
tag
ram
So
cke
t(98
76
);
byte
[] rece
ive
Da
ta =
ne
w b
yte
[10
24
];
byte
[] se
nd
Da
ta =
ne
w b
yte
[10
24
];
wh
ile(tru
e)
{ Da
tag
ram
Pa
cke
t rece
ive
Pa
cke
t =
ne
w D
ata
gra
mP
acke
t(rece
ive
Da
ta, re
ce
ive
Da
ta.le
ng
th);
se
rve
rSo
cke
t.rece
ive
(rece
ive
Pa
cke
t);
at port 9876
Create space for
received datagram
Receive
datagram
Exam
ple: Java server (U
DP), cont
Strin
g s
en
ten
ce
= n
ew
Strin
g(re
ce
ive
Pa
cke
t.ge
tDa
ta());
Ine
tAd
dre
ss IP
Ad
dre
ss =
rece
ive
Pa
cke
t.ge
tAd
dre
ss();
int p
ort =
rece
ive
Pa
cke
t.ge
tPo
rt();
Strin
g c
ap
italiz
ed
Se
nte
nce
= s
en
ten
ce
.toU
pp
erC
ase
();
Get IP ad
dr
port #, of
sender
2: A
pplication Layer1
05
se
nd
Da
ta =
ca
pita
lize
dS
en
ten
ce
.ge
tByte
s();
Da
tag
ram
Pa
cke
t se
nd
Pa
cke
t =
ne
w D
ata
gra
mP
acke
t(se
nd
Da
ta, s
en
dD
ata
.len
gth
, IPA
dd
ress,
po
rt);
se
rve
rSo
cke
t.se
nd
(se
nd
Pa
cke
t);
}
}
}
Write out datagramto socket
End of w
hile loop,
loop back and
wait for
another d
atagram
Create d
atagramto send
to client
UDP ob
servations & questions
rBoth
client server use Datagram
Socket
rDest
IP and port are ex
plicitly attached to
segment.
rWhat w
ould happen if ch
ange both
clientSocket
and serverS
ocketto “m
ySocket”?
and serverS
ocketto “m
ySocket”?
rCan th
e client send a segm
ent to server with
out know
ingthe server’s IP ad
dress and
/or port num
ber?
rCan m
ultiple clients use the server?2
: Application Layer
10
6
Chapter 2
: Application layer
r2.1 Principles of netw
ork applications
r2.2 W
eb and
HTTP
r2.3 FTP
r2.4 Electronic M
ail
r2.6 P2
P applications
r2.7 Socket program
ming
with
UDP
r2.8 Socket program
ming
with
TCP
2: A
pplication Layer1
07
r2.4 Electronic M
ail�SMTP, PO
P3, IM
AP
r2.5 DNS
with
TCP
Socket-program
ming using T
CP
TCP service:
reliable transfer of b
yte
sfrom
one process to anoth
er
2: A
pplication Layer1
08
process
TCP w
ithbuffers,
variables
socket
controlled by
applicationdeveloper
controlled by
operatingsystem
host orserver
process
TCP w
ithbuffers,
variables
socket
controlled by
applicationdeveloper
controlled by
operatingsystem
host orserver
internet
Socket program
ming w
ith TCP
Client m
ust contact server
rserver process m
ust first be running
rserver m
ust have created
socket (d
oor) that
welcom
es client’s contact
rWhen contacted
by client,
server TCP creates new
socket
for server process to com
municate w
ith client
�allow
s server to talk with
multiple clients
source port numbers
2: A
pplication Layer1
09
Client contacts server b
y:
rcreating client-local T
CP
socket
rspecifying IP ad
dress, port
number of server process
rWhen client creates
socket: client TCP
establish
es connection to server T
CP
�source port num
bers
used to d
istinguish
clients (more in C
hap 3
)
TCP provides reliable, in-ordertransfer of bytes (“pipe”) betw
een client and server
application viewpoint
Client/server socket interaction: T
CP
wait fo
r incom
ing
cre
ate
socket,
port=x
, for
incom
ing re
quest:
welc
om
eS
ocket =
S
erv
erS
ocket()
cre
ate
socket,
connect to
hostid
, port=x
Server (running on h
ostid)
Client
TCP
connection setup
2: A
pplication Layer11
0
wait fo
r incom
ing
connectio
n re
quest
connectio
nS
ocket =
welc
om
eS
ocket.a
ccept()
connect to
hostid
, port=x
clie
ntS
ocket =
S
ocket()
clo
se
connectio
nS
ocket
read re
ply
from
clie
ntS
ocket
clo
se
clie
ntS
ocket
send re
quest u
sin
gclie
ntS
ocket
read re
quest fro
mconnectio
nS
ocket
write
reply
toconnectio
nS
ocket
connection setup
inFromUser
keyb
oa
rdm
on
itor
Pro
cess
inp
ut
strea
m
Client
process
Stream
jargon
rA stream
is a sequence of characters th
at flow into
or out of a process.
rAn input stream
is attach
ed to som
e input source for th
e process,
2: A
pplication Layer111
outToServer
to n
etw
ork
from
ne
two
rk
inFromServer
clien
tSo
cket
inp
ut
strea
mo
utp
ut
strea
m
TC
Pso
cket
client TCP
socket
source for the process,
e.g., keyboard
or socket.
rAn output stream
is attach
ed to an output
source, e.g., monitor or
socket.
Socket program
ming w
ith TCP
Exam
ple client-server app:1) client read
s line from
standard
input (inFromUser
stream) , send
s to server via socket (o
utToServer
stream)
2: A
pplication Layer11
2
stream)
2) server read
s line from socket
3) server converts line to uppercase, send
s back to
client
4) client read
s, prints modified
line from
socket (inFromServerstream
)
Exam
ple: Java client (T
CP)
import ja
va.io
.*;
import ja
va.n
et.*;
cla
ss T
CP
Clie
nt {
public
sta
tic v
oid
main
(Strin
g a
rgv[]) th
row
s E
xceptio
n
{
Strin
g s
ente
nce;
2: A
pplication Layer11
3
Strin
g s
ente
nce;
Strin
g m
odifie
dS
ente
nce;
Buffe
redR
eader in
Fro
mU
ser =
new
Buffe
redR
eader(n
ew
InputS
tream
Reader(S
yste
m.in
));
Socket c
lientS
ocket =
new
Socket("h
ostn
am
e", 6
789);
Data
Outp
utS
tream
outT
oS
erv
er =
new
Data
Outp
utS
tream
(clie
ntS
ocket.g
etO
utp
utS
tream
());
Create
input stream
Create
client socket, connect to server
Create
output streamattach
ed to socket
Exam
ple: Java client (T
CP), cont.
Buffe
redR
eader in
Fro
mS
erv
er =
new
Buffe
redR
eader(n
ew
InputS
tream
Reader(c
lientS
ocket.g
etIn
putS
tream
()));
sente
nce =
inF
rom
User.re
adLin
e();
Create
input streamattach
ed to socket
Send
line
2: A
pplication Layer11
4
outT
oS
erv
er.w
riteB
yte
s(s
ente
nce +
'\n');
modifie
dS
ente
nce =
inF
rom
Serv
er.re
adLin
e();
Syste
m.o
ut.p
rintln
("FR
OM
SE
RV
ER
: " + m
od
ified
Se
nte
nce);
clie
ntS
ocket.c
lose();
}
}
Send
lineto server
Read
linefrom
server
Exam
ple: Java server (T
CP)
imp
ort ja
va
.io.*;
imp
ort ja
va
.ne
t.*;
cla
ss T
CP
Se
rve
r {
pu
blic
sta
tic v
oid
ma
in(S
tring
arg
v[]) th
row
s E
xce
ptio
n
{ Strin
g c
lien
tSe
nte
nce
;
Strin
g c
ap
italiz
ed
Se
nte
nce
; Create
2: A
pplication Layer11
5
Strin
g c
ap
italiz
ed
Se
nte
nce
;
Se
rve
rSo
cke
t we
lco
me
So
cke
t = n
ew
Se
rve
rSo
cke
t(67
89
);
wh
ile(tru
e) {
So
cke
t co
nn
ectio
nS
ocke
t = w
elc
om
eS
ocke
t.acce
pt();
Bu
ffere
dR
ea
de
r inF
rom
Clie
nt =
ne
w B
uffe
red
Re
ad
er(n
ew
Inp
utS
trea
mR
ea
de
r(co
nn
ectio
nS
ocke
t.ge
tInp
utS
trea
m()));
Create
welcom
ing socketat port 6
789
Wait, on w
elcoming
socket for contactby client
Create input
stream, attach
ed
to socket
Exam
ple: Java server (T
CP), cont
Data
Outp
utS
tream
outT
oC
lient =
new
Data
Outp
utS
tream
(co
nn
ectio
nS
ocke
t.ge
tOu
tpu
tStre
am
());
clie
ntS
ente
nce =
inF
rom
Clie
nt.re
adLin
e();
Read
in linefrom
socket
Create output
stream, attach
ed
to socket
2: A
pplication Layer11
6
capita
lizedS
ente
nce =
clie
ntS
ente
nce.to
UpperC
ase() +
'\n';
outT
oC
lient.w
riteB
yte
s(c
ap
italiz
edS
ente
nce);
}
} }
Write out lineto socket
End of w
hile loop,
loop back and
wait for
another client connection
TCP ob
servations & questions
rServer h
as two types of sockets:
�ServerS
ocketand
Socket
rWhen client knocks on serverS
ocket’s“door,”
server creates connectionSocket
and com
pletes TCP conx
.TCP conx
.
rDest
IP and port are not
explicitly attach
ed to
segment.
rCan m
ultiple clients use the server?2
: Application Layer
11
7
Chapter 2
: Sum
mary
rapplication arch
itectures�client-server
�P2P
�hybrid
rapplication service
our study of netw
ork apps now com
plete!
rspecific protocols:�HTTP
�FTP
�SMTP, PO
P, IMAP
�DNS
2: A
pplication Layer11
8
rapplication service requirem
ents:�
reliability, b
andwidth,
delay
rInternet transport service m
odel
�connection-oriented
, reliab
le: TCP
�unreliab
le, datagram
s: UDP
�DNS
�P2P: B
itTorrent, S
kype
rsocket program
ming
Chapter 2
: Sum
mary
rtypical request/reply message ex
change:
�client requests info or service
Most im
portantly:learned
about protocols
Important them
es: rcontrol vs. d
ata msgs
�in-b
and, out-of-b
and
2: A
pplication Layer11
9
service
�server respond
s with
data, status cod
e
rmessage form
ats:�head
ers: fields giving
info about d
ata
�data: info b
eing com
municated
�in-b
and, out-of-b
and
rcentralized
vs. decentralized
rstateless vs. stateful
rreliab
le vs. unreliable
msg transfer
r“com
plexity at netw
ork edge”
