Application Layer

CS 3516 Computer Networks

2: Application Layer

Chapter 2: Application Layer

learn about protocols

Goals:
conceptual,
implementation
aspects of network
application protocols
transport-layer
service models
client-server
paradigm
peer-to-peer
paradigm

Some network apps

by examining popular
application-level
protocols

HTTP
FTP
SMTP / POP3 / IMAP
DNS

programming network
applications
socket API

e-mail
web
instant messaging
remote login
P2P file sharing
multi-user network
games
streaming stored video
clips

social networks
voice over IP
real-time video
conferencing
f
g
grid computing

Creating a Network App

Write programs that

Chapter 2: Application layer

application
transport
network
data link
physical

run on (different) end

communicate over network

e.g., web server software
communicates
commun
cates with
w th browser
software

2.1 Principles of
network applications
2.2 Web and HTTP
2.3 FTP
2.4 Electronic Mail

2.5 DNS

systems

No need to write software

for network-core devices
Network-core devices do
not run user applications
applications on end systems
allows for rapid app
development, propagation

application
transport
network
data link
physical

application
transport
network
data link
physical

2.6 P2P applications

2.7 Socket programming
with UDP
2.8 Socket p
programming
g
g
with TCP

SMTP, POP3, IMAP

Client-server Architecture

Application architectures

server:

Client-server (CS)

always-on host
permanent IP address
server farms for scaling

Including data centers / cloud computing

Peer-to-peer (P2P)
Hybrid of client-server and P2P

clients:
communicate with server
may be intermittently
connected
may have dynamic IP
addresses
do not communicate
directly with each other

client/server

Server Example - Google Data

Centers

Pure P2P Architecture

Estimated cost of data center: $600M

Google spent $2.4B in 2007 on new data

centers
Each data center uses 50-100 megawatts
g
of power

no always-on server
arbitrary end systems
directly communicate peer-peer
peers are intermittently
connected and change IP
addresses

Highly scalable but

difficult to manage

Hybrid of Client-server and P2P

E.g. Skype

E.g. Instant messaging

voice-over-IP P2P application

centralized server: finding address of
remote party
client-client connection: often direct (not
through server)
chatting between two users is P2P
centralized service: client presence
detection/location

user registers its IP address with central

server when it comes online
user contacts central server to find IP

Processes Communicating
Process: program running
within a host.
Within same host, two
processes communicate
using
g inter-process
p
communication (defined
by OS).
Processes in different
hosts communicate by
exchanging messages

Client process: process

that initiates
communication
Server process: process
that waits to be
contacted
Note: applications with
P2P architectures have
client processes &
server processes

addresses of buddies

Addressing Processes

Sockets

Process sends/receives
messages to/from its
socket
Socket analogous to door
sending
g process
p
shoves
message out door
sending process relies on
transport infrastructure
on other side of door which
brings message to socket
at receiving process

host or
server

host or
server

process

controlled by
app developer

process
socket

socket
TCP with
buffers,
variables

Internet

TCP with
buffers,
variables

To receive messages,
process must have

identifier

Host device has unique

32-bit IP address
Exercise: use ipconfig
from command prompt to
get your IP address
(Windows)

controlled
by OS

Types of messages
exchanged,
e.g., request, response

Message syntax:

Message semantics

what fields in messages &

how fields are delineated
meaning of information in
fields

Public-domain protocols:
Defined in RFCs
allows for
interoperability
e.g., HTTP,
HTTP SMTP,
SMTP
BitTorrent
Proprietary protocols:
e.g., Skype, ppstream

Rules for when and how

processes send &
respond to messages

Data loss

Throughput

Time Sensitive

file transfer
e-mail
Web documents
real time audio/video
real-time

no loss
no loss
no loss
l
loss-tolerant
t l
t

no
no
no
yes 100s
yes,
100 s msec

stored audio/video
interactive games
instant messaging

loss-tolerant
loss-tolerant
no loss

elastic
elastic
elastic
di 5kb
5kbps-1Mbps
1Mb
audio:
video:10kbps-5Mbps
same as above
few kbps up
elastic

yes, few secs

yes, 100s msec
yes and no

Q: does IP address of

host on which process

runs suffice for
identifying the process?
A: No, many processes
can be running on
same
Identifier includes both
IP address and port
numbers associated with
process on host.
Example port numbers:
HTTP server: 80
Mail server: 25

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
t
transfer
f
Timing
some apps (e.g.,
Internet telephony,
interactive games)
require low delay to be
effective

Transport Service Requirements of Common

Apps
Application

API: (1) choice of transport protocol; (2) ability to

fix a few parameters (see Sockets slide deck)

App-layer Protocol Defines

Throughput
some apps (e.g.,
multimedia) require
minimum amount of
throughput to be
effective
th apps (elastic
( l ti apps)
)
other
make use of whatever
throughput they get
Security
encryption, data integrity,

Internet Transport Protocols Services

TCP service:

connection-oriented: setup

required between client and

server processes
reliable transport between
sending
di and
d receiving
i i process
flow control: sender wont
overwhelm receiver
congestion control: throttle
sender when network
overloaded
does not provide: timing,
minimum throughput
guarantees, security

UDP service:

unreliable data transfer

between sending and
receiving process
does not provide:
connection setup,
setup
reliability, flow control,
congestion control, timing,
throughput guarantee, or
security

Q: why bother? Why is

there a UDP?

Internet Apps: Application, Transport Protocols

Application
e-mail
remote terminal access
Web
fil ttransfer
file
f
streaming multimedia
Internet telephony

Chapter 2: Application layer

Application
layer protocol

Underlying
transport protocol

SMTP [RFC 2821]

Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
HTTP (eg Youtube),
RTP [RFC 1889]
SIP, RTP, proprietary
(e.g., Skype)

TCP
TCP
TCP
TCP
TCP or UDP

2.1 Principles of
network applications
2.2 Web and HTTP
2.3 FTP
2.4 Electronic Mail

typically UDP

2.5 DNS

Web and HTTP

HTTP Overview (continued)

Webs application layer

protocol
client/server
li t/
model
d l
client: browser that
requests, receives,
displays Web objects
server: Web server
sends objects in
response to requests

PC running
Explorer

Server
running
Apache Web
server
Mac running
Navigator

path name

host name

client initiates TCP

connection (creates socket)
to server, port 80
server accepts TCP
connection
ti from
f
client
li t
HTTP messages (applicationlayer protocol messages)
exchanged between browser
(HTTP client) and Web
server (HTTP server)
TCP connection closed

SMTP, POP3, IMAP

HTTP: hypertext
transfer protocol

www.someschool.edu/someDept/pic.gif

2.6 P2P applications

2.7 Socket programming
with UDP
2 8 Socket programming
2.8
with TCP

HTTP Overview

First some jargon

Web page consists of objects
Object can be HTML file, JPEG image, Java
applet, audio file,
Web
W b page consists
i t of
f base
b
HTML
HTML-file
fil which
hi h
includes several referenced objects
Each object is addressable by a URL
Example URL:

Uses TCP:

HTTP connections

HTTP is stateless

server maintains no
information about
past client requests

aside

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

Nonpersistent HTTP
At most one object is
sent over a TCP
connection.

Persistent HTTP
Multiple objects can
be sent over single
TCP connection
between client and
server.

Nonpersistent HTTP
Suppose user enters URL

(contains text,
references to 10
jpeg images)

Nonpersistent HTTP (cont.)

4. HTTP server closes TCP

www.someSchool.edu/someDepartment/home.index
5. HTTP client receives response

1a. HTTP client initiates TCP

connection to HTTP server

(process) at
www.someSchool.edu on port 80

2. HTTP client sends HTTP

request message (containing

URL) into TCP connection

socket. Message indicates that
client wants object

someDepartment/home.index

1b. HTTP server at host

www.someSchool.edu waiting
for TCP connection at port 80.
accepts connection, notifying
client

connection.

message containing html file,

displays html. Parsing html
file, finds 10 referenced jpeg
objects

1-5 repeated for each

time 6. Steps
of 10 jpeg objects

3. HTTP server receives request

message, forms response
message containing requested
object, and sends message
into its socket

time

Nonpersistent HTTP: Response time

Definition of RTT: time for
a small packet to travel
from client to server
and back.
Response time:
one RTT to initiate TCP
connection
one RTT for HTTP
request and first few
bytes of HTTP response
to return
file transmission time
total = 2RTT+transmit time

initiate TCP
connection
RTT
requestt
file

time to
transmit
file

RTT
file
received
time

time

HTTP request message

Persistent HTTP
Persistent HTTP
Nonpersistent HTTP issues:
requires 2 RTTs per object server leaves connection
open after sending
OS overhead for each TCP
response
connection

HTTP messages
browsers often open parallel subsequent
between same
TCP connections to fetch
client/server sent over
referenced objects
open connection
client sends requests as
soon as it encounters a
referenced object
as little as one RTT for all
the referenced objects

HTTP request message: general format

two types of HTTP messages: request, response

HTTP request message:
ASCII (human-readable format)

request
q
line
(GET, POST,
HEAD commands)

GET /somedir/page.html HTTP/1.1

Host: www.someschool.edu
User-agent: Mozilla/4.0
header Connection: close
lines Accept-language:fr

Carriage return,
line feed
indicates end
of message

(extra carriage return, line feed)

Uploading form input

Post method:
Web page often
includes form input
Input
p is uploaded
p
to
server in entity body

URL method:
Uses GET method
Input is uploaded in
URL field of request
line:

www.somesite.com/animalsearch?monkeys&banana

HTTP response message

status line
(protocol
status code
status phrase)
header
lines

data, e.g.,
requested
HTML file

HTTP/1.1 200 OK
Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified:
Last
Modified: Mon
Mon, 22 Jun 1998 ...
Content-Length: 6821
Content-Type: text/html
data data data data data ...

Method types
HTTP/1.0
GET
POST
HEAD

asks server to leave

requested object out of
response

HTTP/1.1
GET, POST, HEAD
PUT

uploads
up a f
file in
n entity
nt ty
body to path specified
in URL field

DELETE
deletes file specified in
the URL field

HTTP response status codes

In first line in server->client response message.
A few sample codes:
200 OK
request succeeded, requested object later in this message

301 Moved Permanently

requested object moved, new location specified later in
this message (Location:)

400 Bad Request

request message not understood by server

404 Not Found

requested document not found on this server

505 HTTP Version Not Supported

Trying out HTTP (client side) for yourself

1. Telnet to your favorite Web server:
telnet cis.poly.edu 80

Opens TCP connection to port 80

(default HTTP server port) at cis.poly.edu.
Anything typed in sent
to port 80 at cis.poly.edu

2. Type in a GET HTTP request:

GET /~ross/ HTTP/1.1
Host: cis.poly.edu

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 State: Cookies

Example:
Susan always access
Internet always from PC
visits specific e1) cookie header line of
commerce site for first
HTTP response message
time
2) cookie header line in
HTTP request message when initial HTTP
3) cookie file kept on
requests arrives at site,
users host, managed by
site creates:
users browser
4) back-end database at
unique ID
Web site
entry in backend
database for ID

Many major Web sites

use cookies
Four components:

Cookies: keeping state (cont.)

client
ebay 8734

cookie file

usual http request msg

usual http response

Set-cookie: 1678
ebay 8734
amazon 1678

usual http request msg

cookie: 1678
usual http response msg

one week later:

entry

cookiespecific
action

access

usual http request msg

cookie: 1678
usual http response msg

How to keep state:

protocol endpoints: maintain state
at sender/receiver over multiple
transactions
cookies: http messages carry
state

backend
database

cookiespectific
action

Web caches (proxy server)

More About Web Caching

Goal: satisfy client request without involving origin server

user sets browser:

Web accesses via
cache
browser sends all
HTTP requests to
cache

origin
server

Proxy
server
client

object in cache: cache

returns object
else cache requests
object from origin
server, then returns
object to client

client

Consequences

origin
servers

utilization on LAN = 15%

utilization on access link = 100%
total delay = Internet delay +
access delay + LAN delay
= 2 sec + minutes (congested) +
milliseconds

public
Internet

origin
servers

possible solution

increase bandwidth of access

link to, say, 100 Mbps

public
Internet

consequence
15 Mbps
1
b
access link

institutional
network

Why Web caching?

Reduce response time
for client request
Reduce traffic
ff on an
institutions access
link.
Internet dense with
caches: enables poor
content providers to
effectively deliver
content (but so does
P2P file sharing)

Caching Example (cont)

Assumptions
average object size =
1,000,000 bits
avg. request rate from
institutions browsers to origin
servers = 15/sec
delay from institutional router
to any origin server and back
to router = 2 sec

Cache acts as both

client and server
Typically cache is
installed by ISP
(university, company,
residential ISP)

origin
server

Caching Example

aside

Cookies and privacy:

cookies permit sites to
learn a lot about you
you may supply name
and e-mail to sites

What cookies can bring:

authorization
shopping carts
recommendations
user session state
(Web e-mail)

Amazon server
creates ID
1678 for user create

access
ebay 8734
amazon 1678

Cookies (continued)

server

100 Mbps LAN

institutional
cache

utilization on LAN = 15%

utilization on access link = 15%
Total delay = Internet delay +
access delay + LAN delay
= 2 sec + msecs + msecs
BUToften a costly upgrade

100 Mbps
b
access link
institutional
network

100 Mbps LAN

institutional
cache

Caching - Conditional GET

Caching example (cont)

possible solution: install
cache

public
Internet

suppose hit rate is 0.4

consequence

40% requests will be

y
satisfied almost immediately
60% requests satisfied by
origin server
utilization of access link
reduced to 60%, resulting in
negligible delays (say 10
msec)
total avg delay = Internet
delay + access delay + LAN
delay = .6*(2.01) secs +
.4*milliseconds < 1.4 secs

origin
servers

15 Mbps
1
b
access link
institutional
network

100 Mbps LAN

institutional
cache

2.1 Principles of
network applications
2.2 Web and HTTP

2.3 FTP
2.4 Electronic Mail

2.6 P2P applications

2.7 Socket programming
with UDP
2.8 Socket programming
with TCP

SMTP, POP3, IMAP

SSN, name, passport #

IP address (32 bit) used for addressing
datagrams
name, e.g.,
www.yahoo.com - used
by humans

Q: map between IP
addresses and name?

HTTP response

object
not
modified

HTTP/1.0
304 Not Modified

If-modified-since:
<date>

server: response
contains no object if
cached copy is up-todate:

HTTP request msg

If-modified-since:
<date>

object
modified

HTTP response
HTTP/1.0 200 OK

Chapter 2: Application layer

2.1 Principles of
network applications
2.2 Web and HTTP
2.3 FTP
2.4 Electronic Mail

2.5 DNS

Domain Name System:

distributed database

application-layer protocol

implemented in hierarchy of
many name servers
host,
h
t routers,
t
name servers to
t
communicate to resolve names
(address/name translation)
note: core Internet
function, implemented as
application-layer protocol
complexity at networks
edge

2.6 P2P applications

2.7 Socket programming
with UDP
2.8 Socket programming
with TCP

SMTP, POP3, IMAP

DNS: Domain Name System

Internet hosts, routers:

If-modified-since:
<date>

<data>

2.5 DNS

People: many identifiers:

HTTP request msg

HTTP/1.0 304 Not

Modified

Chapter 2: Application layer

server

Goal: dont send object cache

if cache has up-to-date
cached version
cache: specify date of
cached copy in HTTP
request

DNS
DNS services
hostname to IP
address translation
host aliasing

Aliases,, where canonical

name is real name

mail server aliasing

load distribution
replicated Web
servers: set of IP
addresses for one name

Why not centralize DNS?

single point of failure
traffic volume
distant centralized
database
maintenance
doesnt scale!

Distributed, Hierarchical Database

com DNS servers

yahoo.com
DNS servers

org DNS servers

amazon.com
DNS servers

edu DNS servers

poly.edu
umass.edu
DNS serversDNS servers

pbs.org
DNS servers

Client wants IP for www.amazon.com; 1st approx:

client queries a root server to find .com DNS server
client queries .com DNS server to get amazon.com
DNS server
client queries amazon.com DNS server to get IP
address for www.amazon.com

TLD and Authoritative Servers

Top-level domain (TLD) servers:

Responsible for com, org, net, edu, etc, and

all top-level country domains uk, fr, ca, jp
Network Solutions maintains servers for com
TLD
Educause for edu TLD

Authoritative DNS servers:

Organizations DNS servers, providing

authoritative hostname to IP mappings for
organizations servers (e.g., Web, mail).
Can be maintained by organization or service
provider

DNS name
resolution example

root DNS server

Host at cis.poly.edu
wants IP address for

contacted server
replies with name of
server to contact
I dont know this
name, but ask this
server

TLD DNS server

4

gaia.cs.umass.edu

Iterated query
query:

5
local DNS server
dns.poly.edu

DNS: Root Name Servers

Root DNS Servers

Contacted by local name server that can not resolve name

Root name server:
Contacts authoritative name server if name mapping not known
Gets mapping
Returns mapping to local name server
a Verisign,
Verisign Dulles,
Dulles VA
c Cogent, Herndon, VA (also LA)
d U Maryland College Park, MD
g US DoD Vienna, VA
h ARL Aberdeen, MD
j Verisign, ( 21 locations)

e NASA Mt View, CA
f Internet Software C. Palo Alto,

cis.poly.edu

i Autonomica, Stockholm (plus

28 other locations)
m WIDE Tokyo (also Seoul,
Paris, SF)

CA (and 36 other locations)

13 root name
servers worldwide
b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA

Local Name Server

Does not strictly belong to hierarchy

Each ISP (residential ISP, company,
university) has one

Also called default

default name server
server
You can run one in your home/dorm!

When host makes DNS query, query is sent

to its local DNS server

Acts as proxy, forwards query into

hierarchy

DNS name
resolution example
Recursive query:

root DNS server

Puts burden of name

7
resolution on
contacted name
server
Heavy load?
local DNS server
dns.poly.edu

1
requesting host

k RIPE London (also 16 other locations)

3
6
TLD DNS server

authoritative DNS server

dns.cs.umass.edu

requesting host

authoritative DNS server

dns.cs.umass.edu

cis.poly.edu
gaia.cs.umass.edu

DNS: caching and updating records

Once (any) name server learns mapping, it caches
mapping
Cache entries timeout (disappear) after some
time
TLD servers typically
yp
y cached in local name
servers

Thus root name servers not visited often

Originally thought DNS names quite static, but

increasingly not so update/notify mechanisms
under design by IETF

DNS Records
DNS: distributed db storing resource records (RR)
RR format: (name,
Type=A

name is domain (e.g.

foo.com)
value is hostname of
authoritative name
server for this domain

DNS protocol, messages

Type=MX
value is name of mailserver
associated with name

Additional helpful
info that may be used

Chapter 2: Application layer

Register name networkuptopia.com at DNS registrar

(e.g., Network Solutions)

2.1 Principles of
network applications
2.2 Web and HTTP
2.3 FTP
2.4 Electronic Mail

2.5 DNS

(networkutopia.com, dns1.networkutopia.com, NS)

(dns1.networkutopia.com, 212.212.212.1, A)

value is canonical name

Records for
authoritative servers

Example: new startup Network Utopia

provide names
names, IP addresses of authoritative name server
(primary and secondary)
registrar inserts two RRs into .com TLD server:

servereast.backup2.ibm.com

Resource records in
p
to q
query
y
response

Inserting records into DNS

name is alias name for some

canonical (the real) name
www.ibm.com is really

Name, type fields

for a query

msg header

How do people get IP address of your Web site?

How do they send you email?

DNS protocol, messages

DNS protocol : query and reply messages, both with

same message format

Type=CNAME

Type=NS

RFC 2136: http://www.ietf.org/rfc/rfc2136.txt

identification: 16 bit #
for query, reply to query
uses same #
flags:
query or reply
recursion desired
recursion available
reply is authoritative

name is hostname
value is
i IP address
dd

value, type, ttl)

2.6 P2P applications

2.7 Socket programming
with UDP
2.8 Socket programming
with TCP

SMTP, POP3, IMAP

Create authoritative server Type A record for

www.networkuptopia.com; Type MX record for
networkutopia.com for mail

10

Pure P2P Architecture

File Distribution: Client-Server vs P2P

Question : How much time to distribute file
from one server to N peers?

no always-on server
Arbitrary end systems
directly communicate peer-peer
Peers are intermittently
connected and change IP
addresses

u1

us

d1

u2

ui: peer i upload

bandwidth
d2

di: peer i download

bandwidth

File, size F

Three topics:

dN

File distribution
Searching for information
Case Study: Skype

Network (with
abundant bandwidth)

uN

File Distribution Time: Client-Server

Server

Server sequentially

us: server upload

bandwidth

Server

u1 d1 u2

sends N copies:
NF/us time
Client i takes F/di
time to download

us
dN

File Distribution Time: P2P

d2

Network (with
abundant bandwidth)

uN

Server

Server must send one

copy: F/us time
Client i takes F/di time
to download
NF bits must be
downloaded (aggregate)

F
us
dN

u1 d1 u2

d2

Network (with
abundant bandwidth)

uN

Fastest possible upload rate: us + sum ui

Time to distribute F
to N clients using = d = max { NF/u , F/min(d ) }
cs
s
i
client-server approach
i

dP2P = max { F/us, F/min(di), NF/(us + ui) }

i

increases linearly in N
(for large N)

Client-Serer vs P2P: Example

File Distribution: BitTorrent

Client upload rate = u, F/u = 1 hour, us = 10u, dmin us

Minimum Distributtion Time

P2P
Client-Server

torrent: group of
peers exchanging
chunks of a file

tracker: tracks peers

participating in torrent

3.5

2.5
2

obtain list
of peers

1.5
1

trading
chunks

0.5
0
0

10

15

20

25

30

35

peer

11

BitTorrent (2)

BitTorrent (1)

File divided into 256KB chunks

Peer joining torrent:
Has no chunks, but will accumulate them over time
Registers
R i t
with
ith tracker
t k to
t gett list
li t of
f peers, connects
t
to subset of peers (neighbors)
While downloading, peer uploads chunks to other peers
Peers may come and go
Once peer has entire file, it may (selfishly) leave or
(altruistically) remain

BitTorrent: Tit-for-tat
(1) Alice optimistically unchokes Bob
(2) Alice becomes one of Bobs top-four providers; Bob reciprocates
(3) Bob becomes one of Alices top-four providers

Pulling Chunks
At any given time,
different peers have
different subsets of
file chunks
Periodically, a peer
(Alice) asks each
neighbor for list of
chunks that they have
Alice sends requests
for her missing chunks
rarest first

Sending Chunks: tit-for-tat

Alice sends chunks to four
neighbors currently
sending her chunks at the

highest rate

Re evaluate top 4 every

Re-evaluate
10 secs
Every 30 secs: randomly
select another peer,
starts sending chunks
- Newly chosen peer may
join top 4 (5 total)
- optimistically unchoke
-

Distributed Hash Table (DHT)

DHT = distributed P2P database

Database has (key, value) pairs;

key: ss number; value: human name

key:
k
content type; value:
l
IP address
dd

Peers query DB with key

DB returns values that match the key

Peers can also insert (key, value) peers

With higher upload rate,
can find better trading
partners & get file faster!

DHT Identifiers

Assign integer identifier to each peer in range

[0,2n-1]

Each identifier can be represented by n bits

Require
q
each key
y to be an integer
g in same range
g
To get integer keys, hash original key

e.g., key = h(Led Zeppelin IV)

This is why they call it a distributed hash table

How to Assign Keys to Peers?

Central issue:

Assigning (key, value) pairs to peers

Rule: assign key to the peer that has the

closest
l s st ID

Convention in lecture: closest is the

immediate successor of the key

Ex: n=4; peers: 1,3,4,5,8,10,12,14;

key = 13, then successor peer = 14

key = 15, then successor peer = 1

12

Circle DHT (2)

Circular DHT (1)

1

O(N) messages
on avg to resolve
query, when there
are N peers

15

4
12

I am

0011
1110

0100

1110
1110

1100

Each peer only aware of immediate

1110

Define closest
as closest
successor

successor and predecessor.

Overlay network

Circular DHT with Shortcuts

1

1110

1010

3
4

4
12

5
10

Each peer keeps track of IP addresses of

predecessor, successor, short cuts.
Reduced from 6 to 2 messages.
Possible to design shortcuts so O(log N) neighbors,
O(log N) messages in query

Skype clients (SC)

Inherently P2P: pairs

of users communicate
Proprietary
Skype
login server
application-layer
protocol (inferred via
reverse engineering)
Hierarchical overlay
with Super Nodes
(SNs)
Index maps usernames
to IP addresses;
distributed over SNs

Supernode
(SN)

To handle peer churn, require

each peer to know IP address
of its two successors.
Each peer periodically pings its
two successors to see if still alive

5
10

Peer 5 abruptly leaves

Peer 4 detects; makes 8 its immediate successor;
asks 8 who its immediate successor is; makes 8s
immediate successor its second successor.
What if peer 13 wants to join?

P2P Case study: Skype

1000

Peer Churn
15

15

12

0101

1110

Whos resp
for key 1110?

Whos resp
for key 1110 ?

1111

5
10

0001

Peers as Relays

Problem when both

Alice and Bob are
behind NATs.

NAT prevents outside

peer from initiating call
to insider peer

Solution:

Using Alices and Bobs

SNs, Relay is chosen
Each peer initiates
session with relay
Peers can now
communicate through
NATs via relay

13

Chapter 2: Summary

Chapter 2: Application layer

2.1 Principles of
network applications
2.2 Web and HTTP
2.3 FTP
2.4 Electronic Mail

2.5 DNS

SMTP, POP3, IMAP

2.6 P2P applications

2.7 Socket programming
with UDP
2.8 Socket programming
with TCP
(See Sockets slide deck)

Study of network apps now complete!

Application architectures
client-server
P2P
hybrid

Application service
requirements:

specific protocols:
-

HTTP
DNS
P2P: BitTorrent, Skype

socket programming

reliability, bandwidth,
delay

Internet transport
service model
connection-oriented,
reliable: TCP
unreliable, datagrams: UDP

Chapter 2: Summary
Learned about protocols

Typical request/reply
message exchange:
client requests info or
service
server responds with
data, status code

Message formats:
headers: fields giving
info about data
data: info being
communicated

Important themes:

- control vs data msgs

- in-band, out-of-band
- centralized
t li d vs
decentralized
- stateless vs stateful
- reliable vs unreliable
msg transfer
- complexity at network
edge

14