Intro CN Ch02 Class

Chapter 2
Application Layer
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 Computer Networking:
A Top Down Approach ,
(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: 6th edition.
Jim Kurose, Keith Ross
 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 Addison-Wesley, March
you note that they are adapted from (or perhaps identical to) our slides, and
note our copyright of this material.
2012.
Thanks and enjoy! JFK/KWR
All material copyright 1996-2012

2: Application Layer 1
J.F Kurose and K.W. Ross, All Rights Reserved
Chapter 2: Application Layer
Our goals:  learn about protocols
 conceptual, by examining popular
implementation application-level
aspects of network protocols
application protocols  HTTP
 transport-layer  FTP
service models  SMTP / POP3 / IMAP
DNS
 client-server

paradigm  programming network

 peer-to-peer
applications
socket API
paradigm 
Chapter 2: Application layer
 2.1 Principles of  2.6 P2P file sharing
network applications  2.7 Socket programming
 2.2 Web and HTTP with TCP
 2.3 FTP  2.8 Socket programming
 2.4 Electronic Mail with UDP
 SMTP, POP3, IMAP  Building a Web server
 2.5 DNS by Unix socket
programming
Some network apps
 e-mail  voice over IP
 web  real-time video
 instant messaging conferencing
 remote login  grid computing
 P2P file sharing  …
 multi-user network  …
games  …
 streaming stored video
clips
Creating a network app application
transport
network
data link
write programs that physical
 run on (different) end

systems
 communicate over network
 e.g., web server software
communicates with browser
software application
little software written for

transport
network
data link
devices in network core
application
physical
transport
network
 network core devices do data link
physical
not run user applications
 applications on end systems
allows for rapid app
development, propagation
programming
Application architectures
 Client-server
 Peer-to-peer (P2P)
 Hybrid of client-server and P2P
Client-server architecture
server:
 always-on host
 permanent IP address
 server farms for
scaling
clients:
client/server  communicate with server
 may be intermittently
connected
 may have dynamic IP
addresses
 do not communicate
directly with each other
Pure P2P architecture
 no always-on server
 arbitrary end systems
directly communicate peer-peer
 peers are intermittently
connected and change IP
addresses
 example: Gnutella
Highly scalable but

difficult to manage
Hybrid of client-server and P2P
Skype
 voice-over-IP P2P application
 centralized server: finding address of remote
party:
 client-client connection: direct (not through
server)
Processes communicating
Process: program running Client process: process
within a host. that initiates
 within same host, two
communication
processes communicate Server process: process
using inter-process that waits to be
communication (defined contacted
by OS).
 processes in different  Note: applications with
hosts communicate by P2P architectures have
exchanging messages client processes &
server processes
Sockets
 process sends/receives
host or host or
server server
messages to/from its
socket controlled by
app developer
 socket analogous to door process process
 sending process shoves socket socket

message out door TCP with TCP with
Internet buffers,
 sending process relies on buffers,
variables variables
transport infrastructure
on other side of door which
brings message to socket controlled
by OS
at receiving process
 API: (1) choice of transport protocol; (2) ability to fix

a few parameters (lots more on this later)
Addressing processes
 to receive messages,
process must have
identifier
 host device has unique
32-bit IP address
 Q: does IP address of
host on which process
runs suffice for
identifying the process?
Addressing processes
 to receive messages,  identifier includes both
process must have IP address and port
identifier numbers associated with
 host device has unique process on host.
32-bit IP address  Example port numbers:
 Q: does IP address of  HTTP server: 80
host on which process  Mail server: 25
runs suffice for  to send HTTP message
identifying the to gaia.cs.umass.edu web
process? server:
 A: No, many  IP address: 128.119.245.12
processes can be  Port number: 80
running on same host  more shortly…
App-layer protocol defines
 Types of messages Public-domain protocols:
exchanged,  defined in RFCs
 e.g., request, response  allows for
 Message syntax: interoperability
 what fields in messages &
 e.g., HTTP, SMTP
how fields are delineated
Proprietary protocols:
 Message semantics
 meaning of information in
 e.g., Skype
fields
 Rules for when and how
processes send &
respond to messages
What transport service does an app need?
Data loss Throughput
 some apps (e.g., audio) can  some apps (e.g.,
tolerate some loss multimedia) require
 other apps (e.g., file minimum amount of
transfer, telnet) require bandwidth to be
100% reliable data
So
transfer called “Quality of Service”
“effective”
 other apps (“elastic
Timing apps”) make use of
 some apps (e.g., whatever bandwidth
Internet telephony, they get
interactive games)
require low delay to be
“effective”
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

video:10kbps-5Mbps

video:10kbps-5Mbps

video:10kbps-5Mbps
Internet transport protocols services
TCP service: UDP service:

 connection-oriented: setup  unreliable data transfer
required between client and between sending and
server processes receiving process
 reliable transport between  does not provide:
sending and receiving process connection setup,
 flow control: sender won’t reliability, flow control,
overwhelm receiver congestion control, timing,
or bandwidth guarantee
 congestion control: throttle
sender when network
overloaded Q: why bother? Why is
 does not provide: timing, there a UDP?
minimum bandwidth
guarantees
Internet apps: application, transport protocols
Application Underlying
Application layer protocol transport protocol
e-mail SMTP [RFC 2821] TCP

remote terminal access Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
file transfer FTP [RFC 959] TCP
streaming multimedia proprietary TCP or UDP
(e.g. RealNetworks)
Internet telephony proprietary
(e.g., Vonage,Dialpad) typically UDP
 app architectures with TCP
app requirements
 2.8 Socket programming

 2.2 Web and HTTP with UDP

 2.3 FTP  Building a Web server
 2.4 Electronic Mail by Unix socket
 SMTP, POP3, IMAP programming
 2.5 DNS
Web and HTTP
First some jargon
 Web page consists of objects
 Object can be HTML file, JPEG image, Java
applet, audio file,…
 Web page consists of base HTML-file which
includes several referenced objects
 Each object is addressable by a URL
 Example URL:
www.someschool.edu/someDept/pic.gif
host name path name
HTTP overview
HTTP: hypertext
transfer protocol
 Web’s application layer PC running
protocol Explorer
 client/server model
 client: browser that
requests, receives, Server
“displays” Web objects running
Apache Web
 server: Web server
server
sends objects in
response to requests
Mac running
Navigator
HTTP overview (continued)
Uses TCP: HTTP is “stateless”
 client initiates TCP  server maintains no
connection (creates socket) information about
to server, port 80 past client requests
 server accepts TCP
connection from client aside
Protocols that maintain
 HTTP messages (application- “state” are complex!
layer protocol messages)  past history (state) must
exchanged between browser be maintained
(HTTP client) and Web
 if server/client crashes,
server (HTTP server)
their views of “state” may
 TCP connection closed
be inconsistent, must be
reconciled
HTTP connections
Nonpersistent HTTP Persistent HTTP
 At most one object is  Multiple objects can
sent over a TCP be sent over single
connection. TCP connection
between client and
server.
Nonpersistent HTTP
(contains text,
Suppose user enters URL references to 10
www.someSchool.edu/someDepartment/home.index jpeg images)
1a. HTTP client initiates TCP

connection to HTTP server
(process) at
1b. HTTP server at host
www.someSchool.edu waiting
www.someSchool.edu on port 80
for TCP connection at port 80.
“accepts” connection, notifying
client
2. HTTP client sends HTTP
request message (containing
URL) into TCP connection 3. HTTP server receives request
socket. Message indicates message, forms response
that client wants object message containing requested
someDepartment/home.index object, and sends message
into its socket
time
Nonpersistent HTTP (cont.)
4. HTTP server closes TCP

connection.
5. HTTP client receives response
message containing html file,
displays html. Parsing html
file, finds 10 referenced jpeg
objects
time 6. Steps 1-5 repeated for each
of 10 jpeg objects
Non-Persistent HTTP: Response time
Definition of RTT: time to
send a small packet to
travel from client to
server and back. initiate TCP
connection
Response time: RTT
 one RTT to initiate TCP request
file
connection time to
RTT
transmit
 one RTT for HTTP file
request and first few file
received
bytes of HTTP response
to return time time
 file transmission time
total = 2RTT+transmit time
Persistent HTTP
Nonpersistent HTTP issues: Persistent HTTP

 requires 2 RTTs per object  server leaves connection
 OS overhead for each TCP open after sending
connection response
 browsers often open parallel  subsequent HTTP messages
TCP connections to fetch between same
referenced objects client/server sent over
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
 two types of HTTP messages: request, response

 HTTP request message:
 ASCII (human-readable format)
request line
(GET, POST, GET /somedir/page.html HTTP/1.1
HEAD commands) Host: www.someschool.edu
User-agent: Mozilla/4.0
header Connection: close
lines Accept-language:fr
Carriage return,
line feed (extra carriage return, line feed)
indicates end
of message
HTTP request message: general format
Method types
HTTP/1.0 HTTP/1.1
 GET  GET, POST, HEAD
 POST  PUT
 HEAD  uploads file in entity
body to path specified
 asks server to leave
in URL field
requested object out of
response  DELETE
 deletes file specified in
the URL field
HTTP response message
status line
(protocol
status code HTTP/1.1 200 OK
status phrase) Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
header
Last-Modified: Mon, 22 Jun 1998 …...
lines
Content-Length: 6821
Content-Type: text/html
data, e.g., data data data data data ...

requested
HTML file
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 www.eurecom.fr 80 Opens TCP connection to port 80
(default HTTP server port) at www.eurecom.fr.
Anything typed in sent
to port 80 at www.eurecom.fr
2. Type in a GET HTTP request:

GET /~ross/index.html HTTP/1.0 By typing this in (hit carriage
return twice), you send
this minimal (but complete)
GET request to HTTP server
3. Look at response message sent by HTTP server!
User-server state: cookies
Example:
Many major Web sites
use cookies  Susan always access
Four components: Internet always from PC
1) cookie header line of  visits specific e-
HTTP response message commerce site for first
2) cookie header line in time
HTTP request message
3) cookie file kept on  when initial HTTP
user’s host, managed by requests arrives at site,
user’s browser
site creates:
4) back-end database at
Web site  unique ID
 entry in backend
database for ID
Cookies: keeping “state”
client server
ebay 8734
usual http request msg
Amazon server
cookie file usual http response creates ID
Set-cookie: 1678 1678 for user create
ebay 8734 entry
amazon 1678
usual http request msg
cookie: 1678 cookie- access
specific
one week later: usual http response msg action backend
database
access
ebay 8734 usual http request msg
amazon 1678 cookie: 1678 cookie-
spectific
usual http response msg action
Cookies (continued)
aside
What cookies can bring: Cookies and privacy:
 authorization  cookies permit sites to
 shopping carts
learn a lot about you
 you may supply name
 recommendations
and e-mail to sites
 user session state
(Web e-mail)
How to keep “state”:
 protocol endpoints: maintain state
at sender/receiver over multiple
transactions
 cookies: http messages carry state
Conditional GET
 Goal: don’t send object if cache server

cache has up-to-date cached HTTP request msg
version
object
If-modified-since:
 cache: specify date of
<date>
not
cached copy in HTTP request modified
HTTP response
If-modified-since:
HTTP/1.0
<date> 304 Not Modified
 server: response contains no
object if cached copy is up-
HTTP request msg
to-date: If-modified-since:
HTTP/1.0 304 Not <date> object
Modified modified
HTTP response
HTTP/1.0 200 OK
<data>
Web caches (proxy server)
Goal: satisfy client request without involving origin server
 user sets browser: origin

server
Web accesses via
cache Proxy
 browser sends all server
client
HTTP requests to
cache
 object in cache: cache
returns object
 else cache requests
object from origin client
origin
server, then returns server
object to client
More about Web caching
 Cache acts as both client Why Web caching?
and server
 Typically cache is installed
by ISP (university,
company, residential ISP)
Caching example
Assumptions origin
 average object size = 100,000
servers
bits public
 avg. request rate from Internet
institution’s browsers to origin
servers = 15/sec
 delay from institutional router
to any origin server and back 1.5 Mbps
to router = 2 sec access link
Consequences
institutional
 data rate 1.5Mbps network
 utilization on LAN = 15% 10 Mbps LAN
 utilization on access link = 100%
 total delay = Internet delay +
access delay + LAN delay
= 2 sec + minutes + milliseconds institutional
cache
Why?
Queueing Delay
 R=link bandwidth (bps)

 L=packet length (bits)
 a=average packet
arrival rate
traffic intensity = La/R
 La/R ~ 0: average queueing delay small

 La/R -> 1: delays become large
 La/R > 1: more “work” arriving than can be
serviced, average delay infinite!
Caching example (cont)
origin
Possible solution
servers
 increase bandwidth of access
link to, say, 10 Mbps public
Internet
Consequences
 utilization on LAN = 15%
 utilization on access link = 15%
10 Mbps
 Total delay = Internet delay + access link
access delay + LAN delay
institutional
= 2 sec + msecs + msecs
network
 often a costly upgrade 10 Mbps LAN
institutional
cache
Caching example (cont)
origin
Install cache servers
 suppose hit rate is .4 public
Consequence Internet
 40% requests will be
satisfied almost immediately
 60% requests satisfied by
origin server 1.5 Mbps
access link
 utilization of access link
reduced to 60%, resulting in institutional
negligible delays (say 10 network
10 Mbps LAN
msec)
 total avg delay = Internet
delay + access delay + LAN
delay = .6*(2.01) secs +
milliseconds < 1.4 secs institutional
cache
and server
 Typically cache is installed
by ISP (university,
company, residential ISP)
and server  Reduce response time for
 Typically cache is installed client request.
by ISP (university,  Reduce traffic on an
company, residential ISP) institution’s access link.
 Internet dense with caches
enables “poor” content
providers to effectively
deliver content (but so
does P2P file sharing)
programming
FTP: the file transfer protocol
目前無法顯示此圖像。
FTP file transfer

FTP FTP
user client server
interface
user
at host local file remote file
system system
 transfer file to/from remote host

 client/server model
 client: side that initiates transfer (either to/from
remote)
 server: remote host
 ftp: RFC 959
 ftp server: port 21
FTP: separate control, data connections
TCP control connection
 FTP client contacts FTP port 21
server at port 21, specifying
TCP as transport protocol
TCP data connection
 Client obtains authorization FTP port 20 FTP
over control connection client server
 Client browses remote
 Server opens a second TCP
directory by sending
commands over control data connection to transfer
connection. another file.
 Control connection: “out of
 When server receives a
command for a file transfer, band”
the server opens a TCP data  FTP server maintains “state”:
connection to client current directory, earlier
 After transferring one file, authentication
server closes connection.
FTP commands, responses
Sample commands: Sample return codes

 sent as ASCII text over  status code and phrase (as
control channel in HTTP)
 USER username  331 Username OK,
 PASS password password required
 125 data connection
 LIST return list of file in
already open;
current directory
transfer starting
 RETR filename retrieves  425 Can’t open data
(gets) file connection
 STOR filename stores  452 Error writing
(puts) file onto remote file
host
programming
Electronic Mail outgoing
message queue
user mailbox
user
Three major components: agent
 user agents mail
user
server
 mail servers agent
 simple mail transfer SMTP mail
protocol: SMTP server user
SMTP agent
User Agent
 a.k.a. “mail reader” SMTP
mail user
 composing, editing, reading agent
server
mail messages
 e.g., Eudora, Outlook, elm, user
Netscape Messenger agent
user
 outgoing, incoming messages agent
stored on server
Electronic Mail: mail servers
user
Mail Servers agent
 mailbox contains incoming mail
user
messages for user server
agent
 message queue of outgoing
SMTP
(to be sent) mail messages mail
server user
 SMTP protocol between mail
servers to send email SMTP agent
messages SMTP
 client: sending mail mail user
agent
server server
 “server”: receiving mail
user
server agent
user
agent
Electronic Mail: SMTP [RFC 2821]
 uses TCP to reliably transfer email message from client

to server, port 25
 direct transfer: sending server to receiving server
 three phases of transfer
 handshaking (greeting)
 transfer of messages
 closure
 command/response interaction
 commands: ASCII text
 response: status code and phrase
 messages must be in 7-bit ASCII
Scenario: Alice sends message to Bob
1) Alice uses UA to compose 4) SMTP client sends Alice’s
message and “to” message over the TCP
bob@someschool.edu connection
2) Alice’s UA sends message 5) Bob’s mail server places the
to her mail server; message message in Bob’s mailbox
placed in message queue 6) Bob invokes his user agent
3) Client side of SMTP opens to read message
TCP connection with Bob’s
mail server
1 mail
mail
server user
user server
2 agent
agent 3 6
4 5
Sample SMTP interaction
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
Try SMTP interaction for yourself:
 telnet servername 25
 see 220 reply from server
 enter HELO, MAIL FROM, RCPT TO, DATA, QUIT
commands
above lets you send email without using email client
(reader)
SMTP: final words
 SMTP uses persistent Comparison with HTTP:
connections
 HTTP: pull
 SMTP requires message
(header & body) to be in 7-  SMTP: push
bit ASCII  both have ASCII
 SMTP server uses command/response
CRLF.CRLF to determine interaction, status codes
end of message
 HTTP: each object
encapsulated in its own
response msg
 SMTP: multiple objects
sent in multipart msg
Mail message format
SMTP: protocol for

exchanging email msgs header
blank
RFC 822: standard for text
line
message format:
 header lines, e.g.,
To:

body
 From:
 Subject:
different from SMTP
commands!
 body
 the “message”, ASCII
characters only
Mail access protocols
SMTP SMTP
目前無法顯示此圖像。
access user
user
agent protocol agent
sender’s mail receiver’s mail

server server
 SMTP: delivery/storage to receiver’s server
 Mail access protocol: retrieval from server
 POP: Post Office Protocol [RFC 1939]
• authorization (agent <-->server) and download
 IMAP: Internet Mail Access Protocol [RFC 1730]
• more features (more complex)
• manipulation of stored messages on server
 HTTP: Hotmail , Yahoo! Mail, etc.
POP3 protocol S: +OK POP3 server ready
C: user bob
authorization phase S: +OK
C: pass hungry
 client commands: S: +OK user successfully logged on
 user: declare username
C: list
 pass: password S: 1 498
 server responses S: 2 912
S: .
 +OK
C: retr 1
 -ERR S: <message 1 contents>
transaction phase, client: S: .
C: dele 1
 list: list message numbers C: retr 2
 retr: retrieve message by S: <message 2 contents>
number S: .
C: dele 2
 dele: delete
C: quit
 quit S: +OK POP3 server signing off
POP3 (more) and IMAP
More about POP3 IMAP
 Previous example uses  Keep all messages in
“download and delete” one place: the server
mode.  Allows user to
 Bob cannot re-read e- organize messages in
mail if he changes folders
client  IMAP keeps user state
 “Download-and-keep”: across sessions:
copies of messages on  names of folders and
different clients mappings between
message IDs and folder
 POP3 is stateless
name
across sessions
programming
DNS: Domain Name System
People: many identifiers: Domain Name System:

 SSN, name, passport #  distributed database
Internet hosts, routers: implemented in hierarchy of
many name servers
 IP address (32 bit) -
 application-layer protocol
used for addressing
host, routers, name servers to
datagrams
communicate to resolve names
 “name”, e.g., (address/name translation)
gaia.cs.umass.edu - used
 note: core Internet
by humans
function, implemented as
Q: map between IP application-layer protocol
addresses and name ?  complexity at network’s
“edge”
DNS name servers
Why not centralize DNS?  no server has all name-
 single point of failure to-IP address mappings
 traffic volume local name servers:
 each ISP, company has
 distant centralized
local (default) name server
database  host DNS query first goes
 maintenance to local name server
authoritative name server:
doesn’t scale!  for a host: stores that
host’s IP address, name
 can perform name/address
translation for that host’s
name
Distributed, Hierarchical Database
Root DNS Servers
com DNS servers org DNS servers edu DNS servers
pbs.org poly.edu umass.edu

yahoo.com amazon.com
DNS servers DNS serversDNS servers
DNS servers 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
DNS: Root name 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 NSI Herndon, VA
c PSInet Herndon, VA k RIPE London
d U Maryland College Park, MD i NORDUnet Stockholm
g DISA Vienna, VA
h ARL Aberdeen, MD
j NSI (TBD) Herndon, VA m WIDE Tokyo
e NASA Mt View, CA
f Internet Software C. Palo Alto,
CA
13 root name
b USC-ISI Marina del Rey, CA servers worldwide
l ICANN Marina del Rey, CA
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:
 organization’s DNS servers, providing
authoritative hostname to IP mappings for
organization’s servers (e.g., Web, mail).
 can be maintained by organization or service
provider
Local Name Server
 does not strictly belong to hierarchy
 each ISP (residential ISP, company,
university) has one.
 also called “default name server”
 when host makes DNS query, query is sent
to its local DNS server
 acts as proxy, forwards query into hierarchy
DNS name root DNS server
resolution example
2
 Host at cis.poly.edu 3
TLD DNS server
wants IP address for 4
gaia.cs.umass.edu 5
iterated query: local DNS server

dns.poly.edu
 contacted server 7 6
replies with name of 1 8
server to contact
authoritative DNS server
 “I don’t know this
dns.cs.umass.edu
name, but ask this requesting host
server” cis.poly.edu
gaia.cs.umass.edu
DNS name
resolution example root DNS server
recursive query: 2 3
 puts burden of name 6
7
resolution on
TLD DNS server
contacted name
server
 heavy load? local DNS server
dns.poly.edu 5 4
1 8
authoritative DNS server

dns.cs.umass.edu
requesting host
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 cached in local name
servers
• Thus root name servers not often visited
 update/notify mechanisms under design by IETF
 RFC 2136
 http://www.ietf.org/html.charters/dnsind-charter.html
DNS records
DNS: distributed db storing resource records (RR)
RR format: (name, value, type,ttl)
 Type=A  Type=CNAME
 name is hostname  name is alias name for some
 value is IP address “cannonical” (the real) name
www.ibm.com is really
 Type=NS
servereast.backup2.ibm.com
 name is domain (e.g.
 value is cannonical name
foo.com)
 value is IP address of
 Type=MX
authoritative name
 value is name of mailserver
server for this domain
associated with name
DNS protocol, messages
DNS protocol : query and reply messages, both with
same message format
msg header
 identification: 16 bit #
for query, reply to query
uses same #
 flags:
 query or reply
 recursion desired
 recursion available
 reply is authoritative
DNS protocol, messages
Name, type fields

for a query
RRs in reponse
to query
records for
authoritative servers
additional “helpful”
info that may be used
Inserting records into DNS
 example: new startup “Network Utopia”
 register name networkuptopia.com at DNS registrar
(e.g., Network Solutions)
 provide names, IP addresses of authoritative name server
(primary and secondary)
 registrar inserts two RRs into com TLD server:
(networkutopia.com, dns1.networkutopia.com, NS)

(dns1.networkutopia.com, 212.212.212.1, A)
 create authoritative server Type A record for

www.networkuptopia.com; Type MX record for
networkutopia.com
 How do people get IP address of your Web site?
 app architectures with TCP
app requirements
 2.8 Socket programming

 2.2 Web and HTTP with UDP

 2.3 FTP  Building a Web server
 2.4 Electronic Mail by Unix socket
 SMTP, POP3, IMAP programming
 2.5 DNS
Pure P2P architecture
 no always-on server
 arbitrary end systems
directly communicate peer-peer
 peers are intermittently
connected and change IP
addresses
 Three topics:
 File distribution
 Searching for information
 Case Study: Skype
Comparing Client-server, P2P architectures
Question : How much time distribute file
initially at one server to N other computers?
us: server upload
bandwidth
Server
ui: client/peer i
u1 d1 u2 upload bandwidth
us d2
di: client/peer i
File, size F download bandwidth
dN
Network (with
uN abundant bandwidth)
Client-server: file distribution time
Server
 server sequentially F u1 d1 u2
sends N copies: us d2
 NF/us time dN Network (with

abundant bandwidth)
 client i takes F/di uN
time to download
Time to distribute F
to N clients using = dcs = max { NF/us, F/min(di) }
i
client/server approach
increases linearly in N
(for large N) 2: Application Layer 83
P2P: file distribution time
Server
 server must send one
F u1 d1 u2
copy: F/us time us d2
 client i takes F/di time

Network (with
to download
dN
abundant bandwidth)
 NF bits must be
uN
downloaded (aggregate)
 fastest possible upload rate (assuming
all nodes sending file chunks to same
peer): us + ui
i=1,N
dP2P = max { F/us, F/min(di) , NF/(us + ui) }

i i=1,N
Server-client vs. P2P: example
Client upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us
3.5
P2P
Minimum Distribution Time
3
Client-Server
2.5
1.5
0.5
0
0 5 10 15 20 25 30 35
N
P2P Case Study: BitTorrent
 P2P file distribution
tracker: tracks peers torrent: group of

participating in torrent peers exchanging
chunks of a file
obtain list
of peers
trading
chunks
peer
BitTorrent (1)
 file divided into 256KB chunks.
 peer joining torrent:
 has no chunks, but will accumulate them over time
 registers with tracker to get list of peers,
connects 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 (2)
Pulling Chunks Sending Chunks: tit-for-tat
 at any given time,  Alice sends chunks to
different peers have four neighbors currently
different subsets of sending her chunks at the
file chunks highest rate
 periodically, a peer  re-evaluate top 4
(Alice) asks each every 10 secs
neighbor for list of  every 30 secs: randomly
chunks that they have. select another peer,
 Alice issues requests starts sending chunks
for her missing chunks  newly chosen peer may
 rarest first join top 4
BitTorrent: Tit-for-tat
(1) Alice “optimistically unchokes” Bob
(2) Alice becomes one of Bob’s top-four providers; Bob reciprocates
(3) Bob becomes one of Alice’s top-four providers
With higher upload rate,

can find better trading
partners & get file faster!
Distributed Hash Table (DHT)
 DHT = distributed P2P database
 Database has (key, value) pairs;
 key: ss number; value: human name
 key: content type; value: IP address
 Peers query DB with key

 DB returns values that match the key
 Peers can also insert (key, value) peers

DHT Identifiers
 Assign integer identifier to each peer in range
[0,2n-1].
 Each identifier can be represented by n bits.
 Require each key to be an integer in same range.
 To get integer keys, hash original key.
 eg, 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 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
Circular DHT (1)
1
3
15
4
12
5
10
8
 Each peer only aware of immediate successor
and predecessor.
 “Overlay network”
Circle DHT (2)
O(N) messages 0001 Who’s resp

on avg to resolve for key 1110 ?
I am
query, when there 0011
are N peers
1111
1110
1110 0100
1110
1100
1110
1110 0101
Define closest 1110
as closest 1010
successor 1000
Circular DHT with Shortcuts
1 Who’s resp
for key 1110?
3
15
4
12
5
10
8
 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
Peer Churn
1
•To handle peer churn, require
3 each peer to know the IP address
15
of its two successors.
• Each peer periodically pings its
4 two successors to see if they
12 are still alive.
5
10
8
 Peer 5 abruptly leaves
 Peer 4 detects; makes 8 its immediate successor;
asks 8 who its immediate successor is; makes 8’s
immediate successor its second successor.
 What if peer 13 wants to join?
P2P Case study: Skype
Skype clients (SC)
 P2P (pc-to-pc, pc-to-
phone, phone-to-pc)
Voice-Over-IP (VoIP) Skype
application login server Supernode
 also IM (SN)
 proprietary
application-layer
protocol (inferred via
reverse engineering)
 hierarchical overlay
Peers as relays
 Problem when both
Alice and Bob are
behind “NATs”.
 NAT prevents an outside
peer from initiating a call
to insider peer
 Solution:
 Using Alice’s and Bob’s
SNs, Relay is chosen
 Each peer initiates
session with relay.
 Peers can now
communicate through
NATs via relay
programming
Socket programming
Goal: learn how to build client/server application that
communicate using sockets
Socket API Socket API

 introduced in BSD4.1 UNIX,
1981 a, application-created,
 explicitly created, used, OS-controlled interface
released by apps (a “door”) into which
 client/server paradigm application process can
 two types of transport both send and
service via socket API: receive messages to/from
 unreliable datagram another application
(UDP) process
 reliable, byte stream-
oriented (TCP)

Socket-programming using TCP
Socket: a door between application process and end-
end-transport protocol (UCP or TCP)
TCP service: reliable transfer of bytes from one
process to another
controlled by
controlled by process application
application process
developer
developer socket socket
controlled by TCP with TCP with controlled by
buffers, operating
operating buffers, internet system
system variables variables
host or host or
server server
More in Chap 3 2: Application Layer 101
Socket programming with TCP
Client must contact server  When contacted by client,
 server process must first server TCP creates new
be running socket for server process to
 server must have created communicate with client
socket (door) that  allows server to talk with
welcomes client’s contact multiple clients
 source port numbers
Client contacts server by:
used to distinguish
 creating client-local TCP
clients (more in Chap3)
socket
 specifying IP address, port application viewpoint
number of server process
TCP provides reliable, in-order
 When client creates
transfer of bytes (“pipe”)
socket: client TCP
between client and server
establishes connection to
server TCP
Stream jargon
 A stream is a sequence of
characters that flow into
or out of a process.
 An input stream is
attached to some input
source for the process, eg,
keyboard or socket.
 An output stream is
attached to an output
source, eg, monitor or
socket.

 2.5 DNS

Socket programming with UDP
UDP: no “connection” between

client and server
 no handshaking
 sender explicitly attaches application viewpoint
IP address and port of
destination to each packet UDP provides unreliable transfer
of groups of bytes (“datagrams”)
 server must extract IP
between client and server
address, port of sender
from received packet
UDP: transmitted data may be
received out of order, or
lost

Unix Network Programming
The socket
struct and data handling
System calls
Based on Beej's Guide to Network Programming
Building a simple Web server
 handles one HTTP  after creating server,
request you can request file
 accepts the request using a browser (eg IE
explorer)
 parses header
 see text for details
 obtains requested file
from server’s file
system
 creates HTTP response
message:
 header lines + file
 sends response to client

Chapter 2: Summary
Our study of network apps now complete!
 application service  specific protocols:
requirements:  HTTP
 reliability, bandwidth,  FTP
delay
 SMTP, POP, IMAP
 client-server paradigm  DNS
 Internet transport  socket programming
service model
 connection-oriented,
reliable: TCP
 unreliable, datagrams:
UDP

Chapter 2: Summary
Most importantly: learned about protocols
 typical request/reply Important themes:

message exchange:  control vs. data msgs
client requests info or
in-band, out-of-band


service
 server responds with  centralized vs.
data, status code decentralized
 message formats:  stateless vs. stateful
 headers: fields giving  reliable vs. unreliable
info about data msg transfer
 data: info being
communicated  “complexity at network
edge”

Intro CN Ch02 Class

Uploaded by

Copyright:

Available Formats

You might also like

Intro CN Ch02 Class

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Intro CN Ch02 Class

Uploaded by

Copyright:

Available Formats

Chapter 2

A note on the use of these ppt slides:

Thanks and enjoy! JFK/KWR

All material copyright 1996-2012

paradigm  programming network

write programs that physical

 run on (different) end

little software written for

Highly scalable but

 sending process shoves socket socket

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

Application Data loss Bandwidth Time Sensitive

file transfer no loss elastic no

Application Data loss Bandwidth Time Sensitive

file transfer no loss elastic no

Application Data loss Bandwidth Time Sensitive

file transfer no loss elastic no

Application Data loss Bandwidth Time Sensitive

file transfer no loss elastic no

TCP service: UDP service:

e-mail SMTP [RFC 2821] TCP

 2.2 Web and HTTP with UDP

host name path name

1a. HTTP client initiates TCP

4. HTTP server closes TCP

Nonpersistent HTTP issues: Persistent HTTP

 two types of HTTP messages: request, response

data, e.g., data data data data data ...

1. Telnet to your favorite Web server:

2. Type in a GET HTTP request:

3. Look at response message sent by HTTP server!

 Goal: don’t send object if cache server

 user sets browser: origin

 R=link bandwidth (bps)

traffic intensity = La/R

 La/R ~ 0: average queueing delay small

FTP file transfer

 transfer file to/from remote host

Sample commands: Sample return codes

 uses TCP to reliably transfer email message from client

 messages must be in 7-bit ASCII

SMTP: protocol for

sender’s mail receiver’s mail

People: many identifiers: Domain Name System:

com DNS servers org DNS servers edu DNS servers

pbs.org poly.edu umass.edu

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

iterated query: local DNS server

authoritative DNS server

Name, type fields

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

 create authoritative server Type A record for

 2.2 Web and HTTP with UDP

 NF/us time dN Network (with

 client i takes F/di time

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

tracker: tracks peers torrent: group of

With higher upload rate,