3rd Edition: Chapter 2

Download Report

Transcript 3rd Edition: Chapter 2

Network Taxonomy
Telecommunication
networks
Circuit-switched
networks
FDM
4/12/05
TDM
Packet-switched
networks
Networks
with VCs
Datagram
Networks
 A circuit-switched network
• Requires circuit setup before data transmission
• Allocates a precise, fixed amount of bandwidth to each circuit
 A packet-switched network is not either connection-oriented or
connectionless
• Virtual-circuit network: also requires a setup phase
• Datagram network: hosts can send
at any time
1
CS118
Internet structure: network of networks
 a packet passes through many networks!
local
ISP
Tier 3
ISP
Tier-2 ISP
local
ISP
local
ISP
local
ISP
Tier-2 ISP
Tier 1 ISP
Tier 1 ISP
Tier 1 ISP
Tier-2 ISP
local
local
ISP
ISP
4/12/05
NAP
Tier-2 ISP
local
ISP
2
Tier-2 ISP
local
ISP
CS118
Protocol layering and data
 Each layer takes data from above
 adds a header to create a new data unit
 passes the new data unit to the layer below
source
data application
Ht data transport
network
Hn Ht data
link
data
Hl Hn Ht
physical
4/12/05
destination
data message
application
transport
Ht data segment
network
Hn Ht data datagram
link
Hl Hn Ht data frame
physical
3
CS118
Protocol header: one examples
Link layer: Ethernet frame format
destination source
address
address
data …
type
header
error
checking
code
trailer
application
transport
network
link
physical
4/12/05
4
CS118
Data Delivery Performance
 3 basic measurements
 Delay (sec, msec)
 Throughput (bits/sec)
 Loss rate (% of packets lost)
 measure at different points  different results
End-to-end
server
my
computer
Hop-by-hop
4/12/05
5
CS118
Packet Losses
 Loss due to congestion
 Loss due to transmission
errors
 wireless links
Limited transmission rate
 Higher bit error rate
 Hosts mobility: high variance
in the number of hosts being
served

4/12/05
6
CS118
Throughput
 Throughput over a single link
 Point-to-point
• Pumping data to the pipe: link bandwidth
• Enhance the transmission with error detection
and retransmission

Multi-access
 Throughput between two end hosts
4/12/05
7
CS118
Delay in packet-switched networks
4 sources of delay at each hop
 nodal processing:


 Transmission = L / R
 R = link bandwidth (bps)
 L = packet length (bits)
 Propagation = d/s
 d = length of physical link
 s = propagation speed in medium
(~2x108 m/sec)
check bit errors
determine output link
 Queueing = #packets in queue
X transmission time
of each packet
transmission
A
propagation
B
4/12/05
C
nodal
processing
queueing
8
CS118
Example: one hop delay
total delay (AB) = ?1ms  2 1ms  0.5ms  3.5ms
 Queuing delay =
Waiting time for 2 pkts
 transmission delay =
 Propagation delay =
link length = 100 km
Bandwidth= 1 Mbps
packet size= 1000 bits
(all pkts equal length)
1000bits

1000000bits / sec
1 msec
100,000m
0.5 msec
8
2  10 m / sec
Switch A
Switch B
(2.0x10^8 meters/sec in a fiber)
4/12/05
9
CS118
Network latency
 Time to send a packet from point A to point B
 sum of delays across each hop along the path
Delay A B  Delay A1  Delay12  Delay 23  Delay 3 B
 RTT: round-trip-time
RTTAB  Delay AB  Delay B A
2
1
A
4/12/05
3
B
10
CS118
Packet-switching: store-and-forward
L
R
 Takes L/R seconds to
transmit (push out) packet
of L bits on to link of R bps
 Entire packet must arrive at
router before it can be
transmitted on next link:
store and forward
 Ignore propagation delay
4/12/05
R
R
Example:
 L = 8000 bits (1000bytes)
 R = 2 Mbps
 delay = 3L/R = 12 msec
11
CS118
Packet-switching: store-and-forward
321
R
R
Example 2:
 A sends 5 packets to B
T=0  L = 8000 bits, R = 2 Mbps
R

32
1
3
2
1
4
3
2
1
5
4
3
21
5
4
5
Ignore propagation delay
L/R  How long does it take starting from A
sending the first bit of first packet till B
2L/R receives the last bit of the last packet?
3L/R
4L/R
321 5L/R
21
3
4 6L/R
21
3
4 7L/R
5
4/12/05
time12
CS118
Bandwidth, transmission delay, and
propagation delay
bandwidth
10Mbps
20Mbps
time
(bandwidth  delay) product: amount of data "in-the-pipe"
Propagation delay= 10ms
Bandwidth= 1 Gbps
4/12/05
125KB data in the pipe
13
CS118
Chapter 2: Application layer
 2.1 Principles of network
applications
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail

SMTP, POP3, IMAP
 2.5 DNS
4/12/05
 2.6 P2P file sharing
 2.7 Socket programming
with TCP
 2.8 Socket programming
with UDP
 2.9 Building a Web server
14
CS118
Chapter 2: Application Layer
Our goals:
 conceptual, implementation
aspects of network
application protocols
 transport-layer service
models
 client-server paradigm

 learn about protocols by
examining popular
application-level
protocols



peer-to-peer paradigm

HTTP
FTP
SMTP / POP3 / IMAP
DNS
 programming network
applications

4/12/05
15
socket API
CS118
Some network apps
 E-mail
 Internet telephone
 Web
 Real-time video
 Instant messaging
conference
 Massive parallel
computing
 Remote login
 P2P file sharing
 Multi-user network games
 Streaming stored video
clips
4/12/05



16
CS118
Creating a network app
application
transport
network
data link
physical
Write programs that



run on different end systems
and
communicate over a network.
e.g., Web: Web server software
communicates with browser
software
little software written for
devices in network core


4/12/05
network core devices do not run
user application code
application on end systems
allows for rapid app
development, propagation
17
application
transport
network
data link
physical
application
transport
network
data link
physical
CS118
Chapter 2: Application layer
 2.1 Principles of network
applications
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail

SMTP, POP3, IMAP
 2.5 DNS
4/12/05
 2.6 P2P file sharing
 2.7 Socket programming
with TCP
 2.8 Socket programming
with UDP
 2.9 Building a Web server
18
CS118
Application architectures
 Client-server
 Peer-to-peer (P2P)
 Hybrid of client-server and P2P
4/12/05
19
CS118
Client-server architecture
server:



always-on host
permanent IP address
server farms for scaling
clients:




4/12/05
20
communicate with server
may be intermittently
connected
may have dynamic IP
addresses
do not communicate
directly with each other
CS118
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
4/12/05
21
CS118
Hybrid of 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
4/12/05
22
CS118
Processes communicating
Client process: process that
initiates communication
Server process: process that waits
to be contacted
Process: program running
within a host.
 within same host, two
processes communicate
using inter-process
communication (defined by
OS).
 processes in different hosts
communicate by
exchanging messages
4/12/05
 Note: applications with P2P
architectures have client
processes & server
processes
23
CS118
Sockets
 process sends/receives
messages to/from its socket
 socket analogous to door


host or
server
host or
server
process
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
controlled by
app developer
process
socket
socket
TCP with
buffers,
variables
Internet
TCP with
buffers,
variables
controlled
by OS
 API: (1) choice of transport protocol; (2) ability to fix a few
parameters (lots more on this later)
4/12/05
24
CS118
Addressing processes
4/12/05
 For a process to receive
 Identifier includes both the
messages, it must have an
identifier
 A host has a unique32-bit
IP address
 Q: does the IP address of
the host on which the
process runs suffice for
identifying the process?
 Answer: No, many
processes can be running
on same host
IP address and port
numbers associated with
the process on the host.
 Example port numbers:


HTTP server: 80
Mail server: 25
 More on this later
25
CS118
App-layer protocol defines
 Types of messages
Public-domain protocols:
 defined in RFCs
 allows for interoperability
 e.g., HTTP, SMTP
Proprietary protocols:
 e.g., KaZaA
exchanged, e.g., request &
response messages
 Syntax of message types:
what fields in messages &
how fields are delineated
 Semantics of the fields, i.e.,
meaning of information in
fields
 Rules for when and how
processes send & respond
to messages
4/12/05
26
CS118
What transport service does an app need?
Data loss
 some apps (e.g., audio) can
tolerate some loss
 other apps (e.g., file transfer,
telnet) require 100% reliable
data transfer
Bandwidth
 some apps (e.g.,
multimedia) require
minimum amount of
bandwidth to be
“effective”
 other apps (“elastic apps”)
make use of whatever
bandwidth they get
Timing
 some apps (e.g., Internet
telephony, interactive
games) require low delay
to be “effective”
4/12/05
27
CS118
Transport service requirements of common apps
Data loss
Bandwidth
Time Sensitive
file transfer
e-mail
Web documents
real-time audio/video
no loss
no loss
no loss
loss-tolerant
no
no
no
yes, 100’s msec
stored audio/video
interactive games
instant messaging
loss-tolerant
loss-tolerant
no loss
elastic
elastic
elastic
audio: 5kbps-1Mbps
video:10kbps-5Mbps
same as above
few kbps up
elastic
Application
4/12/05
28
yes, few secs
yes, 100’s msec
yes and no
CS118
Internet transport protocols services
TCP service:
UDP service:
 connection-oriented: setup




4/12/05
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 bandwidth guarantees
29
 unreliable data transfer
between sending and receiving
process
 does not provide: connection
setup, reliability, flow control,
congestion control, timing, or
bandwidth guarantee
Q: why bother? Why is there a
UDP?
CS118
Internet apps: application, transport protocols
Application
e-mail
remote terminal access
Web
file transfer
streaming multimedia
Internet telephony
4/12/05
Application
layer protocol
Underlying
transport protocol
SMTP [RFC 2821]
Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
proprietary
(e.g. RealNetworks)
proprietary
(e.g., Vonage,Dialpad)
TCP
TCP
TCP
TCP
TCP or UDP
30
typically UDP
CS118
Chapter 2: Application layer
 2.1 Principles of network
applications


app architectures
app requirements
 2.2 Web and HTTP
 2.4 Electronic Mail
 SMTP, POP3, IMAP
 2.6 P2P file sharing
 2.7 Socket programming
with TCP
 2.8 Socket programming
with UDP
 2.9 Building a Web server
 2.5 DNS
4/12/05
31
CS118
Web and HTTP
First some jargon
 Web page consists of objects
 Object can be HTML file, JPEG image, Java
applet, audio file,…
 Web page consists of base HTML-file which
includes several referenced objects
 Each object is addressable by a URL
 Example URL:
www.someschool.edu/someDept/pic.gif
path name
host name
4/12/05
32
CS118
HTTP overview
HTTP: hypertext transfer
protocol
 Web’s application layer
PC running
Explorer
protocol
 client/server model
 client: browser that
requests, receives,
“displays” Web objects
 server: Web server sends
objects in response to
requests
 HTTP 1.0: RFC 1945
 HTTP 1.1: RFC 2068
4/12/05
Server
running
Apache Web
server
Mac running
Navigator
33
CS118
HTTP overview (continued)
Uses TCP:
HTTP is “stateless”
 client initiates TCP connection
 server maintains no
(creates socket) to server, port 80
 server accepts TCP connection
from client
 HTTP messages (applicationlayer protocol messages)
exchanged between browser
(HTTP client) and Web server
(HTTP server)
 TCP connection closed
4/12/05
information about past
client requests
aside
Protocols that maintain “state” are
complex!
 past history (state) must be
maintained
 if server/client crashes, their
views of “state” may be
inconsistent, must be
reconciled
34
CS118
HTTP connections
Nonpersistent HTTP
 At most one object is sent
over a TCP connection.
 HTTP/1.0 uses
nonpersistent HTTP
4/12/05
Persistent HTTP
 Multiple objects can be
sent over single TCP
connection between client
and server.
 HTTP/1.1 uses persistent
connections in default
mode
35
CS118
Nonpersistent HTTP
(contains text,
references to 10
www.someSchool.edu/someDepartment/home.index
jpeg images)
1a. HTTP client initiates TCP
connection to HTTP server (process)
at www.someSchool.edu on port
1b. HTTP server at host
80
www.someSchool.edu waiting
for TCP connection at port 80.
“accepts” connection, notifying
client
2. HTTP client sends HTTP request
message (containing URL) into
TCP connection socket. Message
3. HTTP server receives request
indicates that client wants object
message, forms response message
someDepartment/home.index
containing requested object, and
Suppose user enters URL
sends message into its socket
time
4/12/05
36
CS118
Nonpersistent HTTP (cont.)
4. HTTP server closes TCP
5. HTTP client receives response
time
connection.
message containing html file,
displays html. Parsing html
file, finds 10 referenced jpeg
objects
6. Steps 1-5 repeated for each of 10
jpeg objects
4/12/05
37
CS118
Response time modeling
Definition of RRT: time to send a
small packet to travel from client
to server and back.
Response time:
 one RTT to initiate TCP
connection
 one RTT for HTTP request and
first few bytes of HTTP response
to return
 file transmission time
total = 2RTT+transmit time
initiate TCP
connection
RTT
request
file
time to
transmit
file
RTT
file
received
time
4/12/05
38
time
CS118
Persistent HTTP
Persistent without pipelining:
 client issues new request only
when previous response has
been received
 one RTT for each referenced
object
Persistent with pipelining:
 default in HTTP/1.1
 client sends requests as soon as
it encounters a referenced
object
 as little as one RTT for all the
referenced objects
Nonpersistent HTTP issues:
 requires 2 RTTs per object
 OS overhead for each TCP
connection
 browsers often open parallel TCP
connections to fetch referenced
objects
Persistent HTTP
 server leaves connection open
after sending response
 subsequent HTTP messages
between same client/server sent
over open connection
4/12/05
39
CS118
HTTP request message
 two types of HTTP messages: request, response
 HTTP request message:
 ASCII (human-readable format)
request line
(GET, POST,
HEAD commands)
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
User-agent: Mozilla/4.0
header Connection: close
lines Accept-language:fr
Carriage return,
line feed
indicates end
of message
4/12/05
(extra carriage return, line feed)
40
CS118
HTTP request message: general format
4/12/05
41
CS118
Uploading form input
Post method:
 Web page often includes
form input
 Input is uploaded to server
in entity body
URL method:
 Uses GET method
 Input is uploaded in URL
field of request line:
www.somesite.com/animalsearch?monkeys&banana
4/12/05
42
CS118
Method types
HTTP/1.0
 GET
 POST
 HEAD

4/12/05
asks server to leave
requested object out of
response
HTTP/1.1
 GET, POST, HEAD
 PUT

uploads file in entity body
to path specified in URL
field
 DELETE
 deletes file specified in the
URL field
43
CS118
HTTP response message
status line
(protocol
status code
status phrase)
header
lines
data, e.g.,
requested
HTML file
4/12/05
HTTP/1.1 200 OK
Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html
data data data data data ...
44
CS118
HTTP response status codes
In first line in server->client response message.
A few sample codes:
200 OK

request succeeded, requested object later in this message
301 Moved Permanently

requested object moved, new location specified later in this message
(Location:)
400 Bad Request

request message not understood by server
404 Not Found

requested document not found on this server
505 HTTP Version Not Supported
4/12/05
45
CS118
Trying out HTTP (client side) for yourself
1. Telnet to your favorite Web server:
telnet cis.poly.edu 80
Opens TCP connection to port 80
(default HTTP server port) at cis.poly.edu.
Anything typed in sent
to port 80 at cis.poly.edu
2. Type in a GET HTTP request:
By typing this in (hit carriage
return twice), you send
this minimal (but complete)
GET request to HTTP server
GET /~ross/ HTTP/1.1
Host: cis.poly.edu
3. Look at response message sent by HTTP server!
4/12/05
46
CS118
User-server state: cookies
Many major Web sites use
cookies
Four components:
Example:


1) cookie header line of HTTP
response message
2) cookie header line in HTTP
request message
3) cookie file kept on user’s
host, managed by user’s
browser
4) back-end database at Web
site
4/12/05

47
Susan access Internet
always from same PC
She visits a specific ecommerce site for first time
When initial HTTP requests
arrives at site, site creates a
unique ID and creates an
entry in backend database
for ID
CS118
Cookies: keeping “state” (cont.)
client
Cookie file
server
usual http request msg
usual http response +
ebay: 8734
Cookie file
amazon: 1678
ebay: 8734
Set-cookie: 1678
usual http request msg
cookie: 1678
usual http response msg
one week later:
Cookie file
amazon: 1678
ebay: 8734
4/12/05
usual http request msg
cookie: 1678
usual http response msg
48
server
creates ID
1678 for user
cookiespecific
action
cookiespectific
action
CS118
Cookies (continued)
aside
Cookies and privacy:
 cookies permit sites to
learn a lot about you
 you may supply name and
e-mail to sites
 search engines use
redirection & cookies to
learn yet more
 advertising companies
obtain info across sites
What cookies can bring:
 authorization
 shopping carts
 recommendations
 user session state (Web email)
4/12/05
49
CS118
Web caches (proxy server)
Goal: satisfy client request without involving origin server
origin
server
 user sets browser: Web
accesses via cache
 browser sends all HTTP
requests to cache


4/12/05
object in cache: cache
returns object
else cache requests object
from origin server, then
returns object to client
client
client
50
Proxy
server
origin
server
CS118
More about Web caching
 Cache acts as both client and
server
 Typically cache is installed by
ISP (university, company,
residential ISP)
4/12/05
Why Web caching?
 Reduce response time for
client request.
 Reduce traffic on an
institution’s access link.
 Internet dense with caches
enables “poor” content
providers to effectively
deliver content (but so
does P2P file sharing)
51
CS118
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%
origin
servers
public
Internet
1.5 Mbps
access link
institutional
network
 utilization on access link = 100%
 total delay = Internet delay + access
10 Mbps LAN
delay + LAN delay
= 2 sec + minutes + milliseconds
institutional
cache
4/12/05
52
CS118
Caching example (cont)
Possible solution
 increase bandwidth of access
link to, say, 10 Mbps
Consequences
origin
servers
public
Internet
 utilization on LAN = 15%
 utilization on access link = 15%
10 Mbps
access link
 Total delay = Internet delay +
access delay + LAN delay
= 2 sec + msecs + msecs
 often a costly upgrade
institutional
network
10 Mbps LAN
institutional
cache
4/12/05
53
CS118
Caching example (cont)
origin
servers
Install cache
 suppose hit rate is .4
public
Internet
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 =
.6*(2.01) secs + milliseconds <
1.4 secs
1.5 Mbps
access link
institutional
network
10 Mbps LAN
institutional
cache
4/12/05
54
CS118
Conditional GET
 Goal: don’t send object if cache
server
cache
HTTP request msg
has up-to-date cached version
 cache: specify date of cached
copy in HTTP request
If-modified-since:
<date>
If-modified-since:
<date>
HTTP response
object
not
modified
HTTP/1.0
304 Not Modified
 server: response contains no
object if cached copy is up-todate:
HTTP request msg
HTTP/1.0 304 Not
Modified
If-modified-since:
<date>
HTTP response
object
modified
HTTP/1.0 200 OK
<data>
4/12/05
55
CS118
What to do after this class
 Work on your homework & reading assignment
 Let me know what you like/not about this course so far
 Food for thought
 Network link speed has gone up by several orders of magnitude
over the last 20+ years. What implication does this have on
queueing delay?
 Make good use of course homepage
 Homework assignments & solutions, lecture notes
 Discussion board (pls don’t post detailed programming codes onto
newsgroup without TA’s approval)
 If you know other interesting information resources, let us know
4/12/05
56
CS118
Chapter 2: Application layer
 2.1 Principles of network
applications
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail

SMTP, POP3, IMAP
 2.5 DNS
4/12/05
 2.6 P2P file sharing
 2.7 Socket programming
with TCP
 2.8 Socket programming
with UDP
 2.9 Building a Web server
57
CS118
Before the Web:
how did people share data over the net?
 ftp (File Transfer Protocol)
 email also used for small-size data files
 user interface: not easy to use
 Command line: ftp host name
user name:
passwd:
dir file-locations
 have to know what’s available where
 earlier attempt: archie, a searching tool
• a net crawler going out visiting all public ftp servers, collect
information to feed archie server database
• user must know the archie servers address or name
4/12/05
58
CS118
FTP: the file transfer protocol
FTP
FTP
user
interface client
user
at host
file transfer
local file
system
FTP
server
remote file
system
 transfer file to/from remote host
 client/server model
client: side that initiates transfer (either to/from remote)
 server: remote host
 ftp specification: RFC 959 (http://www.ietf.org/rfc/rfc959.txt)
 ftp server: port 21

4/12/05
59
CS118
FTP: separate control, data connections
TCP control connection
port 21
 FTP client contacts FTP server at




4/12/05
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, the server opens
another TCP data connection to
client
After transferring one file, server
closes connection.
FTP
client
TCP data connection
port 20
FTP
server
 Server opens a new TCP data
connection to transfer each data
file
 Control connection: “out of band”
 FTP server maintains “state”: user
authentication, current directory
used, etc.
60
CS118
data connection management
 Used for
sending a file from client to server (put)
 sending a file from server to client (get)
 sending a listing of files or directories from server to
client
 client chooses a port number for its end of the TCP
connection



performs a passive open on this port
sends this port number to server using PORT command
 server issues an active open to that port on client host
 server always uses port 20 at its end of data connection
 end-of-file is denoted by closing the connection
4/12/05
61
CS118
FTP commands, responses
Sample commands:
Sample return codes
 sent as ASCII text over control
 status code and phrase (as in
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
4/12/05
62
HTTP)
331 Username OK,
password required
125 data connection
already open;
transfer starting
425 Can’t open data
connection
452 Error writing
file
CS118
Chapter 2: Application layer
 2.1 Principles of network
applications
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail

SMTP, POP3, IMAP
 2.5 DNS
4/12/05
 2.6 P2P file sharing
 2.7 Socket programming
with TCP
 2.8 Socket programming
with UDP
 2.9 Building a Web server
63
CS118
Electronic Mail
user mailbox
Three major components:
user
agent
 user agents
mail
server
 mail servers
 simple mail transfer protocol:
SMTP
SMTP
User Agent
SMTP
 a.k.a. “mail reader”
 composing, editing, reading mail
messages
mail
 e.g., Eudora, Outlook, elm,
server
Netscape Messenger
 outgoing, incoming messages
stored on server
user
agent
4/12/05
outgoing
message queue
64
SMTP
user
agent
mail
server
user
agent
user
agent
user
agent
CS118
Electronic Mail: mail servers
Mail Servers
user
agent
 mailbox contains incoming
mail
server
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
4/12/05
SMTP
SMTP
mail
server
user
agent
65
SMTP
user
agent
mail
server
user
agent
user
agent
user
agent
CS118
Simple Mail Transfer Protocol (SMTP) [RFC 2821]
 uses TCP to reliably transfer email message


from client to server
From client server to recipient 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 !
4/12/05
66
CS118
Scenario: Alice sends message to Bob
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
1) Alice uses UA to compose
message and “to”
[email protected]
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
1
user
agent
4/12/05
2
mail
server
3
mail
server
4
5
67
6
user
agent
CS118
Email delivery
TCP port 25
Your email application program
mail server
user
SMTP
user
SMTP
agent
daemon
sender
SMTP
user
receiver
4/12/05
user
agent
User
POP mailbox
SMTP
daemon
mail server
68
CS118
A typical SMTP message exchange (after the TCP connection setup)
sender SMTP process
receiver SMTP process
220 whitehouse.gov SMTP ready
HELO foo.berkeley.edu
250 whitehouse.gov
MAILFROM:<[email protected]>
250 OK
RCPT TO: <[email protected]>
250 OK
RCPT TO: <[email protected]>
550 No such user
DATA
354 start mail input
blah blah blah .....
<CRLF>.<CRLF>
250 OK
QUIT
221 whitehouse.gov service closing
Sample smtp interaction
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <[email protected]>
S: 250 [email protected]... Sender ok
C: RCPT TO: <[email protected]>
S: 250 [email protected] ... Recipient 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
(if more msgs to send, start from "MAIL FROM" again)
C: QUIT
S: 221 hamburger.edu closing connection
4/12/05
70
CS118
Are there some basic rules behind the reply codes?
Code meaning
220
221
250
500
550
service ready
I’m closing too
requested action OK
error, command not recognized
no such mbox, no action taken
Common practices
1st digit: whether response is good/bad/incomplete
e.g. 2= positive completion, 5=negative completion
2nd digit: encodes responses in specific categories
e.g. 2=connections, 5=mail system (status of the receiver mail
system)
3rd digit: a finer gradation of meaning in each category specified by
the 2nd digit.
4/12/05
71
CS118
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)
4/12/05
72
CS118
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
4/12/05
73
CS118
Mail message format
SMTP: protocol for
exchanging email msgs
RFC 822: standard for text
message format:
 header lines, e.g.,
header
To:
 From:
 Subject:
different from SMTP
commands!

blank
line
body
 body
 the “message”, ASCII
characters only
4/12/05
74
CS118
Message format: multimedia extensions
 MIME: multimedia mail extension, RFC 2045, 2056
 additional lines in msg header declare MIME content type
MIME version
method used
to encode data
multimedia data
type, subtype,
parameter declaration
encoded data
4/12/05
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
75
CS118
Mail access protocols
user
agent
SMTP
SMTP
sender’s mail
server
access
protocol
user
agent
receiver’s mail
server
 SMTP: delivery/storage to receiver’s server
 Mail access protocol: retrieval from server



4/12/05
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.
76
CS118
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
4/12/05
77
S:
C:
S:
C:
S:
+OK POP3 server ready
user bob
+OK
pass hungry
+OK user successfully logged
C:
S:
S:
S:
C:
S:
S:
C:
C:
S:
S:
C:
C:
S:
list
1 498
2 912
.
retr 1
<message 1 contents>
.
dele 1
retr 2
<message 1 contents>
.
dele 2
quit
+OK POP3 server signing off
on
CS118
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
4/12/05
IMAP
 Keep all messages in one
place: the server
 Allows user to organize
messages in folders
 IMAP keeps user state
across sessions:

78
names of folders and
mappings between message
IDs and folder name
CS118