CN Chp2 (Compatibility Mode)

.
Computer Networks
Application Layer
jamali@ iust.ac.ir June 23, 2010 Application Layer 2 -1

Chapter 2 Outline
2.1 Principles of 2.6 Socket

app layer protocols programming with TCP
clients and servers 2.7 Socket
app requirements programming with UDP
2.2 Web and HTTP 2.8 Building a Web
2.3 FTP server
2.4 Electronic Mail 2.9 Content
SMTP, POP3, IMAP
distribution
Network Web caching
2.5 DNS
Content distribution
networks
P2P file sharing

Network Applications
within same host, two implements user

processes communicate interface &
using inter-process application-level
communication (defined protocol
by OS). Web: browser
processes running in E-mail: mail reader
different hosts streaming audio/video:
communicate with an media player
application-layer
protocol
user agent: interfaces
Process: program running with user “above” and
within a host. network “below”.

From Application Viewpoint
Application-layer protocols:
one “piece” of the application; define
messages exchanged by apps and
actions taken.
the application
App. Software Controlled

Application Software application by App. Soft.
(API)
Application Program Interface (API) transport
Communication Software & Hardware network Controlled
by OS
Platform (OS + Hardware) link
physical

Client/Server Applications
Application Process Application Process

Application
(Client Side)
process (Server Side)
Application Program Interface (API) Application Program Interface (API)
Communication Software & Hardware Communication Software & Hardware

Platform (OS + Hardware) Platform (OS + Hardware)
Server Agents Examples:

Internet Information
Sever + http, Appachi +
http
Communication
SQL query engines + http
Network
Communication Software
Examples: TCP, UDP; IP…

Applications and Application-
Application-Layer Protocols
Application: communicating,
distributed processes application
transport
network
e.g., e-mail, Web, P2P file data link
sharing, instant messaging physical
modem
running in end systems
(hosts)
exchange messages to modem
implement application
Application-layer protocols
one “piece” of an app
define messages
exchanged by apps and
application
actions taken transport application
network transport
use communication data link network
physical data link
services provided by lower physical
layer protocols (TCP, UDP)

Application--Layer Protocols
Application
Types of messages Public-domain protocols:

exchanged: request & defined in RFCs
response messages
allows for
Syntax of message
types: what fields in interoperability
messages & how fields eg, HTTP, SMTP
are delineated
Semantics of the Proprietary protocols:
fields: meaning of
information in fields eg, Napster, KaZaA, …
Rules for when and
how processes send &
respond to messages

Client--Server Paradigm
Client
Typical network app has two
pieces: client and server
application
Client: transport
network
data link
initiates contact with server physical modem
(“speaks first”)
typically requests service from modem
server,
Web: client implemented in
browser; e-mail: in mail reader
request
Server: reply
provides requested service to client

application
e.g., Web server sends requested Web transport
network
page, mail server delivers e-mail data link
physical

Pure P2P architecture
no always on server
arbitrary end systems modem
directly communicate
peers are intermittently modem
connected and change IP

addresses
example: Gnutella
Highly scalable
But difficult to manage

Hybrid of client-
client-server and P2P
Napster
File transfer P2P
File search centralized:
Peers register content at central server
Peers query same central server to locate content
Instant messaging
Chatting between two users is P2P
Presence detection/location centralized:
User registers its IP address with central server when it
comes online
User contacts central server to find IP addresses of
buddies
jamali@ iust.ac.ir June 23, 2010 Application Layer 2-10

Processes Communicating Across Network
Sockets: doors between process and host
process sends/receives
host or host or
messages to/from its server server
socket
controlled by
socket analogous to door app developer
sending process pushes process process
message out door socket socket
sending process assumes TCP with TCP with
transport infrastructure buffers,
Internet
buffers,
variables variables
on other side of door which
brings message to socket
at receiving process controlled
by OS
API: (1) choice of transport protocol; (2) ability to fix

a few parameters (lots more on this later)

Process Identifier
For a process to Identifier includes
receive messages, it both the IP address
must have an identifier and port numbers
Every host has a unique associated with the
32-bit IP address process on the host.
Q: does the IP address Example port numbers:
of the host on which HTTP server: 80
the process runs Mail server: 25
suffice for identifying Example IP address:
the process? 113.45.12.201
Answer: No, many Example Identifier:
processes can be (80; 113.45.12.201)
running on same host

What transport service does an app need?
Data loss Bandwidth
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
“effective”
transfer
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”

Requirements of Selected Network Applications
Application Data loss Bandwidth Time

Sensitive
file transfer no loss elastic no
e-mail no loss elastic no
web documents no loss elastic (few kbps) no
real-time loss- audio: few kbps-1Mbps yes, 100s of
audio/video tolerant video:10kbps-5Mbps msec
stored loss- same as above yes, few sec
audio/video tolerant
interactive loss- few kbps-10kbps yes, 100s of
games tolerant msec
instant no loss elastic yes and no
messaging

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 is there a UDP?
no guarantee on: timing,
minimum bandwidth

Internet apps: application, transport protocols
applications application-layer underlying transport

protocol 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
remote file server NFS [McKusik] UDP or TCP
streaming multimedia proprietary UDP or TCP
(e.g., Dialpad)
internet telephony proprietary Typically UDP
(e.g., Dialpad)

Chapter 2 Outline
2.1 Principles of app 2.6 Socket programming

layer protocols with TCP
clients and servers 2.7 Socket programming
app requirements with UDP
2.3 FTP server
2.4 Electronic Mail 2.9 Content distribution
SMTP, POP3, IMAP Network Web caching
2.5 DNS
networks
P2P file sharing

Web and HTTP
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.iust.ac.ir/computer/home.html
host name path name

HTTP Overview
HTTP: hypertext
Server
transfer protocol running
Web’s app layer protocol Apache Web
server
client/server model
PC running
client: browser that Explorer
requests, receives,
“displays” Web objects
server: Web server
sends objects in Storage
response to requests contents:
HTTP 1.0: RFC 1945 base files,
HTTP 1.1: RFC 2068 objects
Mac running
Navigator

HTTP Overview (cont.)
HTTP is “stateless”
Uses TCP: server maintains no
client initiates TCP information about
connection (creates socket) past client requests
to server, port 80
server accepts TCP
Protocols that maintain
aside
connection from client
“state” are complex!
HTTP messages (application-
past history (state) must
layer protocol messages)
be maintained
exchanged between browser
(HTTP client) and Web if server/client crashes,
server (HTTP server) their views of “state” may
be inconsistent, must be
TCP connection closed
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
HTTP/1.0 uses between client and
nonpersistent HTTP server.
HTTP/1.1 uses
persistent connections
in default mode

Non--persistent HTTP
Non
Suppose user enters URL (contains text,
www.iust.ac.ir/computer/home.html references to 10
jpeg images)
1. HTTP client initiates TCP

connection to HTTP server
(process) at www.iust.ac.ir
2. HTTP server at host
www.iust.ac.ir waiting for
on port 80
TCP connection at port 80.
“accepts” connection, notifying
client
3. HTTP client sends HTTP
request message (containing
URL) into TCP connection
4. HTTP server receives request
socket. Message indicates
message, forms response
that client wants object
message containing requested
Computer//home.html
object, and sends message
into its socket
time

Non--persistent HTTP (cont.)
Non
5. HTTP client receives response 4. …

message containing html file,
displays html. Parsing html
file, finds 10 referenced jpeg 6. HTTP server closes
objects TCP connection.
time 7. Steps 1-6 repeated for each

of 10 jpeg objects

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

Persistent HTTP
Nonpersistent HTTP issues: Persistent without pipelining:

requires 2 RTTs per object client issues new request
OS must work and allocate only when previous
host resources for each TCP response has been received
connection
one RTT for each
but browsers often open referenced object
parallel TCP connections to
fetch referenced objects Persistent with pipelining:
Persistent HTTP default in HTTP/1.1
server leaves connection client sends requests as
open after sending response soon as it encounters a
subsequent HTTP messages referenced object
between same client/server as little as one RTT for all
are sent over connection the referenced objects

HTTP Request Message: General Format
request line method SP URL SP version CR LF

header field name : value CR LF
header lines --- - --- --- ---
CR LF
Entity Body

HTTP Response Message: General Format
status line version SP status code SP phrase CR LF

header lines --- - --- --- ---
CR LF
Entity Body

HTTP Request Message
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
If-modified-since:Sat, 2 Nov 2002 13:45:12
Carriage return, (carriage return, line feed)
line feed
indicates end
of message

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
MIME lines Content-Type: text/html
data, e.g., data data data data data ...

requested
HTML file

GET and HEAD Commands
GET
The GET method means retrieve whatever information (in the form
of an entity) is identified by the Request-URI.
The semantics of the GET method changes to a "conditional GET" if

the request message includes an If-Modified-Since header field.
HEAD
The HEAD method is identical to GET except that the server must
not return any Entity-Body in the response.
There is no"conditional HEAD"request analogous to the conditional

GET.

Conditional GET: Client-
Client-Side Caching
client server
Goal: don’t send object if
client has up-to-date HTTP request msg
If-modified-since:
cached version object
<date>
client: specify date of not
cached copy in HTTP HTTP response modified
request HTTP/1.0
If-modified-since: 304 Not Modified
<date>
server: response contains HTTP request msg
no object if cached copy If-modified-since:
<date> object
is up-to-date:
modified
HTTP/1.0 304 Not HTTP response
Modified HTTP/1.0 200 OK
<data>

POST Command
POST
The POST method is used to request that the destination server
accept the entity enclosed in the request as a new subordinate of
the resource identified by the Request-URL in the Request-Line.
POST is designed to allow a uniform method to cover the following
functions:
Annotation of existing resources;
Posting a message to a bulletin board, newsgroup, mailing
list,or similar group of articles;
Providing a block of data, such as the result of submitting a
form, to a data-handling process;
Extending a database through an append operation.

Uploading Form Input
Get method:
URL encoding
Web page often
A-Z A-Z *-_ *-_
includes form input Space +
a-z a-z
Input is uploaded to 0-9 0-9 Others %HEX
server in URL field of
request line: www.somesite.com/cgi.bin/form.cgi
?firstname=morteza&lastnme=analoui
URL Encoded data
Post method:
Web page often
includes form input
Input is uploaded to
server in entity body

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
Other Methods
OPTIONS, PATCH, COPY, MOVE, DELETE, LINK, UNLINK, TRACE,
WRAPPED, extension method.

Header Fields
1. General Header Fields

2. Request Header Fields
3. Response Header Fields
4. Entity Body Hearer Fields

Header Fields
1. General Header Fields
Keep-Alive MIME-Version
Multipurpose Internet Mail Extensions
Upgrade Data
(rfcs822obs, 2045, 2046, 2077)
Connection Pragma Type Subtypes
Forwarded Application / Postscript, msword,
Msexel,…
Cache-Control Text / Html, plain(ASCII),…
Image / Jpeg, gif, ief,…
Audio / Basic, x-pn-realaudio,…
Multipart / mixed
Video / mpeg,quicktime

Header Fields
2. Request Header Fields

Accept: Range:
Accept-Language: Refer:
Authorization: Unless:
From: User-Agent:
Host: Accept-Encoding:
If-Modified-Since: Cookie:
Proxy-Authorization:

Header Fields
3. Response Header Fields

Location:
Proxy-Authentication:
Public:
Retry-After:
Server:
WWW-Authenticate:
Set-Cookie:

Header Fields (cont.)
4. Entity Body Header Fields

Allow Derived-From
Content-Encoding Expires
Content-Language Last-Modified
Content-Length Link
Content-Range Title
Content-Type Transfer-Encoding
Content-Version URL-Header
Content-MD5 extension-header

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

Status Codes Categories
Response Categories
Informational :100
Successful :200
Redirection :300
Client Error :400 (eg. 404 Not found)
Server Error :500

Status Codes
Status-Codes
"201" ; Created
"202" ; Accepted
"204" ; No Content
"301" ; Moved Permanently
"200" ; OK
"302" ; Moved Temporarily
"304" ; Not Modified
"400" ; Bad Request
"401" ; Unauthorized
"403" ; Forbidden
"404" ; Not Found
"500" ; Internal Server Error
"501" ; Not Implemented
"502" ; Bad Gateway
"503" ; Service Unavailable
“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 Interaction: Authorization
User
Authorization : control access to
server content client server
authorization credentials: usual http request msg
typically name, password
401: authorization req.
stateless: client must present WWW authenticate:
authorization in each request
authorization: header line in
each request usual http request msg
if no authorization: header,
+ Authorization: <cred>
server refuses access, usual http response msg
sends
WWW authenticate:
header line in response usual http request msg
+ Authorization: <cred> time
usual http response msg

Cookies: Keeping “State”-
“State”-RFC2109
Some Web sites store information in a small text file on

your computer. This file is called a cookie.
There are several types of cookies,
you can choose whether to allow some, none, or all of

them to be saved on your computer.
If you do not allow cookies at all, you may not be able to

view some Web sites or
take advantage of customization features (such as local
news and weather, or stock quotes).

How cookies are used
Created by an Internet site to store information on your
computer.
Example, you visit a Web site, it saves a record of the pages
you looked at, to help the site customize the view for you the
next time you visit.
Cookies can also store personally identifiable information,

that can be used to identify or contact you, such as
your name,
e-mail address, or
telephone number.
A Web site only has access to the information you provide.
Once a cookie is saved on your computer, only the Web site

that created the cookie can read it.

Persistent/Temporary Cookies
A persistent cookie is one stored as a file on your

computer, and it remains there when you close
Internet browser.
A temporary or session cookie is stored only for

your current browsing session, and is deleted from
your computer when you close Internet browser.

First--Party vs. Third-
First Third-Party cookies
A first-party cookie either originates on or is sent to the

Web site you are currently viewing.
A third-party cookie either originates on or is sent to a Web

site different from the one you are currently viewing.
Third-party Web sites usually provide some content on the

Web site you are viewing. For example, many sites use
advertising from third-party Web sites and those third-
party Web sites may use cookies.
A common use for this type of cookie is to track your Web

page use for advertising or other marketing purposes.
Third-party cookies can either be persistent or temporary.

Unsatisfactory Cookies
Unsatisfactory cookies are cookies that might

allow access to
personally identifiable information that
could be used for a secondary purpose without
your consent.

Cookies and Privacy
aside
What cookies can bring: Cookies and privacy:
authorization cookies permit sites to
shopping carts learn a lot about you
recommendations you may supply name
user session state

and e-mail to sites
(Web e-mail) search engines use
redirection & cookies
to learn yet more
advertising companies
obtain info across
sites

HTTP and Cookies
Many major Web sites use cookies
There are four components: Example:

1) cookie header line in the Ali access Internet
HTTP response message always from same PC
2) cookie header line in HTTP He visits a specific e-
request message commerce site for first
3) cookie file kept on user’s time
host and managed by user’s When initial HTTP
browser requests arrives at site,
4) back-end database at Web site creates a unique ID
site and creates an entry in
backend database for
ID

Example
client server
Cookie file usual http request msg server
usual http response + creates ID
ebay: 8734 Set-cookie: 1678 1678 for user
Cookie file
usual http request msg
amazon: 1678 cookie: 1678 cookie-
ebay: 8734 specific
usual http response msg action
one week later:
Cookie file usual http request msg

cookie-
cookie: 1678
amazon: 1678 specific
ebay: 8734 usual http response msg action
Cookie File Samples

HTTP over TCP
HTTP
Files
TCP
IP
Routers Routers packets

packets
packets
packets
packets
packets

Chapter 2 Outline
2.3 FTP server
Network Web caching
SMTP, POP3, IMAP
2.5 DNS networks
P2P file sharing

FTP: the File Transfer Protocol
FTP file transfer

user FTP FTP
user client
at host server
interface
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

File Transfer and Access Protocols
(FTP, TFTP, SFTP, NFS) RFCs1
2640 –Internationalization of the File Transfer

Protocol
2624 –NFS Version 4 Design Considerations
2623 –NFS Version 2 and Version 3 Security
Issues and the NFS Protocol’s Use of
RPCSEC_GSS and Kerberos V5
2577 –FTP Security Considerations

2428 –FTP Extensions for IPv6 and NATs

2389 –Feature negotiation mechanism for the File
Transfer Protocol
2349, 1784 - TFTP Timeout Interval and Transfer
Size Options
2348, 1783 - TFTP Blocksize Option

2347, 1782 - TFTP Option Extension

2228 –FTP Security Extensions
2224 –NFS URL Scheme
2204 –ODETTE File Transfer Protocol
2090 –TFTP Multicast Option
2055 –WebNFS Server Specification
2054 –WebNFS Client Specification

1986 –Experiments with a Simple File Transfer

Protocol for Radio Links using
Enhanced Trivial File Transfer Protocol (ETFTP)
1813 –NFS Version 3 Protocol Specification
1785 –TFTP Option Negotiation Analysis
1639, 1545 - FTP Operation Over Big Address
Records (FOOBAR)
1635 –How to Use Anonymous FTP
1579 –Firewall-Friendly FTP

1440 –SIFT/UFT: Sender-Initiated/Unsolicited

File Transfer
1415 –FTP-FTAM Gateway Specification
1350, 783 - The TFTP Protocol (Revision 2) 1282,
1258 - BSD Rlogin
1235 –Coherent File Distribution Protocol
1094 –NFS: Network File System Protocol
specification
1068 –Background File Transfer Program (BFTP)
1037 –NFILE - a file access protocol

959, 765, 542, 354, 265, 172, 114 - File Transfer

Protocol.
949 – FTP unique-named store command.
913 – Simple File Transfer Protocol.
906 – Bootstrap loading using TFTP.
775 – Directory oriented FTP commands.
743 – FTP extension: XRSQ/XRCP.
737 – FTP extension: XSEN.

697 – CWD command of FTP
691 – One more try on the FTP
686 – Leaving well enough alone
683 – FTPSRV - Tenex extension for paged files
662 – Performance improvement in ARPANET file
transfers from Multics
640 – Revised FTP reply codes
630 – FTP error code usage for more reliable mail
service

624 – Comments on the File Transfer Protocol

614 – Response to RFC 607: "Comments on the File
Transfer Protocol"
571 – Tenex FTP problem
535 – Comments on File Access Protocol
532 – UCSD-CC Server-FTP facility
520 – Memo to FTP group: Proposal for File Access
Protocol

506 – FTP command naming problem

505 – Two solutions to a file transfer access
problem
501 – Un-muddling "free file transfer" 487 – Free
file transfer
486 – Data transfer revisited
480 – Host-dependent FTP parameters
479 – Use of FTP by the NIC Journal
478 – FTP server-server interaction - II

468 – FTP data compression

463 – FTP comments and response to RFC 430
448 – Print files in FTP
438 – FTP server-server interaction
430 – Comments on File Transfer Protocol
418 – Server file transfer under TSS/360 at
NASA Ames
414 – File Transfer Protocol (FTP) status and
further comments

412 – User FTP Documentation

310 – Another Look at Data and File Transfer
Protocols
294 – The Use of "Set Data Type" Transaction in
File Transfer Protocol
281 – Suggested addition to File Transfer Protocol
269 – Some Experience with File Transfer
264, 171 - The Data Transfer Protocol

250 – Some thoughts on file transfer

242 – Data Descriptive Language for Shared Data
238 – Comments on DTP and FTP proposals
163 – Data transfer protocols
141 – Comments on RFC 114: A File Transfer
Protocol
133 – File Transfer and Recovery

FTP: Separate Control, Data Connections1
TCP control connection

port 21 (persistent)
FTP client TCP data connection

port 20(nonpersistent) FTP server
FTP client contacts FTP server at port 21, specifying

TCP as transport protocol.
Client obtains authorization over control connection.
Client browses remote directory by sending
commands over control connection.
When server receives a command for a file transfer,
server opens a TCP data conn. to client at port 20.

FTP MODEL1
PI: Protocol Interpreter
USER
DTP: Data Transfer Process
INTERFACE
USER
SERVER FTP COMMANDS USER

PI FTP REPLIES PI
SERVER DATA USER

DTP CONNECTION DTP
FILE FILE
SYSTEM SYSTEM

Control Connection Initiation
In the model, the user-protocol interpreter (PI)
initiates the control connection.
The control connection follows the Telnet
protocol.
FTP commands are generated by the user-PI and

transmitted to the server process via the control
connection.
Standard replies are sent from the server-PI to

the user-PI over the control connection in
response to the commands.

Data Connection Initiation
The FTP commands specify the parameters for
the data connection
(data port, transfer mode, representation type, and
structure) and
the nature of file system operation (store, retrieve,
append, delete, etc.).
The user-DTP should "listen" on the specified data
port, and the server initiate the data connection
and data transfer in accordance with the specified
parameters.
Note that the data connection may be used for
simultaneous sending and receiving.

Relationship between FTP and Telnet
The FTP uses the Telnet protocol on the

control connection.
This can be achieved in two ways:
First, the user-PI or the server-PI may
implement the rules of the Telnet Protocol
directly in their own procedures; or,
Second, the user-PI or the server-PI may make
use of the existing Telnet module in the
system.

FTP: Separate Control, Data Connections
After transferring a file, server closes port

20.
Server opens a second TCP data connection to
transfer the next file.
Control connection: “out of band”
(http is also a file transfer protocol. It is
stateless, in-band and a push/pull protocol.
FTP is also a push/pull one)
FTP server maintains “state”: current

directory, earlier authentication

FTP Commands, Responses
Sample commands: Sample return codes
sent as ASCII text over status code and phrase (as
control channel in HTTP)
(4 uppercase ASCII
331 Username OK,
characters)
password required
USER username
125 data connection
PASS password
already open;
LIST return list of file in transfer starting
current directory
425 Can’t open data
RETR filename retrieves connection
(gets) file
452 Error writing
STOR filename stores file
(puts) file onto remote
host
ftp://ftpserver.iust.ac.ir/dir1/filename.extension

Chapter 2 Outline
2.3 FTP server
Network Web caching
SMTP, POP3, IMAP,
HTTP
networks
2.5 DNS P2P file sharing

Electronic Mail
outgoing
Three major components: message queue
user agents user mailbox
user
mail servers agent
simple mail transfer mail
user
protocol: SMTP server
agent
User Agent mail

Sometimes is called: server user
SMTP
“mail reader” agent
composing, editing, reading

mail messages user
mail
e.g., Eudora, Outlook, elm, agent
server
Netscape Messenger
outgoing, incoming messages user
stored on server agent
user
agent

Electronic Mail: Mail Servers
Mail Servers user
mailbox contains incoming agent
messages for user mail
user
server
message queue of outgoing agent
(to be sent) mail messages
mail
SMTP protocol between mail server user
SMTP
servers to send email agent
messages
“client”: sending mail
mail user
server (sending agent) agent
server
“server”: receiving mail
server (receiving agent) user
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: User1 sends message to User2
1) User1 (sender) uses UA to 4) SMTP client sends User1’s
UA: User Agent
compose message to message over the TCP

user2@yahoo.com . connection.
2) User1’s UA sends message 5) User2’s mail server places
to his mail server; message the message in User2’s
placed in message queue. mailbox.
3) Client side of SMTP opens 6) User2 invokes his/her user
TCP connection with agent to read message.
User2’s mail server.
webmail.iust.ac.ir
1 mail
mail server user User2
user
User1 server agent
agent 2 6
3 4 5 user2@yahoo.com
yahoo.com
user1@webmail.iust.ac.ir

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 SMTP: push
message (header &
both have ASCII
body) to be in 7-bit command/response
ASCII interaction, status codes.
SMTP server uses HTTP: each object
CRLF.CRLF to encapsulated in its own
determine end of response message.
message SMTP: multiple objects
sent in multipart message.

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

SMTP Message Transfer Between Mail Servers
sms = sending mail server
rms = receiving mail server
sms rms: TCP connection establishment on port 25

sms rms: SMTP handshake (HELO, MAIL, FROM, RCPT TO, DATA,
commands, and 220, 250, 354, 221 status codes)
sms header
<CRLF> Mail
body Massage
<CRLF>.<CRLF>
sms QUIT
rms 221 yahoo.com closing connection

Example
webmail.iust.ac.ir User2
mail
User1 mail user
server
server agent
1 6
3 4 5
user 2 user2@yahoo.com
agent
yahoo.com
user1@webmail.iust.ac.ir

Example: SMTP Interaction
sms: TCP connection request on port 25
rms: 220 yahoo.com accepts connection
sms: HELO webmail.iust.ac.ir is ready
rms: 250 Hello webmail.iust.ac.ir
sms: MAIL FROM: <user1@webmail.iust.ac.ir>
rms: 250 user1@webmail.iust.ac.ir... Sender ok
sms: RCPT TO: <user2@yahoo.com>
rms: 250 user2@yahoo.com ... Recipient ok
sms: DATA
rms: 354 Enter mail, end with "." on a line by itself
sms: From: user1@webmail.iust.ac.ir
Mail
sms: To: user2@yahoo.com Massage
.
from
sms: . user1 to
rms: 250 Message accepted for delivery user2
sms: QUIT
rms: 221 yahoo.com closing connection
Message Format: Multimedia Extensions
MIME: multimedia mail extension, RFC 2045, 2056
additional lines in message header declare MIME content
type
From: User1@webmail.iust.ac.ir
To: User2@yahoo.com
MIME version
Subject: Picture of iust
cc: User3@tu.ac.ir
method used MIME-Version: 1.0
to encode data Content-Transfer-Encoding: base64
Content-Type: image/jpeg
multimedia data
type, subtype, base64 encoded data .....
.........................
parameter declaration
......base64 encoded data
encoded data .

MIME (RFCs2045
(RFCs2045,, 2046
2046,, 2077
2077)) Types
Content-
Content-Type: type/subtype; parameters
Text Video
example subtypes: plain, example subtypes: mpeg,
html quicktime
Image
example subtypes: jpeg, Application
gif other data that must be
processed by reader
Audio before “viewable”
example subtypes: basic example subtypes:
(8-bit mu-law encoded), msword, octet-stream
32kadpcm (32 kbps
coding)

Multipart Type
From: user1@webmail.iust.ac.ir
To: user2@yahoo.com
Subject: photo of iust.
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary=StartOfNextPart
--StartOfNextPart
Dear User1, Hear is a photo of iust in 1383 winter.
--StartOfNextPart
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
--StartOfNextPart
Do you like to receive more pictures?
.

Mail Access Protocols
SMTP SMTP access user
Sender user protocol agent
Receiver
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, IUST, etc.

POP3--Post Office Protocol - Version 3
POP3
RFC 1939 / Std 53

To retrieve emails from server (POP3 server)
Server port number: 110
Three states
Authorization State
Transaction State
Update State

POP3 Commands
Authorization State Update State

USER username
QUIT
PASS password
APOP name digest
Transaction State
STAT
LIST [msgNo]
RETR msgNo
DELE msgNo
NOOP
RSET
TOP msgNo line
UIDL [msgNo]

POP3 Protocol
S: +OK POP3 server ready
C: user USER1
authorization phase S: +OK
C: pass zxcdvf
client commands: S: +OK user successfully logged on
user: declare username
pass: password
C: list
S: 1 498
server responses S: 2 912
+OK S: .
-ERR C: retr 1
S: <message 1 contents>
transaction phase, client: S: .
list: list message numbers C: dele 1
retr: retrieve message by C: retr 2
number S: <message 1 contents>
dele: delete S: .
quit C: dele 2
C: quit
S: +OK POP3 server signing off

POP3 (more) and IMAP
More about POP3 IMAP
Previous example uses
“download and delete” mode. Keep all messages in
“Download” brings the mail one place: the server
into client computer.
“Delete” removes the mail Allows user to
from the mail server. User1 organize messages in
cannot re-read e-mail if
he/she changes client folders
computer. IMAP keeps user state
across sessions:
“Download-and-keep”: leaves
the message on the mail names of folders and
server. mappings between
POP3 is stateless across message IDs and folder
sessions. name

Chapter 2 Outline

2.3 FTP server
SMTP, POP3, IMAP, Network Web caching
HTTP Content distribution
2.5 DNS networks
P2P file sharing

DNS RFCs1
2673 –Binary Labels in the Domain Name System.
2672 –Non-Terminal DNS Name Redirection.
2671 –Extension Mechanisms for DNS (EDNS0).
2606 –Reserved Top Level DNS Names.
2541 –DNS Security Operational Considerations.
2540 –Detached Domain Name System (DNS)
Information.
2539 –Storage of Diffie-Hellman Keys in the
Domain Name System (DNS).

DNS RFCs2
2535 –Domain Name System Security Extensions.
2517 –Building Directories from DNS: Experiences from
WWWSeeker.
2352, 2240 - A Convention For Using Legal Names as Domain
Names.
2317 –Classless IN-ADDR.ARPA delegation.
2308 –Negative Caching of DNS Queries (DNS. NCACHE)
2230 –Key Exchange Delegation Record for the DNS.
2219 –Use of DNS Aliases for Network Services.
2182 –Selection and Operation of Secondary DNS Servers.

DNS RFCs3
2181 –Clarifications to the DNS Specification.
2137 –Secure Domain Name System Dynamic Update.
2136 –Dynamic Updates in the Domain Name System (DNS
UPDATE).
2065 –Domain Name System Security Extensions.
2052 –A DNS RR for specifying the location of services
(DNS SRV).
2010 –Operational Criteria for Root Name Servers.
1996 –A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY).
1995 –Incremental Zone Transfer in DNS.

DNS RFCs4
1982 –Serial Number Arithmetic.

1912, 1537 - Common DNS Operational and
Configuration Errors.
1876 –A Means for Expressing Location
Information in the Domain Name System.
1794 –DNS Support for Load Balancing.
1713 –Tools for DNS debugging.
1712 –DNS Encoding of Geographical Location.
1706, 1637, 1348 - DNS NSAP Resource Records.
1591 –Domain Name System Structure and
Delegation.

DNS RFCs5
1536 –Common DNS Implementation Errors and
Suggested Fixes.
1535 –A Security Problem and Proposed Correction
With Widely Deployed DNS Software
1480, 1386 - The US Domain.
1464 –Using the Domain Name System To Store
Arbitrary String Attributes.
1394 –Relationship of Telex Answerback Codes to
Internet Domains.
1183 –New DNS RR Definitions.
1101 –DNS encoding of network names and other
types.
1035 –Domain names - implementation and
specification.
DNS RFCs6
1034 –Domain names - concepts and facilities

1033 –Domain administrators operations guide
1032 –Domain administrators guide
1031 –MILNET name domain transition
973 – Domain system changes and observations
953, 811 - Hostname Server
921, 897 - Domain name system implementation
schedule - revised
920 – Domain requirements

DNS RFCs7
883 – Domain names: Implementation specification
882 – Domain names: Concepts and facilities
881 – Domain names plan and schedule
830 – Distributed system for Internet name
service
819 – Domain naming convention for Internet user
applications
799 – Internet name domains
756 – NIC name server - a datagram-based
information utility
752 – Universal host table

DNS: Domain Name SystemRFC1034
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) -
used for addressing
application-layer protocol
host, routers, name servers to
datagrams
communicate to resolve names
“name”, e.g., (address/name translation)
www.iust.ac.ir - used by
note: core Internet
humans
function, implemented as
Q: map between IP application-layer protocol
addresses and name ? complexity at network’s
“edge”

Why DNS
Although DNS is most commonly associated with
the Internet, private networks also use DNS
because of the following benefits:
Convenience: User-friendly names are easier for people

to remember than numerical IP addresses.
Consistency: IP addresses may change, but the server
names can remain constant.
Simplicity: Users need to learn only one naming
convention to find resources on either the Internet or on
an intranet.

DNS: Domain Name System
The Domain Name System is a distributed

database system that can serve as the foundation
for name resolution in a TCP/IP network.
DNS is used by most internetworking software,

such as web browsers and electronic mail
programs, to locate servers and to resolve, or map,
a user-friendly name of a computer to its IP
address.

DNS Components
To understand how DNS maps names to IP
addresses, you will need to understand the
following five components:
1. Domain Name Space
Name Structure,
2. Zone
Zone data base file,
3. Name Server (DNS Server)
DNS Root Servers,
4. DNS Resolver,
5. Protocol
Forward Lookup Query
Caching.

The domain name space has a hierarchical
structure.
The root domain is at the top, and it is
represented by a period.
Below the root domain, the top-level, or 1st-level
domains can be an organizational type, such as com
or edu., or a geographic location, such as ir. for
IRAN.
Second-level domains are registered to individuals
or organizations, such as microsoft.com, the
Microsoft Corporation domain.
Second-level domains can have many sub domains.
…and any domain can have hosts.

Root Domain
“ .”
Top Level or First Level Domain
name, or FQDN
org. edu. com. ir.
Second Level Domain (Registered to Individuals or Organizations)

fully qualified domain name
ac.ir.
root iust.ac.ir.
webmail . iust . ac . ir .
host
2nd-level top-level ce.iust.ac.ir.
subdomain
domain domain
Any domain can have hosts.

A host is a specific computer within a domain.
Iran University of Science & Technology ‘s Domain: iust.ac.ir.

1. Domain Name Space: Name Structure
Max: 63 Characters Root
Host name . … . Subdomain-name . 2nd-level –name. 1st-level-name .
Max: 255 Characters
ICANN: Internet Corporation For Assigned Names

and Numbers) http://icann.org
Levelm -name authority appoints levelm-1 -names.

Example:
ir. is controlled by (
)
iust.ir. is appointed by (
) and controlled by Iran
University of science and Technology.
Names are Valuable
new

1. Domain Name Space: Top Levels
com: commercial ir: Iran
edu: educational institute nl: Netherlands
ac: Academic, research institute jp: Japan
int: international organization
uk: England
gov: US federal goverment
…
org: US armed forces
net: network providers For the most up-
up-to-
to-date
biz: business information about new top level
domains, consult:
name: people’s name http://www.icann.org/tlds
pro: professions
tv: TV stations and networks
…

2. Zones
Name
Server
ir.
For administrative purposes, Zone Database File
domains can be organized Name

Server ac.ir.
into zones.
Zone
As you can see in this example, Database File
a zone is a discrete and Zone

Database File
contiguous area of the Name
Server
domain name space.
One reason to divide a name space into zones is to
delegate authority for different portions of it.
One very large domain could be difficult to administer.
The name-to-IP address data for computers located in a
zone, is stored in a zone database file on a DNS name
server.

2. Zone Database File
A zone database storing resource records (RR) of the zone
for which a server is authoritative.
RR format: (Name, TTL, Class, Type, Value)
Type=A Type=CNAME
name is hostname name is alias name for some
value is IP address “canonical” (the real) name
Type=NS www.ibm.com is really
name is domain (e.g. iust.ac.ir) servereast.backup2.ibm.com
value is IP address of authoritative
name server for this domain value is canonical name
Type=MX
value is name of mail-server
associated with name

2. Zone Database File: Type Description
Number Type Description Example Resource
Record Format
1 A Network address www 1D IN A 10.1.1.1
2 NS Authoritative name @ 1D IN NS na.av.com
server
3 MD Mail destination; now replaced by MX
4 MF Mail forwarder; now replaced by MX
5 CNAME Canonical alias name
6 SOA Start of zone authority

7 MB Mailbox domain name
8 MG Mailbox member
9 MR Mail rename domain
10 NULL Null resource record
11 WKS Well-Known service

2. Zone Database File: Type Description
Number Type Description Example Record Format
12 PTR Pointer to a domain name
13 HINFO Host information www 1D IN HINFO Solaris
14 MINFO Mailbox information
15 MX Mail exchange
16 TXT Text strings System 1 IN TXT “This is a
new system”
17 RP Responsible person
18 AFSDB AFS-type services
19 X.25 X.25 address
20 ISDN ISDN address
21 RT Route through

2. Zone Database File: Example
Host Information
Name TTL Class Type Value

mail.iust.ac.ir 1D IN HINFO Sun Unix
mail.iust.ac.ir 1D IN A 130.37.16.112 Primary
mail server
mail.iust.ac.ir 1D IN A 192.31.231.165
mail.iust.ac.ir 1D IN MX 1 mail.iust.ac.ir
Secondary
mail.iust.ac.ir 1D IN MX 2 ms.iust.ac.ir mail server
post.iust.ac.ir. 1D IN CNAME mail.iust.ac.ir
ftp.iust.ac.ir. 1D IN CNAME file.iust.ac.ir
Canonical Names Real names

3. DNS Name Servers
Why not centralize DNS?

single point of failure A DNS server is a
traffic volume computer that runs a
DNS server program,
distant centralized
such as Berkeley
database Internet NAME Domain
maintenance (BIND).
doesn’t scale! DNS Servers contain
DNS database files.
no server has all name- They resolve name
to-IP address mappings. resolution queries issued
does scale! by DNS clients.

Distributed, Hierarchical Database
Root DNS Servers
org DNS Servers edu DNS Servers com DNS Servers ir DNS Servers
ac.ir DNS
Servers
iust.ac.ir
DNS Servers

3. DNS Name Servers
Name
Server
Primary Zone ir.
One name server holds the Name Database File
Server
primary zone database file
Secondary Zone
for a zone. Database File ac.ir.
That name server is said to
"have authority" for making
changes to the zone file.
A copy of the zone file may
be stored on other servers to balance network load.
These copies are referred to as secondary zone database
files.
The secondary zone database files are updated regularly
from the primary zone database file by a process called zone
transfer.

Zone Owner’s Responsibilities
Authoritatively maintain the zone’s data.

Arrange for replicated name servers for the zone
Typically, zone data is maintained in a primary file and
loaded into a primary server
Replicated servers use TCP-based zone transfers
specified in DNS protocol to refresh their data.
Therefore, either servers can answer name resolution
queries for that zone.
A name server authoritative for a zone does not
have to be in that zone.
A name server can handle any number of zones,
which don’t have to be contiguous.

3. DNS Root Name Servers
contacted by local name server that can not resolve name
root name server:
Either, contacts authoritative name server
gets mapping
returns mapping to local name server
Or, introduces authoritative name server to local name server.
(a) NSI Herndon, VA (i) NORDUnet Stockholm, Sweden
(c) PSInet Herndon, VA
(d) U Maryland College Park, MD (k) RIPE London, UK
(g) DISA Vienna, VA
(h) ARL Aberdeen, MD
(j) NSI (TBD) Herndon, VA (m) WIDE Tokyo, Japan
(e) NASA Mt View, CA

(f) Internet Software C. Palo Alto, CA
(b) USC-ISI Marina del Rey, CA

(l) ICANN Marina del Rey, CA
13 root name servers
worldwide

13 Root Name Servers
F gets 270,000,000+ hits per day.

Other root servers are comparable.
Top Level Domain servers answer 5,000,000,000 per day.

Root Servers
Home
Server Operator Locations IP Addr ASN
VeriSign Global Registry
A Services
Dulles VA 198.41.0.4 19836
IPv4: 192.228.79.201
Information Sciences
B Institute
Marina Del Rey CA IPv6: tba
2001:478:65::53
Herndon VA; Los Angeles;
C Cogent Communications
New York City; Chicago
192.33.4.12 2149
D University of Maryland College Park MD 128.8.10.90 27
E NASA Ames Research Center Mountain View CA 192.203.230.10 297
Ottawa; Palo Alto; San Jose CA;

New York City; San Francisco;
Madrid; Hong Kong; Los Angeles;
Rome; Auckland; Sao Paulo; IPv4: 192.5.5.241
Internet Systems Consortium,
F Inc.
Beijing; Seoul; Moscow; Taipei; IPv6: 3557
Dubai; Paris; Singapore; Brisbane; 2001:500::1035
Toronto; Monterrey; Lisbon;
Johannesburg;Tel Aviv;Jakarta;
Munich;
U.S. DOD Network

G Information Center
Vienna VA 192.112.36.4 568

Root Servers
Home
Server Operator Locations IP Addr
ASN
IPv4: 128.63.2.53
H U.S. Army Research Lab Aberdeen MD
IPv6:2001:500:1::803f:235
13
Stockholm; Helsinki; Milan;

London; Geneva; Amsterdam;
Oslo; Bangkok; Hong Kong;
I Autonomica/NORDUnet Brussels; Frankfurt; 192.36.148.17 29216
Bucharest; Ankara;
Chicago; Washington DC;
Tokyo; Kuala Lumpur
Dulles VA (2 locations); Mountain
View CA;
Seattle WA; Amsterdam;
VeriSign Global Registry Atlanta GA; Los Angeles CA;
J Services Miami; Stockholm; London;
192.58.128.30 26415
Tokyo; Seoul; Singapore;
Sterling VA (2 locations,
standby)
Reseaux IP Europeens - London (UK); Amsterdam (NL);
IPv4: 193.0.14.129
K Network Coordination Frankfurt (DE); Athens (GR);
IPv6: 2001:7fd::1
25152
Centre Doha (QA); Milan (IT)
Internet Corporation for
L Assigned Names and Los Angeles 198.32.64.12 20144
Numbers
202.12.27.33
M WIDE Project Tokyo; Seoul (KR); Paris (FR)
IPv6: 2001:dc3::35
7500

Autonomous System
On the Internet, an Autonomous System (AS) is

the unit of router policy,
Either a single network
Or a group of network
that is controlled by a common network
administrator (or group of administrators) on
behalf of a single administrative entity (such as
a university, a business enterprise, or a
business division).
An autonomous system is also sometimes referred
to as a routing domain.
An autonomous system is assigned a globally unique
number, sometimes called an Autonomous System
Number (ASN).

4. Resolver
A DNS resolver is a service that uses the DNS

protocol to query for information from DNS
servers.
Function of DNS resolver is performed by the

DNS client service.
DNS service uses UDP in transport layer.

5. DNS Protocol: Forward Lookup Query
a:answer root name server
r:referral q
Root name server: 2 6
may not know q:query 7 3q a
a
authoritative name
server
may know q
q a a
intermediate name intermediate name server
local name server
server: who to dns.iust.ac.ir (Top level) dns.org
contact to find 4 5
1 8
authoritative name
server
authoritative name server
dns.icann.org
requesting host
www.icann.org

a:answer
root name server
recursive query: r:referral q
iterated query
puts burden of name 2
q:query
resolution on r3
contacted name q 4
server a 7
heavy load?
q a q a
intermediate name server
iterated query: local name server (Top Level) dns.org
dns.iust.ac.ir
contacted server 5 6
1 8
replies with name of
server to contact
“I don’t know this dns.icann.org
name, but ask this requesting host
server”
www.icann.org

a:answer
root name server
r:referral q
iterated query
q:query 2 3
r
q 4
r 5
a
q a q 7 intermediate name server
(Top Level) dns.org
local name server
dns.iust.ac.ir
6
1 8

dns.icann.org
requesting host
www.icann.org

IP Address of www.icann.org is
142.12.01.23 Root
Authorized name Name Server
server for org. zone
“ .”
org. edu. com. ir.
ac.ir.
iust.ac.ir.
Local
Name Server
www.icann.org.
Client
The query contains the FQDN of the requested computer.
A forward lookup query is a request
Forward Lookup Query:
What is IP Address of www.icann.org
to map a name to an IP address.

DNS Resolver and Local DNS Server
Root server
3
4
Application DNS cache
5
Top-level
DNS query
1 10 Local DNS 6 domain server
2
server
DNS resolver 7
DNS response 9
8
Second-level
domain server
Caching based on a time-to-live (TTL) assigned by the DNS server

responsible for the host name to reduce latency in DNS translation.

5. DNS Protocol: Caching and Updating Records
once (any) name server learns mapping, it caches mapping

cache entries timeout (disappear) after some time
Top Level Domain 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

5. DNS Protocol Messages
DNS protocol : query and reply messages, both with same

message format
identification flags
12bytes
number of questions number of answer RRs
msg header
number of authority RRs number of additional RRs
identification: 16 bit #
questions
for query, reply to query
(variable number of questions)
uses same #
answers
flags: (variable number of resource records)
query or reply authority
recursion desired (variable number of resource records)
recursion available additional information

(variable number of resource records)
reply is authoritative

5. DNS Protocol Messages
identification flags
12bytes
Name, Type fields number of questions number of answer RRs
for a query number of authority RRs number of additional RRs
questions
RRs in response (variable number of questions)
to query answers
(variable number of resource records)
records for authority
authoritative servers (variable number of resource records)
additional information
additional “helpful” (variable number of resource records)
info that may be used

Inserting records into DNS
Example: just created startup “Network Utopia”

Register name networkuptopia.com at a registrar
(e.g., Network Solutions)
Need to provide registrar with names and IP addresses of your
authoritative name server (primary and secondary)
Registrar inserts two RRs into the com TLD server:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
Put in authoritative server Type A record for
www.networkuptopia.com and Type MX record for
networkutopia.com
How do people get the IP address of your Web site?

Example: Set Debug Command
> set debug
> www.goole.com
Server: jupitr.iust.ac.ir AUTHORITY RECORDS:
Address: 194.225.228.4 -> 1.google.com
------------------------------- nameserver = b.1.google.com
Got answer: ttl = 37098 <10 hours 18 mins 18 secs>
HEADER: -> 1.google.com
opcode = QUERY, id = 11, rcode = nameserver = c.1.google.com
NOERROR ttl = 37098 <10 hours 18 mins 18 secs>
header flags: response, want recursion, -> 1.google.com
recursion avail.
nameserver = d.1.google.com
questions = 1, answers = 4, authority
records = 6, additional = 0 ttl = 37098 <10 hours 18 mins 18 secs>
QUESTIONS: -> 1.google.com
www.google.com, type = A, class = IN nameserver = e.1.google.com
ANSEWRS: ttl = 37098 <10 hours 18 mins 18 secs>
-> www.google.com -> 1.google.com
cannonical name = www.1.google.com nameserver = g.1.google.com
ttl = 900 <15 mins> ttl = 37098 <10 hours 18 mins 18 secs>
-> www.1.google.com -> 1.google.com
internet address = 66.102.9.147 nameserver = a.1.google.com
ttl = 176 <2 mins 56 secs> ttl = 37098 <10 hours 18 mins 18 secs>
-> www.1.google.com --------------------
internet address = 66.102.9.99 Non-authoritative answer:
ttl = 176 <2 mins 56 secs> Name: www.1.google.com
-> www.1.google.com Addresses: 66.102.9.147, 66.102.9.99, 66.102.9.104
internet address = 66.102.9.104 Aliases: www.google.com
ttl = 176 <2 mins 56 secs>

Chapter 2 Outline
2.1 Principles of app 2.6 Socket

layer protocols programming with
clients and servers

TCP
app requirements
2.7 Socket programming
2.2 Web and HTTP with UDP
2.3 FTP 2.8 Building a Web
2.4 Electronic Mail server
SMTP, POP3, IMAP
2.9 Content distribution
2.5 DNS Network Web caching
networks
P2P file sharing

Using Ports to Identify Services
Server host 128.2.194.242
Client host
Service request for
128.2.194.242:80 Web server
(port 80)
(i.e., the Web server)
Client OS
Echo server
(port 7)
Client host Service request for

128.2.194.242:7 Web server
(port 80)
(i.e., the echo server)
Client OS
Echo server
(port 7)

Network Application-
Application-Communication
Network Applications communicates through a network.
API is a programming means, either a library or part of
OS.
API provides the communication functionality for the
Network Applications (Processes).
Application Software
(Network Application)
Application Program Interface (API) API comes as a library
OS Communication Software & Hardware

Platform (OS + Hardware) OS

API Technologies-
Technologies-Sockets
Sockets (earliest technology)

Low level functions for the communication
Socket,
ServerSocket,
ConnectionSocket,
ClientSocket,
DatagramSocket,
Send,
Read,
Write,
Close,
Accept

API Technologies-
Technologies-RPC
Remote Procedure Call (RPC)
Client code invokes a procedure on a remote server.
RPCs support a wire format common to all platforms.
Client and server translate from their binary
format into the wire format.
Each RPC involves four translation:
Client to wire format,
Wire to server format,
Server back to wire (for the return value),
Wire format back to client format.

API Technologies-
Technologies-Components
Components: Components Look and act like

objects,
CORBA (common object request Broker
Architecture)
COM,
COM+ ,
DCOM (Distributed Component Object Model)

Socket Programming
Goal: learn how to build client/server application that

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

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 application
process process
application developer
developer socket socket
TCP with TCP with controlled by
controlled by
buffers, operating
operating buffers, Network system
system variables variables
client or server client or server

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
Client contacts server by: source port numbers
creating client-local TCP used to distinguish
socket clients (more in Chap 3)
specifying IP address, port
number of server process application viewpoint
When client creates
socket: client TCP TCP provides reliable, in-order
establishes connection to transfer of bytes (“pipe”)
server TCP between client and server

Sockets
Client process Server process

Server IP Address
&
Port Number1
Welcoming
socket
send read read write
Client Connection
socket
bytes socket
Server IP Address
&
Client IP Address Port Number2
&
Port Number

Example: Socket Programming with TCP
1) Example client-server app. in Java:

2) Client
1) reads line from standard input (keyboard) (inFromUser stream)
2) sends to server via socket (outToServer stream)
3) Server
1) reads line from socket
2) converts line to uppercase,
3) sends back to client
4) Client
1) reads (inFromServer stream),
2) prints modified line from socket on its standard output
(monitor)

Example: 3 streams and 1 socket
outTOServer inFormUser
Input
Stream
Client
inFormServer
Process
Input
Output Stream
Stream
From transport layer

ClientSocket To transport layer
TCP socket
Streams
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.

Client/Server Socket Interaction: TCP
Server (running on hostid) Client
create socket,
port=x, for
incoming request:
welcomeSocket =
ServerSocket()
TCP create socket,

wait for incoming
connection request connection setup connect to hostid, port=x
connectionSocket = clientSocket =
welcomeSocket.accept() Socket()
send request using

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

Example: TCPClient.java
import import java.io.*;

Statements import java.net.*;
make Java class TCPClient { networking class
classes available
public static void main(String argv[ ]) throws Exception

{
String sentence;
String modifiedSentence;
Creates
BufferedReader inFromUser =
input stream
new BufferedReader(new InputStreamReader(System.in));
Creates server port no.
client socket,
TCP connection Socket clientSocket = new Socket("hostname", 6789);
to server server name
class: is a collection of data and methods that operate on that data

Example: TCPClient.java (cont.)
Creates
output stream DataOutputStream outToServer =
attached to socket new DataOutputStream(clientSocket.getOutputStream());
Creates
input stream BufferedReader inFromServer =
attached to socket new BufferedReader(new
InputStreamReader(clientSocket.getInputStream()));
Sends line
sentence = inFromUser.readLine();
to server
Reads line outToServer.writeBytes(sentence + '\n');

from server
modifiedSentence = inFromServer.readLine();
System.out.println("FROM SERVER: " + modifiedSentence);
clientSocket.close();
}
}
Code Descriptions-
Descriptions-TCPClient.java
import java.io.*;
java.io and java.net are java packages.
The java.io package contains classes for
input (BufferedReader)
output (DataOutputStream)
streams.
import java.net.*;
The java.net package provides classes for network support.
It contains the
Socket (clientSocket object is derived from the Socket class) and
ServerSocket classes.

Code Descriptions-
class TCPClient {
{......}
}
First is beginning of a class definition block.
Class definition for the class named TCPClient.
A class contains variables and methods. The class TCPClient
has no class variables and exactly one method, the main()
method.
Java interpreter executes an application, starts by calling
the class's main method. The main method then calls all the
other methods required to run the application.

Code Descriptions-
String sentence;
String modifiedSentence;
These lines declare objects of type String.
Object sentence is string typed by user and sent to server.
Object modifiedSentence is the string obtained from the server and sent
to the user's standard output.
BufferedReader inFromUser = new BufferedReader (new

InputStreamReader(System.in));
The line creates the stream object inFromUser of type BufferedReader.
Input stream is initialized with System.in, which attaches the stream to
standard input.
The command allows the client to read text from its keyboard.

Code Descriptions-
Socket clientSocket = new Socket("hostname", 6789);
The line
creates object clientSocket of type Socket.
performs a DNS look-up on the hostname to obtain the host's IP
address.
initiates the TCP connection between client and server.
String "hostname" replaced with host name of server (for example,

"fling.seas.upenn.edu").
The number 6789 is the port number. You can use a different port
number; but you must make sure that you use the same port number
at the server side of the application.

Code Descriptions-
DataOutputStream outToServer =new

DataOutputStream(clientSocket.getOutputStream());
BufferedReader inFromServer =new BufferedReader(new
inputStreamReader(clientSocket.getInputStream()));
The above two lines create stream objects that are

attached to the socket.
outToServer stream provides the process output to the socket.
inFromServer stream provides the process input from the
socket.

Code Descriptions-
sentence = inFromUser.readLine();
The above line places a line typed by the user into the string
sentence.
The string sentence continues to gather characters until the
user ends the line by typing a carriage return.
The line passes from standard input through the stream
inFromUser into the string sentence.

Code Descriptions-
outToServer.writeBytes(sentence + '\n');
Line sends the string sentence augmented with a carriage return
into the outToServer stream.
The augmented sentence flows through the client's socket and into
the TCP pipe.
The client then waits to receive characters from the server.
modifiedSentence = inFromServer.readLine();
When characters arrive from the server, they flow through the
stream inFromServer and get placed into the string
modifiedSentence.
Characters continue to accumulate in modifiedSentence until the
line ends with a carriage return character.

Code Descriptions-
System.out.println("FROM SERVER " + modifiedSentence);

The above line prints to the monitor the string
modifiedSentence returned by the server.
This last line
closes the socket and,
hence, closes the TCP connection between the client and the
server.
It causes TCP in the client to send a TCP message to TCP in the
server.

Example: TCPServer.java
import java.io.*;
import java.net.*;
class TCPServer {
public static void main(String argv[]) throws Exception

{
String clientSentence;
Create String capitalizedSentence;
welcoming socket
ServerSocket welcomeSocket = new ServerSocket(6789);
at port 6789
Wait, on welcoming while(true) {

socket for contact
Socket connectionSocket = welcomeSocket.accept();
by client
BufferedReader inFromClient =
Create input new BufferedReader(new
stream, attached InputStreamReader(connectionSocket.getInputStream()));
to socket

Example: TCPServer.java (cont.)
Create output
stream, attached DataOutputStream outToClient =
to socket new DataOutputStream(connectionSocket.getOutputStream());
Read in line
from socket clientSentence = inFromClient.readLine();
capitalizedSentence = clientSentence.toUpperCase() + '\n';

Write out line
outToClient.writeBytes(capitalizedSentence);
to socket
}
}
} End of while loop,
loop back and wait for
another client connection

Code Descriptions-
Descriptions-TCPServer.java
TCPServer has many similarities with TCPClient.

The first line in TCPServer that is substantially different from
what we saw in TCPClient is:
ServerSocket welcomeSocket = new ServerSocket(6789);
Line creates the object welcomeSocket, which is of type

ServerSocket.
The WelcomeSocket is a sort of door that waits for a knock from
some client.
The port number 6789 identifies the process at the server.

Code Descriptions-
Socket connectionSocket = welcomeSocket.accept();
It creates a new socket, called connectionSocket, when some client

knocks on welcomeSocket.
TCP then establishes a direct virtual pipe between clientSocket at
the client and connectionSocket at the server.
The client and server can then send bytes to each other over the
pipe, and all bytes sent arrive at the other side in order.
With connectionSocket established, the server can continue to
listen for other requests from other clients for the application
using welcomeSocket.
This version of the program doesn't actually listen for more
connection requests, but it can be modified with threads to do so.

Code Descriptions-
The program then creates several stream objects, analogous

to the stream objects created in clientSocket. Now
consider:
capitalizedSentence = clientSentence.toUpperCase() + '\n';

This command is the heart of the application.
It takes the line sent by the client,
capitalizes it, and
adds a carriage return.
It uses the method toUpperCase().
All the other commands in the program are peripheral; they
are used for communication with the client.

Code Descriptions-
To test the program pair, you install and compile

TCPClient.java in one host and TCPServer.java in another
host. Be sure to include the proper host name of the server
in TCPClient.java.
You then execute TCPServer.class, the compiled server
program, in the server. This creates a process in the server
that idles until it is contacted by some client.
Then you execute TCPClient.class, the compiled client
program, in the client. This creates a process in the client
and establishes a TCP connection between the client and
server processes.
Finally, to use the application, you type a sentence followed
by a carriage return.

Chapter 2 Outline

clients and servers 2.7 Socket
app requirements

programming with
2.2 Web and HTTP UDP
2.3 FTP
2.8 Building a Web
2.4 Electronic Mail server
SMTP, POP3, IMAP
2.9 Content distribution
2.5 DNS Network Web caching
networks
P2P file sharing

Socket Programming with UDP
UDP: no “connection” between

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

Client/Server Socket Interaction: UDP
Server (running on hostid) Client
create socket, create socket,

port=x, for clientSocket =
incoming request: DatagramSocket()
serverSocket =
DatagramSocket()
Create, address (hostid, port=x,
send datagram request
read request from using clientSocket
serverSocket
write reply to
serverSocket
specifying client read reply from
host address, clientSocket
port number close
clientSocket

Example: Java Client (UDP)
inFromUser
Input
Stream
Input: receives
Process packet (TCP
received “byte
recievepacket
stream”)
sendpacket
UDP UDP
datagram datagram
packet packet
Output: sends
packet (TCP sent
“byte stream”)
UDP socket ClientSocket
To transport From
layer transport layer
Example: UDPClient.java
import java.io.*;
import java.net.*;
class UDPClient {
public static void main(String args[]) throws Exception
{
Create
input stream BufferedReader inFromUser =
new BufferedReader(new InputStreamReader(System.in));
Create
client socket DatagramSocket clientSocket = new DatagramSocket();
Translate
InetAddress IPAddress = InetAddress.getByName("hostname");
hostname to IP
address using DNS byte[ ] sendData = new byte[1024];
byte[ ] receiveData = new byte[1024];
String sentence = inFromUser.readLine();

sendData = sentence.getBytes();

Example: Example: UDPClient.java (cont.)
Create datagram
with data-to-send, DatagramPacket sendPacket =
length, IP addr, port new DatagramPacket(sendData, sendData.length, IPAddress, 9876);
Send datagram clientSocket.send(sendPacket);

to server
DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
Read datagram
clientSocket.receive(receivePacket);
from server
String modifiedSentence =
new String(receivePacket.getData());
System.out.println("FROM SERVER:" + modifiedSentence);

}
}

Code Descriptions-
Descriptions-UDPClient.java
The program UDPClient.java constructs one stream and one socket.

The socket is called clientSocket, and it is of type
DatagramSocket.
UDP uses a different kind of socket than TCP at the client. Here
the client uses a DatagramSocket whereas with TCP our client used
a Socket.
The stream inFromUser is an input stream to the program; it is
attached to the standard input, that is, to the keyboard. We had an
equivalent stream in our TCP version of the program. When the
user types characters on the keyboard, the characters flow into
the stream inFromUser.
In contrast with TCP, there are no streams (input or output)
attached to the socket. Instead of feeding bytes to the stream
attached to a Socket object, UDP will push individual packets
through the DatagramSocket object.

Code Descriptions-
DatagramSocket clientSocket = new DatagramSocket();
It creates the object clientSocket of type DatagramSocket.

In contrast with TCPClient.java, this line does not initiate a
TCP connection.
In particular, the client host does not contact the server
host upon execution of this line. For this reason, the
constructor DatagramSocket() does not take the server
hostname or port number as arguments.
The execution of the above line creates a port for the client
process but does not create a connection between the two
processes.

Code Descriptions-
InetAddress IPAddress = InetAddress.getByName("hostname");
In order to send bytes to a destination process, we shall

need to obtain the address of the process. Part of this
address is the IP address of the destination host.
The above line invokes a DNS look-up that translates the
hostname to an IP address.
DNS was also invoked by the TCP version of the client,
although it was done there implicitly rather than explicitly.
The method getByName() takes as an argument the
hostname of the server and returns the IP address of this
same server. It places this address in the object IPAddress
of type InetAddress.

Code Descriptions-
byte[ ] sendData = new byte[ ];

byte[ ] receiveData = new byte[ ];
The byte arrays sendData and receiveData will hold the data
the client sends and receives, respectively.
sendData = sentence.getBytes();
The above line essentially performs a type conversion. It

takes the string sentence and renames it as sendData, which
is an array of bytes.

Code Descriptions-
DatagramPacket sendPacket = new DatagramPacket(sendData,

sendData.length, IPAddress, 9876);
This line constructs the packet, sendPacket, that the client

will pop into the network through its socket.
Note that sendPacket is of type DatagramPacket.
This packet includes that data that is contained in the
packet, sendData,
the length of this data,
the IP address of the server, and
the port number of the application (which we have set to 9876).

Code Descriptions-
clientSocket.send(sendPacket);
In the above line, the method send() of the object

clientSocket takes the packet just constructed and pops it
into the network through clientSocket.
Once again, note that UDP sends the line of characters in a
manner very different from TCP.
TCP simply inserted the line into a stream, which had a
logical direct connection to the server; UDP creates a
packet that includes the address of the server.
After sending the packet, the client then waits to receive a
packet from the server.

Code Descriptions-
DatagramPacket receivePacket = new

DatagramPacket(receiveData, receiveData.length);
In the above line, while waiting for the packet from the
server, the client creates a place holder for the packet,
receivePacket, an object of type DatagramPacket.
clientSocket.receive(receivePacket);
The client idles until it receives a packet; when it does

receive a packet, it puts the packet in receivePacket.

Code Descriptions-
String modifiedSentence = new String(receivePacket.getData());

It extracts the data from receivePacket and performs a
type conversion, converting an array of bytes into the string
modifiedSentence.
System.out.println("FROM SERVER:" + modifiedSentence);

This line, which is also present in TCPClient, prints out the
string modifiedSentence at the client's monitor.
This last line closes the socket. Because UDP is
connectionless, this line does not cause the client to send a
transport-layer message to the server (in contrast with
TCPClient).

Example: UDPServer.java
import java.io.*;
import java.net.*;
class UDPServer {
public static void main(String args[ ]) throws Exception
Create {
datagram socket
DatagramSocket serverSocket = new DatagramSocket(9876);
at port 9876
byte[ ] receiveData = new byte[1024];
byte[ ] sendData = new byte[1024];
while(true)
{
Create space for
DatagramPacket receivePacket =
received datagram
new DatagramPacket(receiveData, receiveData.length);
Receive serverSocket.receive(receivePacket);
datagram
Example: Example: UDPServer.java (cont.)
String sentence = new String(receivePacket.getData());

Get IP addr
InetAddress IPAddress = receivePacket.getAddress();
port #, of
sender int port = receivePacket.getPort();
String capitalizedSentence = sentence.toUpperCase();
sendData = capitalizedSentence.getBytes();
Create datagram
DatagramPacket sendPacket =
to send to client new DatagramPacket(sendData, sendData.length, IPAddress,
port);
Write out
datagram serverSocket.send(sendPacket);
to socket }
}
} End of while loop,
loop back and wait for
another datagram
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 the following
obtains requested file
slides for details.
from server’s file
system
creates HTTP response
message:
header lines + file
sends response to client

Example: WebServer.java
import java.io.*;
import java.net.*;
import java.util.*;
class WebServer {
{
String requestMessageLine; contain the first line in the HTTP request message
contain the file name of the requested file
String fileName;
ServerSocket listenSocket = new ServerSocket(6789); When a request for a connection
two streams are created
arrives, the accept( ) method of

Socket connectionSocket = listenSocket.accept(); listenSocket creates a new object,
BufferedReader inFromClient = new BufferedReader( connectionSocket, of type Socket.
new InputStreamReader(connectionSocket.getInputStream()));
DataOutputStream outToClient =
new DataOutputStream(connectionSocket.getOutputStream());

Example: WebServer.java (cont.)
requestMessageLine = inFromClient.readLine(); reads the first line of the

HTTP request message.
StringTokenizer tokenizedLine =
new StringTokenizer(requestMessageLine); tokenizedLine holds the request line
with each of the "words" GET,
If(tokenizedLine.nextToken().equals("GET")) { file_name, and HTTP/1.1 placed in a
fileName = tokenizedLine.nextToken(); separate placeholder called a token.
if (fileName.startsWith("/") == true ) removes the backslash that

fileName = fileName.substring(1); may precede the filename.
File file = new File(fileName);
int numOfBytes = (int) file.length(); These commands determine the
size of the file and construct an
FileInputStream inFile = array of bytes of that size. The
new FileInputStream (fileName); name of the array is fileInBytes.
byte[ ] fileInBytes = new byte[ ];
inFile.read(fileInBytes); reads from the stream inFile
to the byte array fileInBytes

Example: WebServer.java (cont.)
sends the mandatory status line: HTTP/1.1

200 Document Follows, followed by a
outToClient.writeBytes( carriage return and a line feed.
"HTTP/1.0 200 Document Follows\r\n"); ◊ to transfer a GIF

image, server prepares
if (fileName.endsWith(".jpg")) the header line
Content-Type:
outToClient.writeBytes("Content-Type:image/jpeg\r\n"); image/gif.
if (fileName.endsWith(".gif")) ◊ to transfer a JPEG
image, server prepares
outToClient.writeBytes("Content-Type:image/gif\r\n"); the header line
Content-Type:
sends a image/jpeg.
content-
length
header line
outToClient.writeBytes("Content-Length: " +numOfBytes + "\r\n");
and a
mandatory
outToClient.writeBytes("\r\n");
blank line
sends the requested
outToClient.write(fileInBytes, 0, numOfBytes); file, fileInBytes, to
the TCP send buffer
connectionSocket.close(); closing the socket connectionSocket
}
else System.out.println("Bad Request Message");
}}
Code Descriptions-
Descriptions-WebServer.java
The first half of the program is almost identical to

TCPServer.java. As with TCPServer.java, we import the
java.io and java.net packages.
In addition to these two packages we also import the
java.util package, which contains the StringTokenizer class,
which is used for parsing HTTP request messages.

Code Descriptions-
Looking now at the lines within the classWebServer, we

define two string objects:
String requestMessageLine;
String fileName;
The object requestMessageLine is a string that will contain

the first line in the HTTP request message.
The object fileName is a string that will contain the file
name of the requested file.

Code Descriptions-
The next set of commands is identical to the corresponding

set of commands in TCPServer.java.
ServerSocket listenSocket = new ServerSocket(6789);

Socket connectionSocket = listenSocket.accept();
Two socket-like objects are created. The first of these
objects is listenSocket, which is of type ServerSocket. The
object listenSocket is created by the server program
before receiving a request for a TCP connection from a
client. It listens at port 6789 and waits for a request from
some client to establish a TCP connection. When a request
for a connection arrives, the accept() method of
listenSocket creates a new object, connectionSocket, of
type Socket.

Code Descriptions-
BufferedReader inFromClient =
new BufferedReader(new InputStreamReader
(connectionSocket.getInputStream()));
DataOutputStream outToClient =
new DataOutputStream(connectionSocket. getOutputStream());
Next two streams are created: the BufferedReader

inFromClient and the DataOutputStream outToClient. The
HTTP request message comes from the network, through
connectionSocket and into inFromClient; the HTTP response
message goes into outToClient, through connectionSocket
and into the network.

Code Descriptions-
The remaining portion of the code differs significantly from

TCPServer.java.
requestMessageLine = inFromClient.readLine();
The above command reads the first line of the HTTP

request message. This line is supposed to be of the form:
GET file_name HTTP/1.1

Code Descriptions-
Our server must now parse the line to extract the filename.
StringTokenizer tokenizedLine =
new StringTokenizer(requestMessageLine);
if (tokenizedLine.nextToken().equals("GET")) {
fileName = tokenizedLine.nextToken();
They parse the first line of the request message to obtain

the requested filename.
The object tokenizedLine can be thought of as the original
request line with each of the "words"
GET,
file_name, and
HTTP/1.1
placed in a separate placeholder called a token.

Code Descriptions-
The server knows from the HTTP RFC that the file name for
the requested file is contained in the token that follows the
token containing "GET."
This file name is put in a string called fileName.
if (fileName.startsWith("/") == true )
fileName = fileName.substring(1);
The purpose of the above if statement in the above code is

to remove the backslash that may precede the filename.

Code Descriptions-
FileInputStream inFile = new FileInputStream (fileName);

The above command attaches a stream, inFile, to the file
fileName.
byte[] fileInBytes = new byte[];

inFile.read(fileInBytes);
These commands determine the size of the file and
construct an array of bytes of that size. The name of the
array is fileInBytes.
The last command reads from the stream inFile to the byte
array fileInBytes. The program must convert to bytes
because the output stream outToClient may only be fed with
bytes.

Code Descriptions-
Now we are ready to construct the HTTP response message.

To this end we must first send the HTTP response header
lines into the DataOutputStream outToClient:
outToClient.writeBytes("HTTP/1.0 200 Document Follows\r\n");
The above and next two commands are particularly

interesting. These commands prepare the header lines for
the HTTP response message and send the header lines to
the TCP send buffer.
The above command sends the mandatory status line:
HTTP/1.1 200 Document Follows, followed by a carriage
return and a line feed.

Code Descriptions-
if (fileName.endsWith(".jpg")) outToClient.writeBytes("Content-
Type: image/jpeg\r\n");
if (fileName.endsWith(".gif")) outToClient.writeBytes("Content-Type:
image/gif\r\n");
These tow command lines prepare a single content-type

header line.
If the server is to transfer a GIF image, then the server
prepares the header line Content-Type: image/gif.
If the server is to transfer a JPEG image, then the server
prepares the header line Content-Type: image/jpeg. (In this
simple Web server, no content line is sent if the object is
neither a GIF nor a JPEG image.)

Code Descriptions-
outToClient.writeBytes("Content-Length: " + numOfBytes + "\r\n");

outToClient.writeBytes("\r\n");
The server then prepares and sends a content-length header

line and a mandatory blank line to precede the object itself
that is to be sent. We now must send the file FileName into
the DataOutputStream outToClient.

Code Descriptions-
We can now send the requested file:
outToClient.write(fileInBytes, 0, numOfBytes);
The above command sends the requested file, fileInBytes, to the
TCP send buffer. TCP will concatenate the file, fileInBytes, to the
header lines just created, segment the concatenation if necessary,
and send the TCP segments to the client.
connectionSocket.close();
After serving one request for one file, the server performs some
housekeeping by closing the socket connectionSocket.

Code Descriptions-
To test this Web server,

install it on a host.
put some files in the host.
Then use a browser running on any machine to request a file
from the server.
When you request a file, you will need to use the port
number that you include in the server code (for example,
6789).
So if your server is located at somehost.somewhere.edu, the
file is somefile.html, and the port number is 6789, then the
browser should request the following:
http://somehost.somewhere.edu:6789/somefile.html

Socket Programming: References
C-language tutorial (audio/slides):

“Unix Network Programming” (J. Kurose),
http://manic.cs.umass.edu/~amldemo/courseware/intro.
Java-tutorials:
“All About Sockets” (Sun tutorial),
http://www.javaworld.com/javaworld/jw-12-1996/jw-12-
sockets.html
“Socket Programming in Java: a tutorial,”
sockets.html

Chapter 2 Outline
2.1 Principles of app 2.6 Socket programming with

layer protocols TCP
clients and servers 2.7 Socket programming with
app requirements UDP
2.2 Web and HTTP 2.8 Building a Web server
2.3 FTP 2.9 Content distribution
2.4 Electronic Mail (delivery)
SMTP, POP3, IMAP Network Web caching
2.5 DNS networks
P2P file sharing

Content Distribution Network
networks
browsers
Web server

The Problem: Congestion
networks
browsers
routers
servers

Content Delivery Network: Idea
browsers
replicated
content
(mirror)
content sink
(cache)
router
content source
server

Content Distribution Metric
Cost × Performance analysis is the key metric to

the effectiveness of an information (content)
distributed system.

Servers: Caching, and Mirror
(content distribution strategies)
The conventional Technologies are:

Proxy cache server, and
Mirror server
They are cost effective technologies which

enhance the performance, namely:
Reducing the latency of access.
Reducing the network bandwidth required for document
transfers.
Reducing the demand on servers with very popular
documents.
Improving the security of electronic file transfer.

Caching: idea
(information distribution strategies)
Basic idea in caching:

Store the frequently retrieved documents into
local files or proxies for future use.
It improves:
access speed and
cuts down on network traffic.
It also reduces:
the server load and
increase availability in the web by replicating
documents among many servers (cache).

Caching: client - network
Caching on client disk:

Browsers maintain small caches of previously-viewed
pages on the user’s local disk. ( example: Documents and
Settings\WELCOME\Local Settings\Temporary Internet Files )
Network caching:
Caching system is located on machine in the
path from multiple clients to multiple servers.

Caching: proxy
Caching proxy servers can be located near a

large community of users such as:
on a campus network,
at an intranet server, or origin servers
at an ISP server.
origin
servers
HTML, FTP, Search, Database
LAN router Internet
router
Internet
institutional institutional
network Cache(Proxy server)
Proxy Architecture
Web Caches (Proxy web-
web-Server)
Goal: satisfy client request without involving origin server.
origin
user sets browser: Web server
accesses via cache
(proxy) Proxy
server
browser sends all HTTP
requests to cache client
(proxy)
object in cache: cache
returns object
else cache requests
object from origin
server, then returns client
object to client origin
server

More about Web Caching
Cache acts as both client Why Web caching?

and server Reduce response time for
Cache can do up-to-date client request.
check using If-modified-
Reduce traffic on an
since HTTP header
institution’s access link.
Issue: should cache take
risk and deliver cached
Internet dense with caches
object without checking? enables “poor” content
Heuristics are used.
providers to effectively
deliver content
Typically cache is installed
by ISP (university,
company, residential ISP)

Content Distribution Model
λ :Arrival (request) Service Providing Departure (response)

Entity
in service
waiting Departure (response)
λ :Arrival (request)
Service Providing
Entity
Service Providing Entity examples:

Server
LAN
Access Link
…

Model Parameters
in service
waiting Departure (response)
λ :Arrival (request)
S
Service Providing
Entity
λ: Average Arrival rate [requests/sec]

S: Average Service time [sec/response];
Example1: Server
λ: Average Arrival rate [file request/sec]
S: Average Service time [sec/file response];
Example2: Link, LAN
λ: Average Arrival rate [bit/sec]
S: Average Service time [sec/file] = L/R; L: file length, R: Link
Bandwidth

Model Equations (M/M/1)
Utilization of Service Providing Entity = U = λxS;

(λ≤1/S)
delay (Response Time)=Service Time + Waiting Time;

delay = S/(1-U);
Waiting Time (Queuing Delay) = delay – S

Equations for Link, LAN
λ = a [files/sec]; rate of files entering into the

link, LAN
S = L/R [sec/file]; the time needed to pass a file
through the Link, LAN
U = λxS = La/R [ ]; Link, LAN Utilization

I = U [ ]; Link, LAN Traffic Intensity
delay = S/(1-U) = L/[R(1-U)] [secs/file]

Link Response Time
Uuplink = Lreq λ /Rlink = Iuplink Files from origin servers
delayup = Sup/(1-Uuplink) [sec/req] λ’

Internet router
Udownlink = Lres λ’ /Rlink = Idownlink

Ruplink Rdownlink
delaydown = Sdown/(1-Udownlink) [sec/res]
LAN router
delay = delayup + delaydown ≈ delaydown
It is because: Lres >> Lreq λ
Request from clients

Caching Example1 (1)
Assumptions origin
servers
Average request rate from
institution’s browser to origin
serves: λ = 15reqs/sec public
Internet
Average request massage size ≈ 0

bit
Rlink =1.6 Mbps
(up and down)
Average object size = L= 100,000

bits LAN
Internet delay ≈ 2 sec (average)

Time spent in the Internet Rlan =10 Mbps

Caching Example1 (2)
delay is calculated for down stream only:
origin
LAN Service time= Slan = L/Rlan = 10
servers
msec
LAN Utilization = La/Rlan = 0.15 = 15%
LAN delay =S/(1-U) = 10/0.85 =11.8 public
msec Internet
Link Service time Slink = L/Rlink = 62.5
msec
937.5 msecs
Link Utilization (Traffic Intensity) =
La/Rlink = 93.75% Rlink =1.6 Mbps
62.5 msecs
access-link
Link delay = 62.5/0.0625 = 1000 msec
LAN
delay = Internet delay + access-link 11.8 msecs
delay + LAN delay =
2000 + 1000 + 11.8 =3011.8 msecs
qrouter = 1000 – 62.5 = 937.5 msec Rlan =10 Mbps

Caching Example2
Upgrade the link:
origin
LAN Service time= Slan = L/Rlan = 10 msec
servers
LAN Utilization = La/Rlan = 0.15 = 15%
LAN delay = S/(1-U) = 10/0.85 = 11.8
msec public
Internet
Link Service time Slink = L/Rlink = 10 msec
Link Utilization (Traffic Intensity) = 1.8 msecs
La/Rlink = 15% Often a costly upgrade
Rlink =10 Mbps
Link delay = 11.8 msec 10 msecs
access-link
delay = Internet delay + access-link LAN

delay + LAN delay = 11.8 msecs
2000 + 11.8 + 11.8 =2023.6 msecs
qrouter = 11.8 – 10 = 1.8 msec
Rlan =10 Mbps

Caching Example3
origin
Install cache servers
suppose hit rate is 0.4
public
Consequence
Internet
40% requests will be satisfied
almost immediately
80.5 msecs
60% requests satisfied by origin
server Rlink =1.6 Mbps
62.5 msecs
access-link
utilization of access link (reduced
to 60%) = 0.6 *93.75= 56.25%
LAN
Link delay = 62.5/0.4375 = 143
11.8 msecs
msec
delay = 0.4* 11.8 + 0.6 x (2000 +
143 + 11.8) = 1297.6 msec
Rlan =10 Mbps Network
cache

Content Distribution Network: idea
The content (information)

origin server
providers are the CDN in North America
customers.
Content replication (mirror)

CDN company installs
CDN distribution node
hundreds of CDN servers
throughout Internet.
in lower-tier ISPs, close
to users.
CDN replicates its customers’
content in CDN servers.
When provider updates CDN server
CDN server
content, CDN updates in S. America CDN server
in Asia
servers. in Europe

CDN: Architectural Layout
Request 1 Origin
Routing(RR) Server
2a
Distribution
Node
2b 3
5 Mirror
Server
6
4
Client
1. Origin server informs RR of Content Availability.
2. Content Pushed to Distribution System.
3. Client Requests Content, Origin server redirects client to RR.
4. Client sends query to RR.
5. RR finds the most suitable Mirror Server.
6. Mirror server receives client request and provides services.
More about CDNs
routing requests not just Web pages

CDN creates a “map”, streaming stored
indicating distances audio/video
from leaf ISPs and
CDN nodes streaming real-time
when query arrives at

audio/video
authoritative DNS CDN nodes create
server: application-layer
overlay network
server determines ISP
from which query ‫ ي رو‬
originates ‫ ي آرد‬
uses “map” to determine
best CDN server

Overlay networks
Edge between peer X and Y if there is a TCP connection.
All active peers and edges is overlay network.
Edge is not a physical link.
Given peer will typically be connected with <10 overlay neighbors
Overlay
X
IP
Y

Overlay Networks
Overlay
IP

P2P File Sharing
Example User1 chooses one of
User1 runs P2P client the peers, User2.
application on his notebook File is copied from
computer. User2’s PC to User1’s
Intermittently connects to notebook: HTTP
Internet; gets new IP
address for each
While User1
connection. downloads, other users
Asks for “network e-book”
uploading from User1.
Application displays other User1’s peer is both a
peers that have copy of Web client and a
network e-book. transient Web server.
All peers are servers = highly scalable!

Definitions
Clay Shirky (www.shirky.com)
P2P is a class of applications that take advantage

of resources:
storage,
cycles,
content,
human presence
available at the edges of the Internet.

Milojicic et al. (HP)
P2P refers to a class of systems and applications
that employ distributed resources to perform a
critical function in a decentralized manner.

Some controversy
Is p2p a new approach?
Problems is peer-to-peer systems are neither new

nor unique; they make us look for solutions to old
problems that we all worked around or tried to
ignore before.
Andy Oram (O'Reilly & associates)
speech at Free and Open Source
Software Developers's Meeting
Brussels, BE, Feb. 2002

Example: University of Washington (2002)
UW is an HTTP content provider

Exported 16.65 TB - Imported 3.44 TB
Bandwidth consumption (in + out)
0.2% Akamai (overnet. eDonkey) [content delivery
networks]
6.04% Gnutella (p2p system)
14.3% WWW
36.9% Kazaa (p2p system)
43% other TCP protocols, e.g. mail, streaming video

Properties
No central control, no central database

No hierarchy
Every node is both a client and a server
The communication between peers is symmetric
No global view of the system
Scalability
Availability for any peer
Peers are autonomous
System globally unreliable
Robustness and security issues

Examples of p2p Applications
File-sharing applications Collaboration

Napster, KazaA, Gnutella, Distributed (Internet)
Freenet, … games, Instant messaging,
E-Commerce Systems Shared Application, …
eBay, … Distributed databases
Parallel Processing Mariposa, Litwin, Yokota,
Distributed computing Plaxton, …
(grid?), SETI (Internet- Mobile Ad hoc networks
connected computers used (Unstructured networks)
for Search for
Application-level multicast
Extraterrestrial
Intelligence), … …

How Much P2P is Involved?
P2P User P2P P2P

Interaction Application Information
Management
eBay yes no no
Napster yes yes no
Gnutella, yes yes yes
Freenet

Types of P2P Systems
Hybrid or Centralized (Napster)

Pure or Decentralized (Gnutella, Freenet)
Super Peers or Hierarchical (KaZaA, DNS)
Redundant Super Peers (DNS)

Hybrid or Centralized P2
P2P
In a hybrid P2P system, some operations are

performed at a central server.
For other operations, the peers have equal status.
Example: Napster file download
Central server contains an index of the files located at
all the peers currently available.
Peer 1 asks server where a file is located.
Server returns address of Peer 2 who has the file.
Peer 1 asks Peer 2 (directly) for the file.
Next 2 slides

Hybrid System
2
1 5
5
2 5
3 3 4
4
5
Give me
1 5
4 Who has

Napster as a Centralized System
Original “Napster” design User2

location
1 ° Peers to notify server when
1)
they join and leave: server
(IP Add, Port Num) 1
° Peers to notify server if 1

their available files change:
Contents 1
3
peers
° Peers to run a “server”
program that listens on a 2 1
port for download requests.
2 User1 queries for “network

2)
e-book”,
3)
3 User1 requests file from
User2. User1

Centralized model (Napster)
Peer Z
IP: a.b.c.d
location
server
register
INTERNET
Document x!
OK:
Document
Peer Z x?
IP = a.b.c.d
x

Hybrid: Ads and DisAds
Advantages:
Search is generally efficient
Disadvantages
High cost on centralized index
Performance & scalability bottleneck
Vulnerable! Highly visible target

Pure P2P-
P2P-1
All peers have equal roles in all responsibilities

Example: Gnutella
In order to find an item, Peer 1 asks his neighbors
if they have it.
They ask their neighbors, and so on
A message has a “time to live” which determines
how long it will be sent along.
Why is this needed?
Different search strategies will be discussed later

Pure P2
P2P-2
What happens when a peer (say, Peer 34) is

identified, who has the file that Peer 1 wants?
2 Different options are in use in different
systems
Peer 34 directly sends file to Peer 1
Peer 34 sends the file back in the same route that it was
requested
Advantages/disadvantages of each option?

Pure P2P
?
?
?
?
?
?
?
?

Pure P2P: Option 1

Pure P2P: Option 2

Gnutella: protocol
Query message
HTTP sent over QueryHit
existing TCP Query
connections
Gnutella on ports
6346 and 6347
peers forward Query
message
Query QueryHit
QueryHit sent over
reverse path QueryHit Query
Query
Scalability: limited
scopeflooding Query

Gnutella Protocol Messages
Broadcast Messages
Ping: initiating message (“I’m here”)
Query: search pattern and TTL (time-to-live)
Back-Propagated Messages
Pong: reply to a ping, contains information about the peer
Query response: contains information about the
computer that has the needed file
Node-to-Node Messages
GET: return the requested file
PUSH: push the file to me

Peer Joining in Gnutella
Joining peer X must find some other peer in Gnutella

network; use list of candidate peers.
X sequentially attempts to make TCP connection with peers
on list until connection setup with Y.
X sends Ping message to Y; Y forwarded Ping message.
All peers receiving Ping message respond with Pong message.
X receives many Pong messages. It can then setup additional
TCP connections.
Peer living!

Topology of Gnutella
Backbone Backbone + Outskirts

Pure: Ads and DisAds
Advantages:
Easy to start
No maintenance needed
Hard to shut down
privacy
Disadvantages:
Inefficient search
Lot of network traffic
Bottlenecks (limited peers)

Super Peers
Make use of heterogeneity

Powerful peers serve as super peers
Weaker peers act as clients
Example: KaZaA
Super-peers index clients’ files
Requires updates on join/leave/update
Queries handled at super-peer level.
Query evaluation between super-peers similar to query
evaluation between peers in a pure system.

Super Peers

Decentralized Directory (KaZaA)
Each peer is either

a group leader or
assigned to a group
leader.
Group leader tracks
the content in all its
children.
Each peer queries its
group leader.
Group leader may
query other group ordinary peer (ordinary node)
leaders. group-leader peer (super node)
KazaA on port 1214 neighboring relationships

in overlay network

KazaA Query
Each file has a hash and a descriptor.

Client sends keyword query to its group leader.
Group leader responds with matches;
For each match: metadata, hash, IP address
If group leader forwards query to other group
leaders, they respond with matches.
Client then selects files for downloading;
HTTP requests using hash as identifier sent to peers
holding desired file.

Super Peers: Ads and DisAds
Advantages:
All the advantages of pure
Takes advantage of different peer capabilities
Disadvantages:
Super nodes might become bottlenecks for clients
Clients are disconnected when super peer leaves
Inefficient search (but better than Pure P2P)
Maintenance costs for super peers

Redundant Super Peers
Like super peers, but each super-peer is k-

redundant, i.e., there are k nodes sharing the
super peer load
all k nodes have the same indexes of all the clients
clients ask super-peer queries in a round robin fashion

Super Peers

Redundant Super Peers

Redundant Super Peers: Ads and DisAds
Advantages
All advantages of super-peers
load of queries is shared among peers
less points of fail
Disadvantages
additional maintenance: nodes must notify all redundant
super-peers upon joining, leaving, updating files
Additional connections between super-peers required

Non--structured system (Gnutella-
Non (Gnutella-like)
Two phases (like Napster)

Localization + exchange
No server
Open source
gnutella.wego.com
Distributed search
The query is flooded
Loop avoidance
Limited TTL (not all nodes are visited)

Structured systems (DHTs)
Based on Distributed Hash Tables (DHTs)

No flooding
Exact matches
Overhead
Gnutella-like O(n)
DHT O(log n)
Examples
CAN, Pastry, Chord, Kademlia, Tapestry, P-Grid, ...

Content--Addressable Networks (CAN)
Content
Provides a large scale distributed hash table

Keys are mapped into values
CAN defines a d-dimensional virtual space
No relationship with the physical space
Query O(n1/d)
Neighbors O(d)
The virtual space is completely distributed among
the peers
Each peer is responsible for one share of the space
The peer that is responsible for region R is also
responsible for the values inside R
Documents must be uniquely identified

Example

Example

Example
1 2

Example

Example

Example
4
4
1
5

Example
1 4
6 5

Example
1 7 4
6 5

Association ID node
1 7 4
6 5
Ex: Node 3
holds this
3
document

Association ID node
1 7 4
6 5

Application--layer multicast
Application
Native multicast not yet completely

deployed
ALM easier/faster to implement

Scalability states at end-systems
High-level support

Application--layer multicast
Application
source

Many works and projects
Gnutella and Napster

@sourceforge.net

JXTA (Sun)
Open platform for p2p cooperation
Interoperability
Any system/peer/application
Platform independency
Languages (C, Java, etc)
Systems platforms (Unix, Windows, etc)
Networking platforms (802.11, Bluetooth, TCP/IP, etc)
Ubiquity
Sensors, PDAs, routers, desktops, laptops, storage
systems

JXTA (Sun)
Objectives
Find peers and resources
Share files with anyone across the network
Create a particular group of peers across different
networks
Communicate securely with peers across public networks
Projects
Applications (24 projects)
Core (13 projects)
Demos (3 projects)
Forge (15 projects)
Other (12 projects)
Services (24 projects)
JXTA (Sun) Protocols
Peer discovery protocol

Peer resolver protocol
Peer information protocol
Rendezvous protocol
Pipe binding protocol
Endpoint routing protocol

JXTA (Sun)
JXTA Community Applications JXTA

Shell
Sun JXTA Peer

JXTA Community Services
Services Commands
J C
Peer Groups Peer Pipes Peer Monitoring X O
T R
Security A E
Peer (Desktop, cell phone, PDA, etc.)

JXTA applications

Final remarks
P2P implies a very large spectrum of areas

High interest in both academicals/industrials
Much has already been done, but no conclusions
are definitive
IPv6 and P2P
NAT, firewalls, IPv6 as an overlay
Many open issues
Trust, security, scalability, QoS, etc.

Chapter 2: Summary
Summary11
Our study of network apps now complete!
application service specific protocols:

requirements: HTTP
reliability, bandwidth,
delay.
FTP
SMTP, POP, IMAP
client-server
paradigm. DNS
Internet transport socket programming
service model. content distribution
connection-oriented, caches, CDNs
reliable: TCP
unreliable, datagrams: UDP P2P

Chapter 2: Summary2
Most importantly: learned about protocols

typical request/reply control vs data messages
message exchange: in-band, out-of-band
client requests info or
service centralized vs. decentralized
server responds with stateless vs. stateful
data, status code reliable vs. unreliable msg transfer
message formats: “complexity at network edge”
headers: fields giving security: authentication
information about data
data: information being
communicated

References & Links
Complimentary Hyperlinks
This part provides hyperlinks to interesting
(and hopefully useful) computer-networking
resources.
Most of these resources provide complimentary
information to the material in chapter 2.
If you're asked to write a paper pertaining to a
specialized topic in computer networking, these
resources should serve as a good starting point
for your research.
References and Hyperlinks

Hyperlinks1
1
Unix Network Programming http://www-

aml.cs.umass.edu/~jsmanic/unetpgm
Online tutorial on Unix socket programming, using slides and
audio, from author James Kurose.
Tutorial on Java sockets

sockets.html
This tutorial presents an introduction to sockets programming
and shows how to write client/server applications in Java.

Hyperlinks2
2
The World Wide Web Consortium (W3C) http://www.w3.org/

The W3C was founded in 1994 to develop common protocols for the evolution of
the World Wide Web. This is an outstanding site with fascinating information on
emerging Web technologies, protocols, and standards.
Web Protocols and Practice

http://www.aw.com/catalog/academic/product/1,4096,0201710889,00.html
Web Protocols and Practice: HTTP/1.1, Networking Protocols, Caching, and Traffic
Measurement, a comprehensive and readable book by Balachander Krishnamurthy
and Jennifer Rexford on Web protocols and related topics.
Cookie Central http://www.cookiecentral.com/

Everything you ever wanted to know about cookies, including how they infringe on
users' privacy.
The IMAP Connection http://www.imap.org/

Everything you always wanted to know about IMAP, including history, direct
access to relevant RFCs, and product information.

Hyperlinks3
3
ISC BIND http://www.isc.org/products/BIND

DNS name servers use the Berkeley Internet Name Domain
(BIND) software. You can learn about it (and download it) here.
Exploring Name Servers http://www.unhooked.net/cgi-

bin/host
nslookup, host, and dig are client programs available for
exploring the contents of name servers in the Internet. Several
sites, including the one listed above, allow you to access these
programs through a Web browser. All of these programs mimic
DNS clients. They send a DNS query message to a name server
(which can often be supplied by the user), and they receive a
corresponding DNS response. They then extract information
(e.g., IP addresses, whether the response is authoritative, etc.)
and present the information to the user.

Complimentary Hyperlinks 4
Online Java Tutorial http://java.sun.com/docs/books/tutorial

Do you what to learn Java before doing the programming exercises?
This is an excellent place to start.
Akamai Homepage http://www.akamai.com/

Homepage for leading Content Distribution Network (CDN) company.
Developers Site for Gnutella http://www.gnutelladev.com/

Includes links to source code as well as links to documentation of the
protocol.

References and Hyperlinks1
Hyperlinks1
A note on Internet Request for Comments (RFCs): Copies of Internet RFCs

are maintained at multiple sites. The RFC URLs below all point into the RFC
archive at the Information Sciences Institute (ISI), maintained the the
RFC Editor of the Internet Society (the body that oversees the RFCs).
Other RFC sites include http://www.faqs.org/rfc,
http://www.pasteur.fr/other/computer/RFC (located in France), and
http://www.csl.sony.co.jp/rfc/ (located in Japan).
Internet RFCs can be updated or obsoleted by later RFCs. We encourage
you to check the sites listed above for the most up-to-date information.
The RFC search facility at ISI, http://www.rfc-editor.org/rfcsearch.html,
will allow you to search for an RFC and show updates to that RFC.
[Abitz 1993] P. Albitz and C. Liu, DNS and BIND, O'Reilly & Associates,
Petaluma, CA, 1993.
[Akamai 2000] Akamai homepage, http://www.akamai.com

Hyperlinks2
[Berners-Lee 1994] T. Berners-Lee, R. Cailliau, A. Luotonen, H. Frystyk

Nielsen, and A. Secret, "The World-Wide Web," Commun. ACM 37, 8 (Aug.
1994), Pages 76-82
[BIND 2000] Internet Software Consortium page on BIND,
http://www.isc.org/bind.html
[Claffy 1998] K. Claffy, G. Miller, and K. Thompson, "The Nature of the
Beast: Recent Traffic Measurements from an Internet Backbone,"
Proceedings of Inet '98 , (Geneva, Switzerland, July 1998),
http://www.caida.org/outreach/resources/papers/Inet98/
[Cookie Central 2000] Cookie Central homepage,
http://www.cookiecentral.com
[Cusumano 1998] M.A. Cusumano and D.B. Toffle, Competing on Internet
Time: Lessons from Netscape and its Battle with Microsoft, Free Press,
1998
[DNSNet] DNSNet page on DNS resources,
http://www.dns.net/dnsrd/docs/

Hyperlinks3
[Frost 1994] J. Frost, "BSD Sockets: A Quick and Dirty Primer,"

http://world.std.com/~jimf/papers/sockets/sockets.html
[Gauthier 1999] L. Gauthier, C. Diot, and J. Kurose, "End-to-end
Transmission Control Mechanisms for Multiparty Interactive Applications
on the Internet," Proceedings of IEEE Infocom '99, (New York, NY, Apr.
1999). ftp://ftp.sprintlabs.com/diot/infocom99-mimiaze.zip
[Gay 1997] V. Gay and B. Dervella, "MHEGAM--A Multimedia Messaging
System," IEEE Multimedia Magazine, Oct.-Dec. 1997, pp. 22-29.

Hyperlinks4
[Heidemann 1997] J. Heidemann, K. Obraczka, and J. Touch, "Modeling the

Performance of HTTP over Several Transport Protocols," IEEE/ACM
Transactions on Networking, Vol. 5, No. 5 (Oct. 1997), pp. 616-630.
[Hess 1998] C. Hess, D. Lin and K. Nahrstedt, "VistaMail: An Integrated
Multimedia Mailing System," IEEE Multimedia Magazine, Oct.-Dec. 1998, pp.
13-23.
[Huffaker 1998] B. Huffaker, J. Jung, D. Wessels, and K. Claffy,
"Visualization of the Growth and Topology of the NLANR Caching
Hierarchy," The 3rd Web Caching Workshop, June 1998, England.
http://www.caida.org/tools/visualization/plankton/Paper/plankton.xml

Hyperlinks5
[IMAP 1999] The IMAP Connection, http://www.imap.org/

[ITU 1997] International Telecommunications Union, "Recommendation
E.164/ I.331--The international public telecommunication numbering plan,"
May 1997. http://www.itu.int/itudoc/itu-t/rec/e/s_e164.html
[Kurose 1996] J. F. Kurose, Unix Network Programming.
http://manic.cs.umass.edu/~amldemo/courseware/intro.html
[Luotonen 1998] A. Luotonen, Web Proxy Servers, Prentice Hall, Englewood
Cliffs, New Jersey, 1998.
[McKusik 1996] Marshall Kirk McKusick, Keith Bostic, Michael Karels, and
John Quarterman, The Design and Implementation of the 4.4BSD Operating
System, Addison-Wesley, Reading, MA, 1996.
[Netcraft 2000] The Netcraft Web Server Survey, Netcraft Web Site,
http://www.netcraft.com/survey/

Hyperlinks6
[Netscape Cookie 1999] Netscape, "Persistent Client State http Cookies.

http://home.netscape.com/newsref/std/cookie_spec.html
[Nielsen 1997] H. F. Nielsen, J. Gettys, A. Baird-Smith, E. Prud'hommeaux,
H. W. Lie, and C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1,
and PNG," W3C Document, 1997 (also appears in Proceedings of ACM
SIGCOMM '97, Cannes, France, pp. 155-166 ).
http://www.acm.org/sigcomm/sigcomm97/papers/p102.html
[NLANR 1999] A Distributed Testbed for National Information
Provisioning, http://ircache.nlanr.net/
[Padhye 1999] J. Padhye and J. Kurose, "An Empirical Study of Client
Interactions with a Continuous-Media Courseware Server," IEEE Internet
Computing, Apr. 1999. ftp://gaia.cs.umass.edu/pub/Padh97:Empirical.ps.gz
[Ramjee 1994] R. Ramjee, J. Kurose, D. Towsley, and H. Schulzrinne,
"Adaptive Playout Mechanisms for Packetized Audio Applications in Wide-
Area Networks," Proceeding IEEE Infocom 94.
ftp://gaia.cs.umass.edu/pib/Ramj94:Adaptive.ps.Z
[RFC 821] J. Postel, "Simple Mail Transfer Protocol," RFC 821, Aug. 1982.
http://www.rfc-editor.org/rfc/rfc821.txt

Hyperlinks7
[RFC 854] J. Postel and J. Reynolds, "TELNET Protocol Specification," RFC

854. May 1993. http://www.rfc-editor.org/rfc/rfc854.txt
[RFC 959] J. Postel and J. Reynolds, "File Transfer Protocol (FTP)," RFC
959, Oct. 1985. http://www.rfc-editor.org/rfc/rfc959.txt
[RFC 1034] P. V. Mockapetris, "Domain Names--Concepts and Facilities," RFC
1034, Nov. 1987. http://www.rfc-editor.org/rfc/rfc1034.txt
[RFC 1035] P. Mockapetris, "Domain Names--Implementation and
Specification," RFC 1035, Nov. 1987. http://www.rfc-
editor.org/rfc/rfc1035.txt
[RFC 1945] T. Berners-Lee, R. Fielding, H. Frystyk, "Hypertext Transfer
Protocol--HTTP/1.0," RFC 1945, May 1996 http://www.rfc-
[RFC 2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies," RFC
2045, Nov. 1996. http://www.rfc-editor.org/rfc/rfc2045.txt

Hyperlinks8
[RFC 2046] N. Freed, N. Borenstein,, "Multipurpose Internet Mail

Extensions (MIME) Part Two: Media Types," RFC 2046, Nov. 1996.
http://www.rfc-editor.org/rfc/rfc2046.txt
[RFC 2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee,
"Hypertext Transfer Protocol--HTTP/1.1," RFC 2068, Jan. 1997.
http://www.rfc-editor.org/rfc/rfc2068.txt. Obsoleted by RFC 2616.
[RFC 2186] K. Claffy and D. Wessels, "Internet Caching Protocol (ICP),
version 2," RFC 2186, Sept. 1997. http://www.rfc-
[RFC 2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
Leach, T. Berners-Lee, R. Feilding, "Hypertext Transfer Protocol--
HTTP/1.1," RFC 2616, June 1999. http://www.rfc-
[Ross 1997] K. W. Ross, "Hash-Routing for Collections of Shared Web
Caches," IEEE Network Magazine, Vol. 11 (Nov.-Dec. 1997), pp. 37-45.
[Ross 1998] K. W. Ross, Distribution of Stored Information in the Web, An
Online Tutorial,
http://www.eurecom.fr/~ross/CacheTutorial/DistTutorial.html, 1998.

Hyperlinks9
[Schurmann 1996] G. Schurmann, "Multimedia Mail," ACM Multimedia

Systems, Oct. 1996, pp. 281-295.
[Squid 2000] Squid Web Proxy Cache, http://www.squid-cache.org/
[Stevens 1997] W.R. Stevens, Unix Network Programming, Volume 1:
Networking APIs-Sockets and XTI, 2nd edition, Prentice-Hall, Englewood
Cliffs, NJ, 1997.
[Turner 1999] D. A. Turner and K. W. Ross, "Continuous-Media Internet E-
Mail: Infrastructure Inadequacies and Solutions,"
http://www.eurecom.fr/~turner/cmail1.html
[Valloppillil 1997] V. Valloppillil and K. W. Ross, "Cache Array Routing
Protocol," Internet Draft, <draft-vinod-carp-v1-03.txt>, June 1997.
[Yeager 1996] N. J. Yeager and R. E. McGrath, Web Server Technology,
Morgan Kaufmann Publishers, San Francisco, 1996. © 2000-2001 by Addison
Wesley Longman
A division of Pearson Education

P2P-Working groups et al.
A generic site on p2p from O'Reilly

www.openp2p.com
P2P working group
www.peer-to-peerwg.org/
Internet2 p2p working group
p2p.internet2.edu
Peer-to-peer development (p2p-hackers)
zgp.org/mailman/listinfo/p2p-hackers
Interesting meeting
www.codecon.org

P2P--References-
P2P References-1
Distributed Computing
Distributed (www.distributed.net)
SETI@home (www.seti.org)
Genome@home (gah.stanford.edu)
Folding@home (www.stanford.edu/group/pandegroup/folding)
Global Grid Forum (www.globalgridforum.org)
Globus Project (www.globus.org)
File sharing
Napster (www.napster.com)
Gnutella (gnutella.wego.co)
Kazaa (www.kazaa.com)

P2P-References-
References-2
Distributed hash tables

CAN (www.acm.org/sigs/sigcomm/sigcomm2001/p13-ratnasamy.pdf)
Pastry (research.microsoft.com/~antr/Pastry)
Chord (www.pdos.lcs.mit.edu/chord)
Tapestry (www.cs.berkeley.edu/~ravenben/tapestry)
Freenet (freenet.sourceforge.net)
Kademlia (kademlia.scs.cs.nyu.edu)
Ad hoc networking
AODV (www.ietf.org/internet-drafts/draft-ietf-manet-aodv-
13.txt)
OLSR (www.ietf.org/internet-drafts/draft-ietf-manet-olsr-10.txt)
Tribe (rp.lip6.fr/site_rp/_publications/350-79Viana.ps.gz)

P2P--References-
P2P References-3
Platforms
JXTA (www.jxta.org)
.NET (www.microsoft.com/net)
Collaboration
Groove (www.groove.net)
Endeavors (www.endeavors.com)
IPv6 as a p2p overlay
Working Groups
p2p.internet2.edu
www.openp2p.com

Home Work2
Work2
Computer Networking ‫ "! ز از دوم ب‬
.#
$ % ‫ را‬3edition
3-4-5-11-12-14-15-23
‫ل‬-‫ ار‬jamali@iust.ac.ir ‫ *)درا (درس‬+,-.

Subject: HW2,”Student ID Number”.#
"

.#‫ ده‬6" ‫م‬7‫ ا‬LAN ‫ را ا ه دو‬cache ‫
ت‬3$4 cache server ‫ ز‬1 ‫ در‬-١
L1=100,000bits, a1=15req/sec, h1=50%(hit rate) :#‫ر‬1 ‫)ل‬9:" ‫ ا; روو‬LAN1 ‫ران‬
L2=50,000bits, a2=20req/sec, h2=30%(hit rate) :#‫ر‬1 ‫)ل‬9:" ‫ ا; روو‬LAN2 ‫ران‬
( @$ ١ ) .#
? ‫!ب‬% ‫ را‬LAN1 ‫= )در>( در‬-. ‫; ز"ن‬-)"
( @$ ١ ) .#
? ‫!ب‬% LAN2 ‫ را ا ران‬1 6‫ر ده‬AB
.#
$ ‫
ض‬D E
‫= ا?> را‬-. ‫ز"ن‬
origin
servers
access link1
public
Internet
access link2
100 Mbps LAN2

10 Mbps LAN1 LAN1 & LAN2
Cache server

CN Chp2 (Compatibility Mode)

Uploaded by

Document Information

Original Description:

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

CN Chp2 (Compatibility Mode)

Uploaded by

Copyright:

Available Formats

.

jamali@ iust.ac.ir June 23, 2010 Application Layer 2 -1

2.1 Principles of 2.6 Socket

jamali@ iust.ac.ir June 23, 2010 Application Layer 2 -2

within same host, two implements user

jamali@ iust.ac.ir June 23, 2010 Application Layer 2 -3

App. Software Controlled

jamali@ iust.ac.ir June 23, 2010 Application Layer 2 -4

Application Process Application Process

Application Program Interface (API) Application Program Interface (API)

Communication Software & Hardware Communication Software & Hardware

Server Agents Examples:

jamali@ iust.ac.ir June 23, 2010 Application Layer 2 -5

jamali@ iust.ac.ir June 23, 2010 Application Layer 2 -6

Types of messages Public-domain protocols:

jamali@ iust.ac.ir June 23, 2010 Application Layer 2 -7

provides requested service to client

jamali@ iust.ac.ir June 23, 2010 Application Layer 2 -8

connected and change IP

jamali@ iust.ac.ir June 23, 2010 Application Layer 2 -9

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-10

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

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-11

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-12

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-13

Application Data loss Bandwidth Time

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-14

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-15

applications application-layer underlying transport

remote terminal access Telnet [RFC 854] TCP

web HTTP [RFC 2616] TCP

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-16

2.1 Principles of app 2.6 Socket programming

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-17

host name path name

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-18

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-19

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-20

Nonpersistent HTTP Persistent HTTP

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-21

1. HTTP client initiates TCP

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-22

5. HTTP client receives response 4. …

time 7. Steps 1-6 repeated for each

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-23

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-24

Nonpersistent HTTP issues: Persistent without pipelining:

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-25

request line method SP URL SP version CR LF

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-26

status line version SP status code SP phrase CR LF

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-27

HTTP request message: ASCII (human-readable format)

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-28

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

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-29

The semantics of the GET method changes to a "conditional GET" if

There is no"conditional HEAD"request analogous to the conditional

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-30

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-31

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-32

jamali@ iust.ac.ir June 23, 2010 Application Layer 2-33