Transcript Application Layer (Email, DNS, P2P)

Throughput: Internet scenario
per-connection
end-end
throughput:
min(Rc,Rs,R/10)
 in practice: Rc or
Rs is often
bottleneck

Rs
Rs
Rs
R
Rc
Rc
Rc
10 connections (fairly) share
backbone bottleneck link R bits/sec
Protocol “Layers”
Networks are complex!
 many “pieces”:
 hosts
 routers
 links of various
media
 applications
 protocols
 hardware,
software
Question:
Is there any hope of
organizing structure of
network?
Or at least our discussion
of networks?
Why layering?
Dealing with complex systems:
 Explicit structure allows identification, relationship
of complex system’s pieces
 layered reference model for discussion
 Modularization eases maintenance, updating of
system
 change of implementation of layer’s service
transparent to rest of system
 e.g., change in gate procedure doesn’t affect rest
of system
 Layering considered harmful?
Internet protocol stack
 application: supporting network applications
 FTP, SMTP, HTTP
 transport: host-host data transfer
 TCP, UDP
 network: routing of datagrams from source
to destination

IP, routing protocols
 link: data transfer between neighboring
network elements

PPP, Ethernet
 physical: bits “on the wire”
application
transport
network
link
physical
Layering: logical communication
Each layer:
 distributed
 “entities”
implement
layer functions
at each node
 entities
perform
actions,
exchange
messages with
peers
application
transport
network
link
physical
application
transport
network
link
physical
network
link
physical
application
transport
network
link
physical
application
transport
network
link
physical
Layering: logical communication
E.g.: transport
 take data from app
 add addressing,
reliability check
info to form
“datagram”
 send datagram to
peer
 wait for peer to
ack receipt
 analogy: post
office
data
application
transport
transport
network
link
physical
application
transport
network
link
physical
ack
data
network
link
physical
application
transport
network
link
physical
data
application
transport
transport
network
link
physical
Layering: physical communication
data
application
transport
network
link
physical
application
transport
network
link
physical
network
link
physical
application
transport
network
link
physical
data
application
transport
network
link
physical
Protocol layering and data
Each layer takes data from above
 adds header information to create new data unit
 passes new data unit to layer below
M
Ht M
Hn Ht M
Hl Hn Ht M
source
destination
application
transport
network
link
physical
application
transport
network
link
physical
M
message
Ht M
Hn Ht M
Hl Hn Ht M
segment
datagram
frame
Summary
 Network access and physical media
 Internet structure and ISPs
 Delay & loss in packet-switched networks
 Protocol layers, service models
 More depth, detail to follow!
Application Layer
Our goals:
 conceptual,
implementation
aspects of network
application protocols
 transport-layer
service models
 client-server
paradigm
 peer-to-peer
paradigm
 learn about protocols
by examining popular
application-level
protocols




HTTP
FTP
SMTP / POP3 / IMAP
DNS
 programming network
applications
 socket API
Some network apps
 e-mail
 voice over IP
 web
 real-time video
 instant messaging
 remote login
 P2P file sharing
 multi-user network
games
 streaming stored video
(YouTube)
conferencing
 cloud computing
 …
 …

Creating a network app
write programs that



run on (different) end
systems
communicate over network
e.g., web server software
communicates with browser
software
No need to write software
for network-core devices


network-core devices do
not run user applications
applications on end systems
allows for rapid app
development, propagation
application
transport
network
data link
physical
application
transport
network
data link
physical
application
transport
network
data link
physical
Outline
 Principles of network applications
App architectures
 App requirements

 Web and HTTP
 FTP
13
Application architectures
 Client-server
 Peer-to-peer (P2P)
 Hybrid of client-server and P2P
14
Client-server architecture
server:
 always-on host
 permanent IP address
 server farms for
scaling
clients:
client/server




communicate with server
may be intermittently
connected
may have dynamic IP
addresses
do not communicate
directly with each other
Pure P2P architecture
 no always-on server
 arbitrary end systems
directly communicate peer-peer
 peers are intermittently
connected and change IP
addresses
highly scalable but
difficult to manage
16
Hybrid of client-server and P2P
Skype
 voice-over-IP P2P application
 centralized server: finding address of remote
party:
 client-client connection: direct (not through
server)
Instant messaging
 chatting between two users is P2P
 centralized service: client presence
detection/location
• user registers its IP address with central
server when it comes online
• user contacts central server to find IP
addresses of buddies
17
Outline
 Principles of network applications
App architectures
 App requirements

 Web and HTTP
 FTP
18
Processes communicating
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
Client process: process
that initiates
communication
Server process: process
that waits to be
contacted
 Note: applications with
P2P architectures have
client processes &
server processes
19
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
host or
server
host or
server
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)
20
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?
21
Addressing processes
 to receive messages,
 identifier includes both
process must have
IP address and port
identifier
numbers associated with
process on host.
 host device has unique
32-bit IP address
 example port numbers:
 HTTP server: 80
 Q: does IP address of
 Mail server: 25
host on which process
runs suffice for
 to send HTTP message
identifying the process?
to gaia.cs.umass.edu web
server:
 A: No, many
 IP address: 128.119.245.12
processes can be
 Port number: 80
running on same host
 more shortly…
22
App-layer protocol defines
 types of messages
exchanged,

e.g., request, response
 message syntax:
 what fields in messages &
how fields are delineated
 message semantics
 meaning of information in
fields
public-domain protocols:
 defined in RFCs
 allows for
interoperability
 e.g., HTTP, SMTP
proprietary protocols:
 e.g., Skype
 rules for when and how
processes send &
respond to messages
23
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
Timing
 some apps (e.g.,
Internet telephony,
interactive games)
require low delay to be
“effective”
Throughput
 some apps (e.g.,
multimedia) require
minimum amount of
throughput to be
“effective”
 other apps (“elastic apps”)
make use of whatever
throughput they get
Security
 encryption, data integrity,
…
24