chapter2_5th-4

8/22/2019 Chapter2_5th-4

http://slidepdf.com/reader/full/chapter25th-4 1/119

2: Application Layer 1

Chapter 2

Application Layer

Computer Networking: A Top Down Approach ,5th edition.Jim Kurose, Keith RossAddison-Wesley, April2009.

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

8/22/2019 Chapter2_5th-4



8/22/2019 Chapter2_5th-4



Chapter 2: Application layer

r 2.1 Principles ofnetwork applications

r 2.2 Web and HTTP

r 2.3 FTPr 2.4 Electronic Mail

SMTP, POP3, IMAP

r 2.5 DNS

r 2.6 P2P applications

r 2.7 Socket programmingwith UDP

r 2.8 Socket programmingwith TCP

8/22/2019 Chapter2_5th-4



Chapter 2: Application Layer

Our goals: r conceptual,

implementationaspects of network

application protocols transport-layer

service models

client-server

paradigm peer-to-peer

paradigm

r learn about protocolsby examining popularapplication-levelprotocols

HTTP FTP

SMTP / POP3 / IMAP

DNS

r programming networkapplications

socket API

8/22/2019 Chapter2_5th-4



Some network apps

r e-mail

r web

r instant messaging

r remote loginr P2P file sharing

r multi-user networkgames

r streaming stored videoclips

r social networks

r voice over IP

r real-time video

conferencingr grid computing

8/22/2019 Chapter2_5th-4



Creating a network app

write programs that run on (different) end

systems

communicate over network

e.g., web server softwarecommunicates with browsersoftware

No need to write softwarefor network-core devices Network-core devices do

not run user applications

applications on end systemsallows for rapid appdevelopment, propagation

application transportnetworkdata link

physical

application transportnetwork

data linkphysical

application transportnetworkdata linkphysical

8/22/2019 Chapter2_5th-4





r 2.2 Web and HTTP

r 2.3 FTPr 2.4 Electronic Mail

SMTP, POP3, IMAP

r 2.5 DNS




8/22/2019 Chapter2_5th-4



Application architectures

r Client-server Including data centers / cloud computing

r Peer-to-peer (P2P)

r Hybrid of client-server and P2P

8/22/2019 Chapter2_5th-4



Client-server architecture

server: always-on host

permanent IP address

server farms forscaling

clients: communicate with server

may be intermittently

connected may have dynamic IP

addresses

do not communicatedirectly with each other

client/server

8/22/2019 Chapter2_5th-4


Google Data Centers

r Estimated cost of data center: $600M

r Google spent $2.4B in 2007 on new datacenters

r Each data center uses 50-100 megawattsof power

8/22/2019 Chapter2_5th-4



Pure P2P architecture

r no always-on server

r arbitrary end systemsdirectly communicate

r peers are intermittentlyconnected and change IPaddresses

Highly scalable butdifficult to manage

peer-peer

8/22/2019 Chapter2_5th-4



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)Instant messaging

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

addresses of buddies

8/22/2019 Chapter2_5th-4



Processes communicating

Process: program runningwithin a host.

r within same host, twoprocesses communicate

using inter-processcommunication (definedby OS).

r processes in different

hosts communicate byexchanging messages

Client process: processthat initiatescommunication

Server process: process

that waits to becontacted

r Note: applications with

P2P architectures haveclient processes &server processes

8/22/2019 Chapter2_5th-4



Sockets

r process sends/receivesmessages to/from itssocket

r socket analogous to door sending process shoves

message out door

sending process relies ontransport infrastructureon other side of door whichbrings message to socketat receiving process

process

TCP with

buffers,

variables

socket

host or server

process

TCP with

buffers,

variables

socket

host or server

Internet

controlled by OS

controlled by

app developer

r API: (1) choice of transport protocol; (2) ability to fixa few parameters (lots more on this later)

8/22/2019 Chapter2_5th-4



Addressing processes

r

to receive messages,process must haveidentifier

r host device has unique32-bit IP address

r Exercise: use ipconfig from command prompt toget your IP address(Windows)

r Q: does IP address of

host on which processruns suffice foridentifying the process?

A: No, many processes

can be running onsame

r Identifier includes bothIP address and portnumbers associated withprocess on host.

r Example port numbers: HTTP server: 80

Mail server: 25

8/22/2019 Chapter2_5th-4



App-layer protocol defines

r Types of messagesexchanged, e.g., request, response

r Message syntax: what fields in messages &

how fields are delineated

r Message semantics meaning of information in

fieldsr Rules for when and how

processes send &respond to messages

Public-domain protocols:

r defined in RFCs

r allows for

interoperabilityr e.g., HTTP, SMTP,BitTorrent

Proprietary protocols:

r e.g., Skype, ppstream

8/22/2019 Chapter2_5th-4



What transport service does an app need?

Data loss r some apps (e.g., audio) can

tolerate some lossr other apps (e.g., file

transfer, telnet) require

100% reliable datatransfer Timing r some apps (e.g.,

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

Throughput

r some apps (e.g.,multimedia) requireminimum amount ofthroughput to be

“effective” r other apps (“elastic apps”)

make use of whateverthroughput they get

Securityr Encryption, data

integrity, …

8/22/2019 Chapter2_5th-4



Transport service requirements of common apps

Application

file transfer

e-mail

Web documentsreal-time audio/video

stored audio/video

interactive games

instant messaging

Data loss

no loss

no loss

no lossloss-tolerant

loss-tolerant

loss-tolerant

no loss

Throughput

elastic

elastic

elasticaudio: 5kbps-1Mbps

video:10kbps-5Mbps

same as above

few kbps up

elastic

Time Sensitive

no

no

noyes, 100’s msec

yes, few secs

yes, 100’s msec

yes and no

8/22/2019 Chapter2_5th-4



Internet transport protocols services

TCP service: r connection-oriented: setup

required between client andserver processes

r reliable transport betweensending and receiving process

r flow control: sender won’toverwhelm receiver

r congestion control: throttle

sender when networkoverloaded

r does not provide: timing,minimum throughputguarantees, security

UDP service: r unreliable data transfer

between sending andreceiving process

r does not provide:connection setup,reliability, flow control,congestion control, timing,throughput guarantee, orsecurity

Q: why bother? Why isthere a UDP?

8/22/2019 Chapter2_5th-4



Internet apps: application, transport protocols

Application

e-mail

remote terminal access

Webfile transfer

streaming multimedia

Internet telephony

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

Underlyingtransport protocol

TCP

TCP

TCPTCP

TCP or UDP

typically UDP

8/22/2019 Chapter2_5th-4





r 2.2 Web and HTTP

r

2.3 FTPr 2.4 Electronic Mail SMTP, POP3, IMAP

r 2.5 DNS



r

2.8 Socket programmingwith TCP

8/22/2019 Chapter2_5th-4



Web and HTTP

First some jargon

r Web page consists of objects

r Object can be HTML file, JPEG image, Java

applet, audio file,… r Web page consists of base HTML-file whichincludes several referenced objects

r Each object is addressable by a URL

r Example URL:www.someschool.edu/someDept/pic.gif

host name path name

8/22/2019 Chapter2_5th-4



HTTP overview

HTTP: hypertexttransfer protocol

r Web’s application layerprotocol

r client/server model client: browser that

requests, receives,“displays” Web objects

server: Web server

sends objects inresponse to requests

PC runningExplorer

Serverrunning

Apache Web

server

Mac runningNavigator

8/22/2019 Chapter2_5th-4



HTTP overview (continued)

Uses TCP: r client initiates TCP

connection (creates socket)to server, port 80

r server accepts TCPconnection from client

r HTTP messages (application-layer protocol messages)exchanged between browser

(HTTP client) and Webserver (HTTP server)

r TCP connection closed

HTTP is “stateless” r server maintains no

information aboutpast client requests

Protocols that maintain“state” are complex!

r past history (state) mustbe maintained

r if server/client crashes,their views of “state” maybe inconsistent, must bereconciled

aside

8/22/2019 Chapter2_5th-4



HTTP connections

Nonpersistent HTTP

r At most one object issent over a TCPconnection.

Persistent HTTP

r Multiple objects canbe sent over singleTCP connectionbetween client andserver.

8/22/2019 Chapter2_5th-4



Nonpersistent HTTPSuppose user enters URL

www.someSchool.edu/someDepartment/home.index

1a. HTTP client initiates TCPconnection to HTTP server(process) at

www.someSchool.edu on port 80

2. HTTP client sends HTTPrequest message (containingURL) into TCP connection

socket. Message indicatesthat client wants objectsomeDepartment/home.index

1b. HTTP server at hostwww.someSchool.edu waiting

for TCP connection at port 80.“accepts” connection, notifyingclient

3. HTTP server receives request

message, forms response message containing requestedobject, and sends messageinto its socket

time

(contains text,

references to 10

jpeg images)

8/22/2019 Chapter2_5th-4



Nonpersistent HTTP (cont.)

5. HTTP client receives responsemessage containing html file,displays html. Parsing htmlfile, finds 10 referenced jpegobjects

6. Steps 1-5 repeated for eachof 10 jpeg objects

4. HTTP server closes TCPconnection.

time

8/22/2019 Chapter2_5th-4



Non-Persistent HTTP: Response time

Definition of RTT: time fora small packet to travelfrom client to serverand back.

Response time:

r one RTT to initiate TCPconnection

r one RTT for HTTPrequest and first fewbytes of HTTP responseto return

r file transmission time

total = 2RTT+transmit time

time totransmitfile

initiate TCPconnection

RTT

requestfile

RTT

file

received

time time

8/22/2019 Chapter2_5th-4



Persistent HTTP

Nonpersistent HTTP issues: r requires 2 RTTs per object

r OS overhead for each TCPconnection

r browsers often open parallel

TCP connections to fetchreferenced objects

Persistent HTTP r server leaves connection

open after sendingresponse

r subsequent HTTP messages

between sameclient/server sent overopen connection

r client sends requests assoon as it encounters a

referenced objectr as little as one RTT for all

the referenced objects

8/22/2019 Chapter2_5th-4



HTTP request message

r two types of HTTP messages: request , response

r HTTP request message: ASCII (human-readable format)

GET /somedir/page.html HTTP/1.1

Host: www.someschool.edu

User-agent: Mozilla/4.0

Connection: close

Accept-language:fr

(extra carriage return, line feed)

request line(GET, POST,

HEAD commands)

header

lines

Carriage return,line feed

indicates end

of message

8/22/2019 Chapter2_5th-4



HTTP request message: general format

8/22/2019 Chapter2_5th-4



Uploading form input

Post method:

r Web page oftenincludes form input

r Input is uploaded toserver in entity body

URL method:

r Uses GET method

r Input is uploaded inURL field of requestline:

www.somesite.com/animalsearch?monkeys&banana

8/22/2019 Chapter2_5th-4



Method types

HTTP/1.0

r GET

r POST

r HEAD asks server to leave

requested object out ofresponse

HTTP/1.1

r GET, POST, HEAD

r PUT uploads file in entity

body to path specifiedin URL field

r DELETE deletes file specified in

the URL field

8/22/2019 Chapter2_5th-4



HTTP response message

HTTP/1.1 200 OK

Connection close

Date: Thu, 06 Aug 1998 12:00:15 GMT

Server: Apache/1.3.0 (Unix)

Last- Modified: Mon, 22 Jun 1998 …...

Content-Length: 6821

Content-Type: text/html

data data data data data ...

status line(protocolstatus code

status phrase)

headerlines

data, e.g.,

requestedHTML file

8/22/2019 Chapter2_5th-4



HTTP response status 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 server404 Not Found

requested document not found on this server

505 HTTP Version Not Supported

In first line in server->client response message.A few sample codes:

8/22/2019 Chapter2_5th-4



Trying out HTTP (client side) for yourself

1. Telnet to your favorite Web server:

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

telnet cis.poly.edu 80

2. Type in a GET HTTP request:

GET /~ross/ HTTP/1.1

Host: cis.poly.edu

By typing this in (hit carriagereturn twice), you send

this minimal (but complete)GET request to HTTP server

3. Look at response message sent by HTTP server!

8/22/2019 Chapter2_5th-4



User-server state: cookies

Many major Web sitesuse cookies

Four components:1) cookie header line of

HTTP response message2) cookie header line inHTTP request message

3) cookie file kept onuser’s host, managed byuser’s browser

4) back-end database atWeb site

Example:r Susan always access

Internet always from PC

r visits specific e-

commerce site for firsttime

r when initial HTTPrequests arrives at site,

site creates: unique ID

entry in backenddatabase for ID

8/22/2019 Chapter2_5th-4



Cookies: keeping “state” (cont.)

client

server

usual http response msg

usual http response msg

cookie file

one week later:

usual http request msgcookie: 1678 cookie-

specificaction

access

ebay 8734usual http request msg Amazon server

creates ID1678 for user create

entry

usual http responseSet-cookie: 1678

ebay 8734amazon 1678

usual http request msgcookie: 1678 cookie-

spectificaction

accessebay 8734

amazon 1678

backenddatabase

8/22/2019 Chapter2_5th-4



Cookies (continued)

What cookies can bring: r authorization

r shopping carts

r recommendations

r user session state(Web e-mail)

Cookies and privacy: r cookies permit sites to

learn a lot about you

r you may supply name

and e-mail to sites

aside

How to keep “state”:

r protocol endpoints: maintain stateat sender/receiver over multipletransactions

r cookies: http messages carry state

8/22/2019 Chapter2_5th-4



Web caches (proxy server)

r user sets browser:Web accesses viacache

r browser sends allHTTP requests tocache object in cache: cache

returns object else cache requests

object from originserver, then returnsobject to client

Goal: satisfy client request without involving origin server

client

Proxy

server

client originserver

originserver

8/22/2019 Chapter2_5th-4



More about Web caching

r cache acts as bothclient and server

r typically cache isinstalled by ISP

(university, company,residential ISP)

Why Web caching?

r reduce response timefor client request

r reduce traffic on aninstitution’s accesslink.

r Internet dense withcaches: enables “poor”

content providers toeffectively delivercontent (but so doesP2P file sharing)

8/22/2019 Chapter2_5th-4



Caching example

Assumptions r average object size =

1,000,000 bits

r avg. request rate frominstitution’s browsers to origin

servers = 15/secr delay from institutional router

to any origin server and backto router = 2 sec

Consequences r utilization on LAN = 15%

r utilization on access link = 100%

r total delay = Internet delay +access delay + LAN delay

= 2 sec + minutes + milliseconds

origin

servers

publicInternet

institutionalnetwork 100 Mbps LAN

15 Mbpsaccess link

institutionalcache

8/22/2019 Chapter2_5th-4



Caching example (cont)

possible solution r increase bandwidth of access

link to, say, 100 Mbps

consequence r utilization on LAN = 15%

r utilization on access link = 15%

r Total delay = Internet delay +access delay + LAN delay

= 2 sec + msecs + msecs

r often a costly upgrade

origin

servers

publicInternet


100 Mbpsaccess link

institutionalcache

8/22/2019 Chapter2_5th-4



Caching example (cont)

possible solution: installcache

r suppose hit rate is 0.4consequence r 40% requests will be

satisfied almost immediatelyr 60% requests satisfied by

origin serverr utilization of access link

reduced to 60%, resulting innegligible delays (say 10

msec)r total avg delay = Internet

delay + access delay + LANdelay = .6*(2.01) secs +.4*milliseconds < 1.4 secs

origin

servers

publicInternet


15 Mbpsaccess link

institutionalcache

8/22/2019 Chapter2_5th-4



Conditional GET

r Goal: don’t send object ifcache has up-to-date cachedversion

r cache: specify date ofcached copy in HTTP requestIf-modified-since:

<date>

r server: response contains noobject if cached copy is up-to-date:HTTP/1.0 304 Not

Modified

cache server

HTTP request msgIf-modified-since:

<date>

HTTP responseHTTP/1.0

304 Not Modified

objectnot

modified

HTTP request msgIf-modified-since:

<date>

HTTP responseHTTP/1.0 200 OK

<data>

objectmodified

8/22/2019 Chapter2_5th-4





r 2.2 Web and HTTP

r 2.3 FTP

r 2.4 Electronic Mail SMTP, POP3, IMAP

r 2.5 DNS

r 2.6 P2P applicationsr 2.7 Socket programming

with UDP


8/22/2019 Chapter2_5th-4



FTP: the file transfer protocol

r transfer file to/from remote host

r client/server model

client: side that initiates transfer (either to/from

remote) server: remote host

r ftp: RFC 959

r ftp server: port 21

file transfer FTP

server

FTPuser

interface

FTPclient

local filesystem

remote file

system

userat host

8/22/2019 Chapter2_5th-4



FTP: separate control, data connections

r FTP client contacts FTP serverat port 21, TCP is transportprotocol

r client authorized over controlconnection

r client browses remotedirectory by sending commandsover control connection.

r when server receives file

transfer command, serveropens 2 nd TCP connection (forfile) to client

r after transferring one file,server closes data connection.

FTPclient

FTPserver

TCP control connectionport 21

TCP data connectionport 20

r server opens another TCPdata connection to transferanother file.

r control connection: “out of

band” r FTP server maintains “state”:

current directory, earlierauthentication

8/22/2019 Chapter2_5th-4



FTP commands, responses

Sample commands: r sent as ASCII text over

control channelr USER username

r PASS password r LIST return list of file in

current directory

r RETR filename retrieves

(gets) filer STOR filename stores

(puts) file onto remotehost

Sample return codes r status code and phrase (as

in HTTP)r 331 Username OK,

password required r 125 data connection

already open;

transfer starting

r 425 Can’t open data

connectionr 452 Error writing

file

8/22/2019 Chapter2_5th-4





r 2.2 Web and HTTP

r 2.3 FTP


r 2.5 DNS


with UDP


8/22/2019 Chapter2_5th-4



Electronic Mail

Three major components: r user agents

r mail servers

r simple mail transfer

protocol: SMTP

User Agent

r a.k.a. “mail reader”

r composing, editing, reading

mail messagesr e.g., Eudora, Outlook, elm,

Mozilla Thunderbird

r outgoing, incoming messagesstored on server

user mailbox

outgoingmessage queue

mail

server

useragent

useragent

useragent

mailserver

useragent

useragent

mailserver

useragent

SMTP

SMTP

SMTP

8/22/2019 Chapter2_5th-4



Electronic Mail: mail servers

Mail Servers r mailbox contains incoming

messages for user

r message queue of outgoing

(to be sent) mail messagesr SMTP protocol between mail

servers to send emailmessages

client: sending mail

server “server”: receiving mail

server

mailserver

useragent

useragent

useragent

mail

server

useragent

useragent

mailserver

useragent

SMTP

SMTP

SMTP

8/22/2019 Chapter2_5th-4



Electronic Mail: SMTP [RFC 2821]

r uses TCP to reliably transfer email message from clientto server, port 25

r direct transfer: sending server to receiving server

r three phases of transfer

handshaking (greeting) transfer of messages

closure

r command/response interaction

commands: ASCII text

response: status code and phrase

r messages must be in 7-bit ASCII

S i Ali d t B b

8/22/2019 Chapter2_5th-4



Scenario: Alice sends message to Bob

1) Alice uses UA to compose

message and “to”[email protected]

2) Alice’s UA sends messageto her mail server; messageplaced in message queue

3) Client side of SMTP opensTCP connection with Bob’smail server

4) SMTP client sends Alice’s

message over the TCPconnection

5) Bob’s mail server places themessage in Bob’s mailbox

6) Bob invokes his user agent

to read message

useragent

mailserver

mailserver user

agent

1

2 3 4 56

8/22/2019 Chapter2_5th-4



Sample SMTP interactionS: 220 hamburger.edu

C: HELO crepes.frS: 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 okC: 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

8/22/2019 Chapter2_5th-4



Try SMTP interaction for yourself:

r telnet servername 25 r see 220 reply from server

r enter HELO, MAIL FROM, RCPT TO, DATA, QUIT commands

above lets you send email without using email client(reader)

8/22/2019 Chapter2_5th-4



SMTP: final words

r SMTP uses persistentconnections

r SMTP requires message(header & body) to be in 7-bit ASCII

r SMTP server usesCRLF.CRLF to determineend of message

Comparison with HTTP:r HTTP: pull

r SMTP: push

r both have ASCIIcommand/responseinteraction, status codes

r HTTP: each objectencapsulated in its own

response msgr SMTP: multiple objects

sent in multipart msg

8/22/2019 Chapter2_5th-4



Mail message format

SMTP: protocol forexchanging email msgs

RFC 822: standard for textmessage format:

r header lines, e.g., To:

From:

Subject:

different from SMTP commands !

r body the “message”, ASCII

characters only

header

body

blankline

8/22/2019 Chapter2_5th-4



Mail access protocols

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

POP: Post Office Protocol [RFC 1939]

• authorization (agent <-->server) and download

IMAP: Internet Mail Access Protocol [RFC 1730]• more features (more complex)

• manipulation of stored msgs on server

HTTP: gmail, Hotmail, Yahoo! Mail, etc.

useragent

sender’s mailserver

useragent

SMTP SMTP accessprotocol

receiver’s mailserver

8/22/2019 Chapter2_5th-4



POP3 protocol

authorization phase r client commands:

user: declare username

pass: password

r server responses +OK

-ERR

transaction phase, client:

r list: list message numbers

r retr: retrieve message bynumber

r dele: delete

r quit

C: list

S: 1 498

S: 2 912

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

S: +OK POP3 server ready

C: user bob

S: +OK

C: pass hungry

S: +OK user successfully logged on

8/22/2019 Chapter2_5th-4



POP3 (more) and IMAP

More about POP3 r Previous example uses

“download and delete”mode.

r Bob cannot re-read e-mail if he changesclient

r “Download-and-keep”:copies of messages ondifferent clients

r POP3 is statelessacross sessions

IMAP r Keep all messages in

one place: the server

r Allows user to

organize messages infolders

r IMAP keeps user stateacross sessions:

names of folders andmappings betweenmessage IDs and foldername

8/22/2019 Chapter2_5th-4





r 2.2 Web and HTTP

r 2.3 FTP


r 2.5 DNS


with UDP


8/22/2019 Chapter2_5th-4



DNS: Domain Name System

People: many identifiers: SSN, name, passport #

Internet hosts, routers: IP address (32 bit) -

used for addressingdatagrams

“name”, e.g.,ww.yahoo.com - used byhumans

Q: map between IPaddresses and name ?

Domain Name System: r distributed database

implemented in hierarchy ofmany name servers

r application-layer protocol host, routers, name servers tocommunicate to resolve names(address/name translation)

note: core Internet

function, implemented asapplication-layer protocol

complexity at network’s“edge”

8/22/2019 Chapter2_5th-4



DNS

Why not centralize DNS?r single point of failure

r traffic volume

r distant centralized

databaser maintenance

doesn’t scale!

DNS servicesr hostname to IP

address translation

r host aliasing Canonical, alias names

r mail server aliasing

r load distribution replicated Web

servers: set of IPaddresses for onecanonical name

Distributed Hierarchical Database

8/22/2019 Chapter2_5th-4



Root DNS Servers

com DNS servers org DNS servers edu DNS servers

poly.edu

DNS servers

umass.edu

DNS serversyahoo.com

DNS servers

amazon.com

DNS servers

pbs.org

DNS servers

Distributed, Hierarchical Database

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

r client queries a root server to find com DNS server

r client queries com DNS server to get amazon.comDNS server

r client queries amazon.com DNS server to get IPaddress for www.amazon.com

8/22/2019 Chapter2_5th-4



DNS: Root name servers

r contacted by local name server that can not resolve name

r root name server:

contacts authoritative name server if name mapping not known

gets mapping

returns mapping to local name server

13 root nameservers worldwide

b USC-ISI Marina del Rey, CA

l ICANN Los Angeles, CA

e NASA Mt View, CA

f Internet Software C. Palo Alto,

CA (and 36 other locations)

i Autonomica, Stockholm (plus

28 other locations)

k RIPE London (also 16 other locations)

m WIDE Tokyo (also Seoul,

Paris, SF)

a Verisign, 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)

8/22/2019 Chapter2_5th-4



TLD and Authoritative Servers

r 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

r 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

8/22/2019 Chapter2_5th-4



Local Name Server

r does not strictly belong to hierarchyr each ISP (residential ISP, company,

university) has one.

also called “default name server” r when host makes DNS query, query is sent

to its local DNS server acts as proxy, forwards query into hierarchy

DNDNS name

8/22/2019 Chapter2_5th-4



requesting host cis.poly.edu

gaia.cs.umass.edu

root DNS server

local DNS server dns.poly.edu

1

2 3

4

5

6

authoritative DNS server

dns.cs.umass.edu

7 8

TLD DNS server

DNS nameresolution example

r Host at cis.poly.eduwants IP address forgaia.cs.umass.edu

iterated query:r contacted server

replies with name ofserver to contact

r “I don’t know this

name, but ask thisserver”

DNS name

8/22/2019 Chapter2_5th-4



requesting host cis.poly.edu

gaia.cs.umass.edu

root DNS server

local DNS server dns.poly.edu

1

2

4 5

6

authoritative DNS server dns.cs.umass.edu

7

8

TLD DNS server

3 recursive query: r puts burden of name

resolution oncontacted name

serverr heavy load?

DNS nameresolution example

8/22/2019 Chapter2_5th-4



DNS: caching and updating records

r once (any) name server learns mapping, it caches mapping

cache entries timeout (disappear) after sometime

TLD servers typically cached in local nameservers• Thus root name servers not often visited

r update/notify mechanisms under design by IETF

RFC 2136 http://www.ietf.org/html.charters/dnsind-charter.html

8/22/2019 Chapter2_5th-4



DNS records

DNS: distributed db storing resource records (RR)

r Type=NS name is domain (e.g.

foo.com) value is hostname of

authoritative nameserver for this domain

RR format: (name, value, type, ttl)

r Type=A

name is hostname value is IP address

r Type=CNAME

name is alias name for some“canonical” (the real) name www.ibm.com is really servereast.backup2.ibm.com

value is canonical name

r Type=MX value is name of mailserver

associated with name

l

8/22/2019 Chapter2_5th-4



DNS protocol, messages

DNS protocol : query and reply messages, both withsame message format

msg headerr identification: 16 bit #

for query, reply to queryuses same #

r flags:

query or reply

recursion desired

recursion available reply is authoritative

DN l

8/22/2019 Chapter2_5th-4



DNS protocol, messages

Name, type fieldsfor a query

RRs in response

to query

records forauthoritative servers

additional “helpful” info that may be used

I i d i DNS

8/22/2019 Chapter2_5th-4



Inserting records into DNS

r example: new startup “Network Utopia” r 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)

r create authoritative server Type A record forwww.networkuptopia.com; Type MX record fornetworkutopia.com

r How do people get IP address of your Web site?

Ch t 2 A li ti l

8/22/2019 Chapter2_5th-4





r 2.2 Web and HTTP

r 2.3 FTP


r 2.5 DNS


with UDP

r 2.8 Socket programming

with TCP

P P2P hit t

8/22/2019 Chapter2_5th-4



Pure P2P architecture

r no always-on serverr arbitrary end systems

directly communicate

r peers are intermittently

connected and change IPaddresses

r Three topics: File distribution Searching for information

Case Study: Skype

peer-peer

Fil Di t ib ti S Cli t P2P

8/22/2019 Chapter2_5th-4



File Distribution: Server-Client vs P2PQuestion : How much time to distribute file

from one server to N peers ?

us

u2 d 1

d 2 u1

uN

d N

Server

Network (withabundant bandwidth)

File, size F

us: server upload

bandwidth

ui

:

peer i uploadbandwidth

d i : peer i download

bandwidth

Fil di ib i i li

8/22/2019 Chapter2_5th-4



File distribution time: server-client

us

u2 d 1 d 2 u1

uN

d N

Server


F r server sequentially

sends N copies: NF/u s time

r client i takes F/ditime to download

increases linearly in N

(for large N)

= dcs = max { NF/u s , F/min(d i ) }i

Time to distribute F to N clients using

client/server approach

Fil di t ib ti ti P2P

8/22/2019 Chapter2_5th-4



File distribution time: P2P

us

u2 d 1 d 2 u1

uN

d N

Server


F r server must send one

copy: F/u s time

r client i takes F/di timeto download

r NF bits must bedownloaded (aggregate)r fastest possible upload rate: us + Sui

dP2P = max { F/u s , F/min(d i ) , NF/(us + Sui) }i

S li t P2P l

8/22/2019 Chapter2_5th-4



0

0.5

1

1.5

2

2.5

3

3.5

0 5 10 15 20 25 30 35

N

M i n i m u m D

i s t r i b u t i o n T i m e P2P

Client-Server

Server-client vs. P2P: example

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

Fil di t ib ti BitT t

8/22/2019 Chapter2_5th-4



File distribution: BitTorrent

tracker: tracks peersparticipating in torrent

torrent: group ofpeers exchangingchunks of a file

obtain listof peers

trading

chunks

peer

r P2P file distribution

8/22/2019 Chapter2_5th-4



BitTorrent (1)

r file divided into 256KB chunks .

r 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”)

r while downloading, peer uploads chunks to other

peers.r peers may come and go

r once peer has entire file, it may (selfishly) leave or(altruistically) remain

BitT t (2)

8/22/2019 Chapter2_5th-4



BitTorrent (2)

Pulling Chunksr at any given time,

different peers havedifferent subsets of

file chunksr periodically, a peer(Alice) asks eachneighbor for list ofchunks that they have.

r Alice sends requestsfor her missing chunks

rarest first

Sending Chunks: tit-for-tat

r Alice sends chunks to fourneighbors currentlysending her chunks at the highest rate

re-evaluate top 4 every

10 secsr every 30 secs: randomly

select another peer,starts sending chunks

newly chosen peer may join top 4

“optimistically unchoke”

BitT t Tit f t t

8/22/2019 Chapter2_5th-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 tradingpartners & get file faster!

Distributed Hash Table (DHT)

8/22/2019 Chapter2_5th-4


Distributed Hash Table (DHT)

r DHT = distributed P2P databaser Database has (key, value) pairs;

key: ss number; value: human name

key: content type; value: IP addressr Peers query DB with key

DB returns values that match the key

r Peers can also insert (key, value) peers

DHT Identifiers

8/22/2019 Chapter2_5th-4


DHT Identifiers

r Assign integer identifier to each peer in range[0,2n-1]. Each identifier can be represented by n bits.

r Require each key to be an integer in same range.r 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?

8/22/2019 Chapter2_5th-4


How to assign keys to peers?

r Central issue: Assigning (key, value) pairs to peers.

r Rule: assign key to the peer that has the

closest ID.r Convention in lecture: closest is the

immediate successor of the key.

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

8/22/2019 Chapter2_5th-4


1

3

4

5

810

12

15

Circular DHT (1)

r Each peer only aware of immediate successorand predecessor.

r “Overlay network”

Circle DHT (2)

8/22/2019 Chapter2_5th-4


Circle DHT (2)

0001

0011

0100

0101

10001010

1100

1111

Who’s resp

for key 1110 ?I am

O(N) messages

on avg to resolve

query, when there

are N peers

1110

1110

1110

1110

1110

1110

Define closestas closestsuccessor

Circular DHT with Shortcuts

8/22/2019 Chapter2_5th-4


u DH w u

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(logN) messages in query

1

3

4

5

810

12

15

Who’s resp

for key 1110?

Peer Churn

8/22/2019 Chapter2_5th-4


Peer 5 abruptly leaves

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

1

3

4

5

810

12

15

•To handle peer churn, require

each peer to know the IP addressof its two successors.

• Each peer periodically pings itstwo successors to see if they

are still alive.

P2P Case study: Skype

8/22/2019 Chapter2_5th-4



P2P Case study: Skype

inherently P2P: pairsof users communicate.

proprietaryapplication-layer

protocol (inferred viareverse engineering)

hierarchical overlaywith SNs

Index maps usernamesto IP addresses;distributed over SNs

Skype clients (SC)

Supernode

(SN)

Skypelogin server

Peers as relays

8/22/2019 Chapter2_5th-4



Peers as relays

Problem when bothAlice and Bob arebehind “NATs”. NAT prevents an outside

peer from initiating a call

to insider peerSolution: Using Alice’s and Bob’s

SNs, Relay is chosen Each peer initiates

session with relay. Peers can now

communicate throughNATs via relay


8/22/2019 Chapter2_5th-4




2.1 Principles ofnetwork applications

2.2 Web and HTTP

2.3 FTP

2.4 Electronic Mail SMTP, POP3, IMAP

2.5 DNS

2.6 P2P applications2.7 Socket programmingwith UDP

2.8 Socket programming

with TCP

Socket programming

8/22/2019 Chapter2_5th-4



Socket programming

Socket API introduced in BSD4.1 UNIX,1981

explicitly created, used,released by apps

client/server paradigm

two types of transport

service via socket API: UDP

TCP

A application-created ,OS-controlled interface

(a “door”) into which application process can

both send andreceive messages to/from

another applicationprocess

socket

Goal: learn how to build client/server application that

communicate using sockets

Socket programming basics

8/22/2019 Chapter2_5th-4


Socket programming basics

Server must berunning beforeclient can sendanything to it.

Server must have asocket (door)through which it

receives and sendssegments

Similarly clientneeds a socket

Socket is locallyidentified with a portnumber Analogous to the apt #

in a building

Client needs to knowserver IP address and

socket port number.


Socket programming with UDP

8/22/2019 Chapter2_5th-4



Socket programming with UDP

UDP: no “connection” betweenclient and server

no handshaking

sender explicitly attachesIP address and port of

destination to each segmentOS attaches IP address andport of sending socket toeach segment

Server can extract IPaddress, port of senderfrom received segment

application viewpoint

UDP provides unreliable transfer of groups of bytes (“datagrams”) between client and server

Note: the official terminologyfor a UDP packet is “datagram”.In this class, we instead use “UDPsegment”.

Running example

8/22/2019 Chapter2_5th-4


Running example

Client: User types line of text

Client program sends line to server

Server: Server receives line of text

Capitalizes all the letters

Sends modified line to client

Client: Receives line of text

Displays


Client/server socket interaction: UDP

8/22/2019 Chapter2_5th-4



Client/server socket interaction: UDP

Server (running on hostid )

close

clientSocket

read datagram fromclientSocket

create socket,

clientSocket =

DatagramSocket()

Client

Create datagram with server IP andport=x; send datagram via

clientSocket

create socket,

port= x.

serverSocket =

DatagramSocket()

read datagram from

serverSocket

write reply to

serverSocket

specifyingclient address,

port number

Example: Java client (UDP)

8/22/2019 Chapter2_5th-4




s e n d P a c k e t

to network from network

r e c e i v e P a c k e t

i n F r o m U s e r

keyboard monito r

Process

clientSocket

UDPpacket

inputstream

UDPpacket

UDPsocket

Output: sendspacket (recall

that TCP sent“byte stream”)

Input: receivespacket (recallthatTCP received“byte stream”)

Client

process

client UDPsocket


8/22/2019 Chapter2_5th-4




import java.io.*;import java.net.*;

class UDPClient {

public static void main(String args[]) throws Exception

{

BufferedReader inFromUser =new BufferedReader(new InputStreamReader(System.in));

DatagramSocket clientSocket = new DatagramSocket();

InetAddress IPAddress = InetAddress.getByName("hostname");

byte[] sendData = new byte[1024];

byte[] receiveData = new byte[1024];

String sentence = inFromUser.readLine();

sendData = sentence.getBytes();

Create

input stream Create

client socket

Translatehostname to IP

address using DNS

Example: Java client (UDP) cont

8/22/2019 Chapter2_5th-4



Example: Java client (UDP), cont.

DatagramPacket sendPacket =

new DatagramPacket(sendData, sendData.length, IPAddress, 9876);

clientSocket.send(sendPacket);

DatagramPacket receivePacket =

new DatagramPacket(receiveData, receiveData.length);

clientSocket.receive(receivePacket);

String modifiedSentence =

new String(receivePacket.getData());

System.out.println("FROM SERVER:" + modifiedSentence);

clientSocket.close();

}

}

Create datagramwith data-to-send,

length, IP addr, port

Send datagramto server

Read datagramfrom server

Example: Java server (UDP)

8/22/2019 Chapter2_5th-4



Example: Java server (UDP)

import java.io.*;import java.net.*;

class UDPServer {

public static void main(String args[]) throws Exception

{

DatagramSocket serverSocket = new DatagramSocket(9876);

byte[] receiveData = new byte[1024];

byte[] sendData = new byte[1024];

while(true)

{

DatagramPacket receivePacket =

new DatagramPacket(receiveData, receiveData.length);

serverSocket.receive(receivePacket);

Createdatagram socket

at port 9876

Create space forreceived datagram

Receivedatagram

Example: Java server (UDP) cont

8/22/2019 Chapter2_5th-4



Example: Java server (UDP), cont

String sentence = new String(receivePacket.getData());

InetAddress IPAddress = receivePacket.getAddress();

int port = receivePacket.getPort();

String capitalizedSentence = sentence.toUpperCase();

sendData = capitalizedSentence.getBytes();

DatagramPacket sendPacket =

new DatagramPacket(sendData, sendData.length, IPAddress,

port);

serverSocket.send(sendPacket);}

}

}

Get IP addrport #, of

sender

Write out

datagramto socket

End of while loop,loop back and wait foranother datagram

Create datagramto send to client

UDP observations & questions

8/22/2019 Chapter2_5th-4


UDP observations & questions

Both client server use DatagramSocketDest IP and port are explicitly attached tosegment.

What would happen if change both clientSocketand serverSocket to “mySocket”? Can the client send a segment to server withoutknowing the server’s IP address and/or port

number?Can multiple clients use the server?



8/22/2019 Chapter2_5th-4




2.1 Principles ofnetwork applications

2.2 Web and HTTP

2.3 FTP

2.4 Electronic Mail SMTP, POP3, IMAP

2.5 DNS

2.6 P2P applications2.7 Socket programmingwith UDP

2.8 Socket programming

with TCP

Socket-programming using TCP

8/22/2019 Chapter2_5th-4



Socket programming using TCP

TCP service: reliable transfer of bytes from oneprocess to another

process

TCP with

buffers,variables

socket

controlled byapplicationdeveloper

controlled by

operatingsystem

host orserver

process

TCP withbuffers,variables

socket

controlled byapplicationdeveloper

controlled byoperatingsystem

host orserver

internet

Socket programming with TCP

8/22/2019 Chapter2_5th-4




Client must contact server

server process must firstbe running

server must have createdsocket (door) thatwelcomes client’s contact

Client contacts server by:

creating client-local TCPsocket

specifying IP address, port

number of server processWhen client createssocket: client TCPestablishes connection toserver TCP

When contacted by client,server TCP creates newsocket for server process tocommunicate with client

allows server to talk withmultiple clients

source port numbersused to distinguishclients (more in Chap 3)

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

application viewpoint

Client/server socket interaction: TCP

8/22/2019 Chapter2_5th-4



Client/server socket interaction TCP

wait for incomingconnection request connectionSocket =

welcomeSocket.accept()

create socket,port=x, for

incoming request: welcomeSocket =

ServerSocket()

create socket,connect to hostid , port=x clientSocket =

Socket()

close

connectionSocket

read reply from

clientSocket

close

clientSocket

Server (running on hostid ) Client

send request using

clientSocket read request from

connectionSocket

write reply to

connectionSocket

TCPconnection setup

Stream jargon

8/22/2019 Chapter2_5th-4



o u t T o S e r v e r

to network from network

i n F r o m S e r v e r

i n F r o m U s e r

keyboard monitor

Process

clientSocket

input

stream

input

stream

output

stream

TCP

socket

Client

process

client TCPsocket

Stream jargon

A stream is a sequence ofcharacters that flow intoor out of a process.

An input stream isattached to some input

source for the process,e.g., keyboard or socket.

An output stream isattached to an outputsource, e.g., monitor or

socket.


8/22/2019 Chapter2_5th-4




Example client-server app: 1) client reads line fromstandard input (inFromUser stream) , sends to server viasocket (outToServer

stream)2) server reads line from socket

3) server converts line touppercase, sends back toclient

4) client reads, prints modifiedline from socket(inFromServer stream)

Example: Java client (TCP)

8/22/2019 Chapter2_5th-4



Example Java client (TCP)

import java.io.*;

import java.net.*;

class TCPClient {

public static void main(String argv[]) throws Exception

{

String sentence;String modifiedSentence;

BufferedReader inFromUser =

new BufferedReader(new InputStreamReader(System.in));

Socket clientSocket = new Socket("hostname", 6789);

DataOutputStream outToServer =

new DataOutputStream(clientSocket.getOutputStream());

Createinput stream

Create

client socket,connect to server

Createoutput stream

attached to socket

Example: Java client (TCP), cont.

8/22/2019 Chapter2_5th-4



Example Java cl ent ( CP), cont.

BufferedReader inFromServer =

new BufferedReader(new

InputStreamReader(clientSocket.getInputStream()));

sentence = inFromUser.readLine();

outToServer.writeBytes(sentence + '\n');

modifiedSentence = inFromServer.readLine();

System.out.println("FROM SERVER: " + modifiedSentence);

clientSocket.close();

}

}

Createinput stream

attached to socket

Send lineto server

Read linefrom server

Example: Java server (TCP)

8/22/2019 Chapter2_5th-4



E amp Ja a s r r ( )import java.io.*;

import java.net.*;

class TCPServer {

public static void main(String argv[]) throws Exception

{

String clientSentence;

String capitalizedSentence;

ServerSocket welcomeSocket = new ServerSocket(6789);

while(true) {

Socket connectionSocket = welcomeSocket.accept();

BufferedReader inFromClient =

new BufferedReader(new

InputStreamReader(connectionSocket.getInputStream()));

Createwelcoming socket

at port 6789

Wait, on welcomingsocket for contact

by client Create input

stream, attachedto socket

Example: Java server (TCP), cont

8/22/2019 Chapter2_5th-4



E mp J ( ),

DataOutputStream outToClient =

new DataOutputStream(connectionSocket.getOutputStream());

clientSentence = inFromClient.readLine();

capitalizedSentence = clientSentence.toUpperCase() + '\n';

outToClient.writeBytes(capitalizedSentence);

}

}

}

Read in linefrom socket

Create outputstream, attached

to socket

Write out lineto socket

End of while loop,loop back and wait foranother client connection

TCP observations & questions

8/22/2019 Chapter2_5th-4


Server has two types of sockets: ServerSocket and Socket

When client knocks on serverSocket’s “door,”server creates connectionSocket and completes

TCP conx.Dest IP and port are not explicitly attached tosegment.

Can multiple clients use the server?


Chapter 2: Summary

8/22/2019 Chapter2_5th-4


2: Application Layer

118

application architectures client-server

P2P

hybrid

application servicerequirements: reliability, bandwidth,

delay

Internet transportservice model connection-oriented,

reliable: TCP

unreliable, datagrams: UDP

our study of network apps now complete!

specific protocols: HTTP

FTP

SMTP, POP, IMAP

DNS P2P: BitTorrent, Skype

socket programming

Chapter 2: Summary

8/22/2019 Chapter2_5th-4


p y

typical request/replymessage exchange: client requests info or

service server responds with

data, status code

message formats:

headers: fields givinginfo about data

data: info beingi t d

Most importantly: learned about protocols Important themes:

control vs. data msgs

in-band, out-of-bandcentralized vs.decentralized

stateless vs. stateful

reliable vs. unreliablemsg transfer

“complexity at network

chapter2_5th-4

Documents