Datacom_Section_2_-_Protocols.ppt

Telecommunications Systems Engineer Course
Data Communications
Section 2
Wenyuan Xu
7-15-2011
References: Dr. Jackson

Review
 What is the difference between WAN and LAN?
 Give a definition of a protocol.
 What is connectionless-oriented service?
 What is the difference between FDMA and TDMA?
 What is circuit switching?
 When is circuit switching more efficient than packet
switching?
 What is burst traffic?
 What is the propagation delay?
◦ What does affect this delay?
 What is the transmission delay?
◦ What does affect this delay?
2

Road Map
• Last Session:
– Introduction and Overview
• Today:
– Basic Protocol Functions
– Protocols
– Application Layer
3

Network Architecture and Protocol Design
• The proliferation of proprietary network
protocols brought to the forefront the need for a
unified framework to enable communications in
a heterogeneous environment
• An architecture for protocol definition and
interaction between the different
communicating entities and components
– In 1984, The International Standard Organization
(ISO) formed a committee to achieve this goal
4

Layered Architecture
 The architecture is divided into multiple layers.
 Each layer performs a related subset of functions
required for communication, and adds value to the
services provided by lower layers.
◦ Layer N relies on services of layer N-1 to provide a service to
layer N+1
◦ Service required from lower layer is independent of how that
service is implemented
 Information and complexity hiding
 Changes in layer N do not affect other layers
5

What is a Protocol?
 A protocol is a set of mutually agreed upon rules that
regiment the interactions between the communicating peers.
◦ The key elements of a protocol are:
 Syntax – defines the structure of information communicated,
including the data format, the coding, and signal representations.
 Semantics – defines the meaning of the exchanged signals,
including control information for coordination and error handling.
 Timing – defines the time at which data should be exchanged.
 In Summary, the key elements of the protocol define:
◦ WHAT is comunicated,
◦ HOW it is communicated, and
◦ WHEN it is communicated.
6

What is interfaces?
• Boundaries between adjacent layers in the
same system are called interfaces
– Interface defines the interaction between
adjacent layers in the same system
7

Standardized Protocol Architectures
• Required for devices to communicate
• Vendors have more marketable products
• Two standards:
– OSI reference model
• Never lived up to early promise
– TCP/IP protocol suite
• Most widely used
8

TCP Protocol Stack
9
Application
Transport
Network
Link
Application Protocol
TCP, UDP Protocol
IP Protocol
Data
Link
IP
Network
Access
IP Protocol
Data
Link
Application
Transport
Network
Link
Transport layer provides ports, logical channels identified by number
Physical Physical

Basic Protocol Functions
• Encapsulation
• Fragmentation and reassembly
• Connection Control
• Ordered delivery
• Flow Control
• Error Control
• Addressing
• Multiplexing
• Transmission Services

Encapsulation
• Protocol Data Unit (PDU)
– Data from the next higher layer (payload)
– Control information (header)
• Address
• Error-detection code
• Protocol control
Encapsulation– the addition of control
information to data

Encapsulation
12
Application
Transport (TCP, UDP)
Network (IP)
Link Layer
Application Data Packet
TCP Data TCP Data TCP Data
Data
TCP
IP
Data
TCP
IP
LH LT
Segment
Datagram
Frame
Packet
Transport
Header
Transpo
rt PDU
Network
PDU
Link
PDU
Network
Header
Link
Header

Fragmentation & Reassembly
• Need to divide data block from a higher layer into
multiple smaller blocks.
• Why?
– Allowed maximum block size
– Efficient error control
– More equitable access to shared transmission, with shorter
delay.
– Early termination
• Cons
– Larger overhead
– More processing time

Road Map
15
Application
Transport (TCP, UDP)
Network (IP)
Link Layer

Applications Require:
 Reliability (e.g., mail, IM, FTP, … etc.)
 Bandwidth
◦ Bandwidth-sensitive applications
◦ Elastic applications
 Timing
16
 FTP: no loss / elastic / not time sensitive
 Email: no loss / elastic / not time sensitive
 Web documents: no loss / elastic / not time sensitive
 IM: no loss / elastic / relatively time-sensitive
 Real-Time A/V: loss-tolerant / requires BW(A: Kbps-1Mbps V:10Kbps-
5Mbps) / time sensitive (100msec)
 Stored A/V: loss-tolerant / requires BW(A: Kbps-1Mbps V:10Kbps-
5Mbps) / time sensitive (few seconds)
 Video gaming (interactive): loss-tolerant / requires Kbps-10Kbps) /
time sensitive (100msec)

2: Application Layer 17
Internet transport protocols services
TCP service:
• connection-oriented: setup
required between client and
server processes
• reliable transport between
sending and receiving process
• flow control: sender won’t
overwhelm receiver
• congestion control: throttle
sender when network
overloaded
• does not provide: timing,
minimum throughput
guarantees, security
UDP service:
• unreliable data transfer
between sending and
receiving process
• does not provide:
connection setup, reliability,
flow control, congestion
control, timing, throughput
guarantee, or security
Q: why bother? Why is there a
UDP?

Internet apps: application, transport protocols
Application
e-mail
remote terminal access
Web
file transfer
streaming multimedia
Internet telephony
Application
layer protocol
SMTP [RFC 2821]
Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
HTTP (eg Youtube),
RTP [RFC 1889]
SIP, RTP, proprietary
(e.g., Skype)
Underlying
transport protocol
TCP
TCP
TCP
TCP
TCP or UDP
typically UDP

Application architectures
• Client-server
• Peer-to-peer (P2P)
• Hybrid of client-server and P2P
19

Client-server architecture
server:
– always-on host
– permanent IP address
– server farms for scaling
– Manage resources
clients:
– communicate with server
– may be intermittently
connected
– may have dynamic IP
addresses
– do not communicate
directly with each other
– Clients rely on servers for
resources
20

Pure P2P architecture
• no always-on server
• arbitrary end systems directly
communicate
• peers are intermittently
connected and change IP
addresses
• example: Gnutella
Highly scalable but difficult to
manage
21

Hybrid of client-server and P2P
Skype
– Internet telephony app
– Finding address of remote party: centralized server(s)
– Client-client connection is direct (not through server)
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
22

Processes
• In any OS, processes communicate with each other
• A process is simply a program on an end system
• In a client-server architecture:
– A web browser process communicate with and exchanges
messages with a web server process
• DEF: a client is the process that initiates the communication with the
other process (server).
– This terminology is used in any architecture
• Each process has an ID (port number) while each end system has
an ID (IP address)
– Web server: port 80
– Mail server (SMTP): port 25
– … www.iana.org
23

Sockets
• A Process (house) receives and sends
messages through its socket (door)
• The socket is the interface between the
application layer and the transport layer (TCP or
UDP)
• Another name is the Application Programming
Interface (API)
• Socket Programming!!
24
Application-layer protocols are specified for same
applications to run on different end systems…

Sockets
• process sends/receives
messages to/from its
socket
• socket analogous to door
– sending process
shoves message out
door
– sending process
relies on transport
infrastructure on other
side of door which
brings message to
socket at receiving
process
25
process
TCP with
buffers,
variables
socket
host or
server
process
TCP with
buffers,
variables
socket
host or
server
Internet
controlled
by OS
controlled by
app developer
 API: (1) choice of transport protocol; (2) ability to fix a few
parameters (lots more on this later)

Socket programming with TCP
Client must contact server
• server process must first be
running
• server must have created
socket (door) that welcomes
client’s contact
Client contacts server by:
• creating client-local TCP
socket
• specifying IP address, port
number of server process
• When client creates socket:
client TCP establishes
connection to server TCP
• When contacted by client,
server TCP creates new
socket for server process to
communicate with client
– allows server to talk with
multiple clients
– source port numbers used
to distinguish clients
TCP provides reliable, in-order
transfer of bytes (“pipe”)
between client and server
application viewpoint

Client/server socket interaction: TCP
wait for incoming
connection request
connectionSocket =
welcomeSocket.accept()
create socket,
port=x, for
incoming request:
welcomeSocket =
ServerSocket()
create socket,
connect to hostid, port=x
clientSocket =
Socket()
close
connectionSocket
read reply from
clientSocket
close
clientSocket
Server (running on hostid) Client
send request using
clientSocket
read request from
connectionSocket
write reply to
connectionSocket
TCP
connection setup

outToServer
to network from network
inFromServer
inFromUser
keyboard monitor
Process
clientSocket
input
stream
input
stream
output
stream
TCP
socket
Client
process
client TCP
socket
Stream jargon
• A stream is a sequence of
characters that flow into or out
of a process.
• An input stream is attached to
some input source for the
process, e.g., keyboard or
socket.
• An output stream is attached to
an output source, e.g., monitor
or socket.

Socket programming with TCP
Example client-server app:
1) client reads line from standard
input (inFromUser stream) ,
sends to server via socket
(outToServer stream)
2) server reads line from socket
3) server converts line to
uppercase, sends back to client
4) client reads, prints modified line
from socket (inFromServer
stream)

Example: Java client (TCP)
import java.io.*;
import java.net.*;
class TCPClient {
public static void main(String argv[]) throws Exception
{
String sentence;
String modifiedSentence;
BufferedReader inFromUser =
new BufferedReader(new InputStreamReader(System.in));
Socket clientSocket = new Socket("hostname", 6789);
DataOutputStream outToServer =
new DataOutputStream(clientSocket.getOutputStream());
Create
input stream
Create
client socket,
connect to server
Create
output stream
attached to socket

Example: Java client (TCP), cont.
BufferedReader inFromServer =
new BufferedReader(new
InputStreamReader(clientSocket.getInputStream()));
sentence = inFromUser.readLine();
outToServer.writeBytes(sentence + 'n');
modifiedSentence = inFromServer.readLine();
System.out.println("FROM SERVER: " + modifiedSentence);
clientSocket.close();
}
}
Create
input stream
attached to socket
Send line
to server
Read line
from server

Example: Java server (TCP)
import java.io.*;
import java.net.*;
class TCPServer {
public static void main(String argv[]) throws Exception
{
String clientSentence;
String capitalizedSentence;
ServerSocket welcomeSocket = new ServerSocket(6789);
while(true) {
Socket connectionSocket = welcomeSocket.accept();
BufferedReader inFromClient =
new BufferedReader(new
InputStreamReader(connectionSocket.getInputStream()));
Create
welcoming socket
at port 6789
Wait, on welcoming
socket for contact
by client
Create input
stream, attached
to socket

Example: Java server (TCP), cont
DataOutputStream outToClient =
new DataOutputStream(connectionSocket.getOutputStream());
clientSentence = inFromClient.readLine();
capitalizedSentence = clientSentence.toUpperCase() + 'n';
outToClient.writeBytes(capitalizedSentence);
}
}
}
Read in line
from socket
Create output
stream, attached
to socket
Write out line
to socket
End of while loop,
loop back and wait for
another client connection

Addressing processes
• to receive messages, process must have identifier
• host device has unique 32-bit IP address
• Q: does IP address of host on which process runs suffice for
identifying the process?
34
 identifier includes both IP address and port numbers associated
with process on host.
 Example port numbers:
◦ HTTP server: 80
◦ Mail server: 25
 to send HTTP message to gaia.cs.umass.edu web server:
◦ IP address: 128.119.245.12
◦ Port number: 80
 more shortly…

HTTP
• HyperText Transfer Protocol
• A Web page (i.e., document) contains several objects (image, text, …
etc.)
• HTTP uses TCP
• Client-Server Architecture
35
www.someschool.edu/someDept/pic.gif
host name path name
PC running
Explorer
Server
running
Apache Web
server
Mac running
Navigator

HTTP Messages
• Connections:
• RTT and Reliability
• Nonpersistent
• Each TCP connection is closed after
the server sends the object
• So we will have many TCP
connections (most Web browsers
have a default of 5-10 parallel TCP
connections  serial connections?)
• Two RTT per object  delay
• Persistent:
• One connection for the whole file
between the client and the server
• The server shuts down the
connection if idle for sometime
• Pipelining (one RTT may be enough
for several objects) vs. no pipelining
(one RTT per object)
36
time to
transmit
file
initiate TCP
connection
RTT
request
file
RTT
file
received
time time

HTTP Request Message Format
GET /somedir/page.html HTTP/1.1
Host: www.cnn.com
Connection: close
User-agent: Mozilla/4.0
Accept-language: fr
37
Request
line
method
URL field
HTTP version
header lines

HTTP Request Message Format
• Methods:
– GET: most popular; it does not use the Entity
Body field
– POST: when the user fills a form such as
search engines; it uses the Entity Body field
– HEAD: same as GET but in general it is used
for debugging
– PUT: only in HTTP/1.1; for Web publishing
– DELETE: only in HTTP/1.1; to delete an
object from a Web server
38

HTTP Response Message Format
HTTP/1.1 200 OK
Connection: close
Date: Thu, 05 Jan 2006 02:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Sun, 01 Nov 2005 12:00:33 GMT
Content-Length: 6821
Content-Type: text/html
(data… the requested object itself … data …)
39
Status line
header lines
Entity Body
version Status code and phrase
Specifies the object type and not the file extension
Bytes

Example

Cookies
Used by servers to identify users for
both security reasons (blocking certain
users) or to serve different users
differently (more common).
Components:
◦ A header in the HTTP response message
◦ A header in the HTTP request message
◦ A cookie file kept on the user’s end system
and managed by the browser
◦ A back-end database at the Web site
41

Cookies: keeping “state” (cont.)
client server
usual http response msg
usual http response msg
cookie file
one week later:
usual http request msg
cookie: 1678 cookie-
specific
action
access
ebay 8734
usual http request msg Amazon server
creates ID
1678 for user create
entry
usual http response
Set-cookie: 1678
ebay 8734
amazon 1678
usual http request msg
cookie: 1678 cookie-
spectific
action
access
ebay 8734
amazon 1678
backend
database

Web Caching (proxy server)
• A network entity that
satisfies HTTP requests
on behalf of an origin
Web server
• It is a client and a server
at the same time
• Maintained by ISP
• Reduces response time
for clients
• Reduces the traffic on
the link between the
institution and the
Internet
43
client
Proxy
server
client
origin
server
origin
server

Caching example
Assumptions
• average object size = 100,000 bits
• avg. request rate from institution’s
browsers to origin servers = 15/sec
• delay from institutional router to any
origin server and back to router = 2
sec
Consequences
• utilization on LAN = 15%
• utilization on access link = 100%
• total delay = Internet delay + access
delay + LAN delay
= 2 sec + minutes + milliseconds
44
origin
servers
public
Internet
institutional
network
10 Mbps LAN
1.5 Mbps
access link
institutional
cache

Caching example (cont)
Possible solution
• increase bandwidth of access link
to, say, 10 Mbps
Consequences
• utilization on LAN = 15%
• utilization on access link = 15%
• Total delay = Internet delay + access
delay + LAN delay
= 2 sec + msecs + msecs
• often a costly upgrade
45
origin
servers
public
Internet
institutional
network
10 Mbps LAN
10 Mbps
access link
institutional
cache

Caching example (cont)
Install cache
• suppose hit rate is .4
Consequence
• 40% requests will be satisfied
almost immediately
• 60% requests satisfied by origin
server
• utilization of access link reduced to
60%, resulting in negligible delays
(say 10 msec)
• total avg delay = Internet delay +
access delay + LAN delay + cache
access delay = .6*(2.01) secs +
.4*milliseconds < 1.4 secs
46
origin
servers
public
Internet
institutional
network
10 Mbps LAN
1.5 Mbps
access link
institutional
cache

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

Server Push and Client Pull
• Server push idea:
– The server sends a chunk
of data.
– The browser displays the
data, but leaves the
connection open.
– The server sends more
data whenever it wants and
the browser displays it,
always leaving the
connection open.
• Client pull idea
– The server sends data,
including a command that
says "reload this data in 5
seconds", or "go load this
other URL in 10 seconds”.
– After the specified time has
elapsed, the client either
reloads the current data or
gets the new data.

Client Pull
• For example, name the following
document doc1.html and try loading it in
a web browser:
<HTML><HEAD>
<META HTTP-EQUIV="Refresh" CONTENT=1>
<title>Document ONE</title>
</HEAD><BODY>
<h1>Bill is great!</h1>
</BODY></HTML>
• You will notice that the document reloads
itself once a second.

FTP: File Transfer Protocol
• 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
50
file transfer
FTP
server
FTP
user
interface
FTP
client
local file
system
remote file
system
user
at host

FTP: separate control, data connections
• 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 file
transfer command, server
opens 2nd TCP connection (for
file) to client
• After transferring one file,
server closes data connection.
51
FTP
client
FTP
server
TCP control connection
port 21
TCP data connection
port 20
 Server opens another TCP data
connection to transfer another file.
 Control connection: “out of band”
 FTP server maintains “state”:
current directory, earlier
authentication

FTP commands, responses
Sample commands:
• sent as ASCII text over control
channel
• USER username
• PASS password
• LIST return list of file in current
directory
• RETR filename retrieves (gets)
file
• STOR filename stores (puts) file
onto remote host
Sample return codes
• status code and phrase (as in
HTTP)
• 331 Username OK, password
required
• 125 data connection
already open; transfer
starting
• 425 Can’t open data
connection
• 452 Error writing file
52

Electronic Mail
Three major components:
• user agents
• mail servers
• simple mail transfer protocol: SMTP
User Agent
• a.k.a. “mail reader”
• composing, editing, reading mail
messages
• e.g., Pine, Elm, Outlook, Netscape
Messenger
• outgoing, incoming messages
stored on server
53
user mailbox
outgoing
message queue
mail
server
user
agent
user
agent
user
agent
mail
server
user
agent
user
agent
mail
server
user
agent
SMTP
SMTP
SMTP

Electronic Mail: mail servers
Mail Servers
• mailbox contains incoming
messages for user
• message queue of outgoing (to be
sent) mail messages
• SMTP protocol between mail
servers to send email messages
– client: sending mail server
– “server”: receiving mail
server
54
mail
server
user
agent
user
agent
user
agent
mail
server
user
agent
user
agent
mail
server
user
agent
SMTP
SMTP
SMTP

Electronic Mail: SMTP
[RFC 821;2821;5321]
• 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
55

Sample SMTP interaction
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection

SMTP Replies
• positive completion reply (2xx)
– e.g. 220 <domain> Service ready
– e.g. 250 Requested mail action okay, completed
• positive intermediate reply (3xx)
– e.g. 354 Start mail input; end with <CRLF>.<CRLF>
• transient negative completion reply (4xx)
– e.g. 452 Requested action not taken: insufficient system
storage
• permanent negative completion reply (5xx)
– e.g. 500 Syntax error, command unrecognized
– e.g. 550 Requested action not taken: mailbox unavailable
(e.g., mailbox not found, no access)

Scenario: Alice sends message to Bob
1) Alice uses UA to compose
message and “to”
bob@someschool.edu
2) Alice’s UA sends message to
her mail server; message
placed in message queue
3) Client side of SMTP opens
TCP connection with Bob’s
mail server
4) SMTP client sends Alice’s
message over the TCP
connection
5) Bob’s mail server places the
message in Bob’s mailbox
6) Bob invokes his user agent to
read message
58
user
agent
mail
server
mail
server user
agent
1
2 3 4 5
6

SMTP: final words
• SMTP uses persistent
connections
• SMTP requires message
(header & body) to be in
7-bit ASCII
• SMTP server uses
CRLF.CRLF to determine
end of message
Comparison with HTTP:
• HTTP: pull
• SMTP: push
• both have ASCII
command/response
interaction, status codes
• HTTP: each object
encapsulated in its own
response msg
• SMTP: multiple objects sent in
multipart msg
59

Mail message format
• RFC 822: standard for text
message format:
• Envelope
• Content
• Envelope contains information
required to transmit and deliver
message
• Content
– header lines, e.g.,
• To:
• From:
• Subject:
different from SMTP commands!
– body
• the “message”, ASCII (7-bits)
characters only
61
header
body
blank
line
Envelop
Content

Mail message format
• RFC 822: standard for text message
format
– Envelope
– Content
• Envelope contains information required
to transmit and deliver message
– Commands, e.g.,
• MAIL FROM:
• RCPT TO:
• Content
– header lines, e.g.,
• To:
• From:
• Subject:
different from SMTP commands!
– body
• the “message”, ASCII (7-bits)
characters only
62
header
body
blank
line
Envelop
Content

SMTP limitations
• Cannot transmit:
– Executable files (binary)
– Language characters with 8-bit
• e.g. â, å, ä, è, é, ê, ë
– Messages over a certain size
– Nontextual data
– Multiple files

Non- ASCII Header
• Header can contain encoded words
=? charset ? encoding ? encoded-text ?=
From: =?US-ASCII?Q?Keith_Moore?= <moore@cs.utk.edu>
To:=?ISO-8859-1?Q?Keld_j=F8rn_Sim?= <test@gmail.com>
Subject:=?ISO-8859-
1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?==?ISO-8859-
2?B?dSB1bmR1cnN0YW5kIHRoZSBleGFtcGxlLg==?=

Multimedia Mail Extensions
• MIME: Multipurpose Internet Mail Extensions (RFC 2045, 2056)
• Used by the user mail agent in the header to send multiple non-
ASCII messages
• Five new header fields
Mime-Version:
Content-Type: type/subtype
For user agent to pick an appropriate agent to present the data
Content-Transfer-Encoding:
Indicates the type of transformation that has been used to
represent the body of the messages in a way that is acceptable for
mail transport
Content-ID:
Uniquely Identifies MIME entities in multiple contexts
Content-Description:
A plaintext description of the object with the body
65

Multimedia Mail Extensions
66
Return-Path: <ece3076-
bounces@gtrep.gatech.edu>
From: "Ghassan AlRegib"
<gregib@ece.gatech.edu>
To: <ece3076@gtrep.gatech.edu>
Date: Tue, 24 Jan 2006 16:11:51 -0500
Message-ID:
<00d201c6212a$ceef7360$b5ac14a8@Serwal
>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----
=_NextPart_000_00D3_01C62100.E6196B60"
X-Mailer: Microsoft Office Outlook 11
MIME version
multimedia data
type, subtype,
parameter declaration

Multipart MIME Example
From: John Smith <js@company.com>
To: Ned Jones <ned@soft.com>
Subject: Sample message
MIME-Version: 1.0
Content-type: multipart/alternative; boundary="simple boundary"
--simple boundary
Content-Type: text/plain; charset=us-ascii
This is the preamble. It is to be ignored, though it is a handy place for mail composers
to include an explanatory note to non-MIME conformant readers.
--simple boundary
Content-Type: text/richtext
This is implicitly typed plain ASCII text. It does NOT end with a linebreak.
--simple boundary

Message format: multimedia extensions
68
From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
multimedia data
type, subtype,
parameter declaration
method used
to encode data
MIME version
encoded data

Mail access protocols
 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 msgs on server
◦ HTTP: Hotmail , Yahoo! Mail, etc.
69
user
agent
sender’s mail
server
user
agent
SMTP SMTP access
protocol
receiver’s mail
server

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

POP3 (more) and IMAP
More about POP3
• Previous example uses
“download and delete”
mode.
• Bob cannot re-read e-mail if
he changes client
• “Download-and-keep”:
copies of messages on
different clients
• POP3 is stateless across
sessions
IMAP
• Keep all messages in one
place: the server
• Allows user to organize
messages in folders
• IMAP keeps user state
across sessions:
– names of folders and
mappings between
message IDs and folder
name
71

Web-Based Mail
• Messages are sent using HTTP between
the browser and the mail server
• SMTP is still used between mail servers
72
Web
Browser
sender’s mail
server
Web
browser
HTTP SMTP HTTP
receiver’s mail
server

DNS: Domain Name System
Domain Name System:
• distributed database implemented in hierarchy of
many name servers
• application-layer protocol host, routers, name
servers to communicate to resolve names
(address/name translation)
• Hostname to IP address translation
• Host aliasing
– Canonical and alias names
• Mail server aliasing
• Load distribution
– Replicated Web servers:
set of IP addresses for one canonical name
73
Why not centralize DNS?
 single point of failure
 traffic volume
 distant centralized
database
 Maintenance
doesn’t scale!

Distributed, Hierarchical Database
Client wants IP for www.amazon.com; 1st approx:
• Client queries a root server to find com DNS server
• Client queries com DNS server to get amazon.com DNS
server
• Client queries amazon.com DNS server to get IP
address for www.amazon.com
74
Root DNS Servers
com DNS servers org DNS servers edu DNS servers
poly.edu
DNS servers
umass.edu
DNS servers
yahoo.com
DNS servers
amazon.com
DNS servers
pbs.org
DNS servers

DNS: Root name servers
• contacted by local name server that can not resolve name
• root name server:
– contacts authoritative name server if name mapping not
known
– gets mapping
– returns mapping to local name server
75
13 root name
servers worldwide
b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA
e NASA Mt View, CA
f Internet Software C. Palo
Alto, CA (and 17 other locations)
i Autonomica, Stockholm (plus
3 other locations)
k RIPE London (also Amsterdam,
Frankfurt)
m WIDE Tokyo
a Verisign, Dulles, VA
c Cogent, Herndon, VA (also Los
Angeles)
d U Maryland College Park, MD
g US DoD Vienna, VA
h ARL Aberdeen, MD
j Verisign, ( 11 locations)

TLD and Authoritative Servers
 Top-level domain (TLD) servers: responsible
for com, org, net, edu, etc, and all top-level
country domains uk, fr, ca, jp.
◦ Network solutions maintains servers for com TLD
 Authoritative DNS servers: organization’s
DNS servers, providing authoritative
hostname to IP mappings for organization’s
servers (e.g., Web and mail).
◦ Can be maintained by organization or service
provider
76

Local Name Server
• Does not strictly belong to hierarchy
• Each ISP (residential ISP, company,
university) has one.
– Also called “default name server”
• When a host makes a DNS query, query is
sent to its local DNS server
– Acts as a proxy, forwards query into
hierarchy.
77

Example
• Host at cis.poly.edu wants
IP address for
gaia.cs.umass.edu
78
requesting host
cis.poly.edu
gaia.cs.umass.edu
root DNS server
local DNS server
dns.poly.edu
1
2
3
4
5
6
authoritative DNS server
dns.cs.umass.edu
7
8
TLD DNS server
iterated query:
 contacted server
replies with name of
server to contact
 “I don’t know this
name, but ask this
server”

Recursive queries
79
requesting host
cis.poly.edu
gaia.cs.umass.edu
root DNS server
local DNS server
dns.poly.edu
1
2
4
5
6
authoritative DNS server
dns.cs.umass.edu
7
8
TLD DNS server
3
recursive query:
 puts burden of name
resolution on contacted
name server
 heavy load?

DNS records
DNS: distributed db storing resource records (RR)
• Type=NS
– name is domain (e.g.
foo.com)
– value is hostname of
authoritative name server
for this domain
RR format: (name, value, type, ttl)
 Type=A
 name is hostname
 value is IP address
 Type=CNAME
 name is alias name for some
“canonical” (the real) name
www.ibm.com is really
servereast.backup2.ibm.com
 value is canonical name
 Type=MX
 value is name of mailserver
associated with name

Inserting records into DNS
• example: new startup “Network Utopia”
• register name networkuptopia.com at DNS registrar
(e.g., Network Solutions)
– provide names, IP addresses of authoritative name server
(primary and secondary)
– registrar inserts two RRs into com TLD server:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
• create authoritative server Type A record for
www.networkuptopia.com; Type MX record for
networkutopia.com
• How do people get IP address of your Web site?

Example
Stored in dns.sc.edu
engr.sc.edu ttl NS dns.engr.sc.edu
dns.engr.sc.edu ttl A 129.252.130.10
Stored in dns.engr.sc.edu
Flits.engr.sc.edu ttl A 129.252.130.110
www.engr.sc.edu ttl CNAME dilbert.engr.sc.edu
dilbert.engr.sc.edu ttl A 129.252.21.8
engr.sc.edu ttl MX hub0.engr.sc.edu
hub0.engr.sc.edu ttl A 129.252.21.22
…..

P2P file sharing
Example
• Alice runs P2P client
application on her notebook
computer
• Intermittently connects to
Internet; gets new IP address
for each connection
• Asks for “Hey Jude”
• Application displays other
peers that have copy of Hey
Jude.
• Alice chooses one of the
peers, Bob.
• File is copied from Bob’s PC
to Alice’s notebook: HTTP
• While Alice downloads, other
users uploading from Alice.
• Alice’s peer is both a Web
client and a transient Web
server.
All peers are servers = highly
scalable!
83

P2P: centralized directory
original “Napster” design
1) when peer connects, it
informs central server:
– IP address
– content
2) Alice queries for “Hey
Jude”
3) Alice requests file from Bob
84
centralized
directory server
peers
Alice
Bob
1
1
1
1
2
3

File distribution: BitTorrent
tracker: tracks peers
participating in torrent
torrent: group of
peers exchanging
chunks of a file
obtain list
of peers
trading
chunks
peer
 P2P file distribution

BitTorrent (1)
• file divided into 256KB chunks.
• peer joining torrent:
– has no chunks, but will accumulate them over time
– registers with tracker to get list of peers, connects to
subset of peers (“neighbors”)
• while downloading, peer uploads chunks to other
peers.
• peers may come and go
• once peer has entire file, it may (selfishly) leave or
(altruistically) remain

BitTorrent (2)
Pulling Chunks
• at any given time, different
peers have different subsets of
file chunks
• periodically, a peer (Alice)
asks each neighbor for list of
chunks that they have.
• Alice sends requests for her
missing chunks
– rarest first
Sending Chunks: tit-for-tat
 Alice sends chunks to 4
neighbors currently
sending her chunks at the
highest rate
 re-evaluate top 4 every 10
secs
 every 30 secs: randomly
select another peer, starts
sending chunks
 newly chosen peer may
join top 4
 “optimistically unchoke”

BitTorrent: Tit-for-tat
(1) Alice “optimistically unchokes” Bob
(2) Alice becomes one of Bob’s top-four providers; Bob reciprocates
(3) Bob becomes one of Alice’s top-four providers
With higher upload rate,
can find better trading
partners & get file faster!

P2P: problems with centralized
directory
• Single point of failure
• Performance bottleneck
• Copyright infringement
file transfer is
decentralized, but locating
content is highly
centralized
89

Query flooding: Gnutella
• fully distributed
– no central server
• public domain protocol
• many Gnutella clients
implementing protocol
overlay network: graph
• edge between peer X and Y if
there’s a TCP connection
• all active peers and edges is
overlay net
• Edge is not a physical link
• Given peer will typically be
connected with < 10 overlay
neighbors
90

Gnutella: protocol
91
Query
QueryHit
Query
QueryHit
File transfer:
HTTP
- Query message sent
over existing TCP
connections
- peers forward Query
message
- QueryHit sent over
reverse path
Scalability: limited scope flooding

Exploiting heterogeneity: KaZaA
• Each peer is either a group
leader or assigned to a group
leader.
– TCP connection between
peer and its group leader.
– TCP connections between
some pairs of group leaders.
• Group leader tracks the content
in all its children.
92
ordinary peer
group-leader peer
neighoring relationships
in overlay network

KaZaA: Querying
• Client sends keyword query to its group
leader
• Group leader responds with matches
• 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
93

Summary
Reading: Chapter 25 (online)
 Data communications
◦ Point-to-point data transmission
◦ Five-component model
 Networking
◦ Networked data communications
◦ Circuit switching/Packet switching/Frame relay/ATM
◦ WAN/LAN/MAN
 What is the importance of protocol architecture?
 What is a PDU?
 Application Layer:
 HTTP
 E-mail
 DNS
 P2P
94

Datacom_Section_2_-_Protocols.ppt

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Datacom_Section_2_-_Protocols.ppt

Ähnlich wie Datacom_Section_2_-_Protocols.ppt (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Datacom_Section_2_-_Protocols.ppt