Download chap2_2ed_5July02 - Computer Science

An Overview of
Applications
Xin Liu
ECS 152A
Ref: slides by J. Kurose and K. Ross
1
Application architecture
 Client-server architecture
 Servers always on
 With fixed address
 Server farm
 P2P architecture
 Scalability
 Difficult to manage
 Hybrid
 Napster
 Instant messaging
• Register to central server
• Chatting in a p2p fashion
2
Network applications: some review
Process: program running user agent: interfaces
within a host.
with user “above” and
network “below”.
 within same host, two
processes communicate  implements user
using interprocess
interface &
communication (defined
application-level
by OS).
protocol
 Web: browser
 processes running in
 E-mail: mail reader
different hosts
 streaming audio/video:
communicate with an
media player
application-layer
protocol
Q: software needed for network core?
3
Applications and application-layer protocols
Application: communicating,
distributed processes



e.g., e-mail, Web, P2P file
sharing, instant messaging
running in end systems
(hosts)
exchange messages to
implement application
application
transport
network
data link
physical
Application-layer protocols



one “piece” of an app
define messages
exchanged by apps and
actions taken
use communication services
provided by lower layer
protocols (TCP, UDP)
application
transport
network
data link
physical
application
transport
network
data link
physical
4
App-layer protocol defines
 Types of messages
exchanged, eg, request
& response messages
 Syntax of message
types: what fields in
messages & how fields
are delineated
 Semantics of the
fields, ie, meaning of
information in fields
 Rules for when and
how processes send &
respond to messages
Public-domain protocols:
 defined in RFCs
 allows for
interoperability
 eg, HTTP, SMTP
Proprietary protocols:
 eg, KaZaA
5
Components of Network App.
 Application-layer protocol is one piece
 Web is an application
 HTTP protocol
 HTML standard for document formats
 Web browsers (Navigator, firefox, IE)
 Web servers (e.g., Apache, microsoft servers)
 E-mail
 SMTP
protocol
 Mail servers, mail readers
6
Client-server paradigm
Typical network app has two
pieces: client and server
Client:
application
transport
network
data link
physical
 initiates contact with server
(“speaks first”)
 typically requests service from
server,
 Web: client implemented in
browser; e-mail: in mail reader
Server:
 provides requested service to client
request
reply
application
transport
network
data link
physical
 e.g., Web server sends requested Web
page, mail server delivers e-mail
7
Processes communicating across
network
 process sends/receives
messages to/from its
socket
 socket analogous to door


sending process shoves
message out door
sending process assumes
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
 Can choose the transport
layer protocol
8
Addressing processes:
 For a process to receive messages, it
must have an identifier
 Every host has a unique 32-bit IP
address
 Example port numbers:


HTTP server: 80
Mail server: 25
9
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”
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
10
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
yes, few secs
yes, 100’s msec
yes and no
11
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 providing: timing,
minimum bandwidth
guarantees
UDP service:
 unreliable data
transfer between
sending and receiving
process
 does not provide:
connection setup,
reliability, flow
control, congestion
control, timing, or
bandwidth guarantee
12
Internet apps: application, transport
protocols
Application
e-mail
remote terminal access
Web
file transfer
streaming multimedia
Internet telephony
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., Dialpad)
TCP
TCP
TCP
TCP
TCP or UDP
typically UDP
13
An Example: Domain Name System
Internet hosts, routers:


IP address
“name”, e.g.,
bread.cs.ucdavis.edu
 Map between IP addresses
and name
 Host aliasing:


relay1.west.abc.com is
abc.com, www.abc.com
Canonical hostname
 Mail-server aliasing:
 Load balancing
 Different from app., e.g.,
web, email.
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)
 note: core Internet
function, implemented as
application-layer protocol
 complexity at network’s
“edge”
 used by other
applications
14
DNS name servers
Why not centralize DNS?
 single point of failure
 traffic volume
 distant centralized
database
 maintenance
 no server has all name-
doesn’t scale!
authoritative name server:
to-IP address mappings
 Distributed, hierarchical
local name servers:



Use UDP, port 53

each ISP, company has
local (default) name server
host DNS query first goes
to local name server
for a host: stores that
host’s IP address, name
can perform name/address
translation for that host’s
name
15
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
a NSI Herndon, VA
c PSInet Herndon, VA
d U Maryland College Park, MD
g DISA Vienna, VA
h ARL Aberdeen, MD
j NSI (TBD) Herndon, VA
k RIPE London
i NORDUnet Stockholm
m WIDE Tokyo
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
16
Simple DNS example
host surf.eurecom.fr
wants IP address of
hi.cs.ucdavis.edu
root name server
2
4
5
1. contacts its local DNS
server, dns.eurecom.fr
2. dns.eurecom.fr contacts local name server
dns.eurecom.fr
root name server, if
necessary
1
6
3. root name server contacts
authoritative name server,
dns.ucdavis.edu, if
requesting host
necessary
surf.eurecom.fr
3
authorititive name server
dns.ucdavis.edu
hi.cs.ucdavis.edu
17
DNS example
root name server
Root name server:
 may not know
authoritative name
server
 may know
intermediate name
server: who to
contact to find
authoritative name
server
6
2
7
local name server
dns.eurecom.fr
1
8
requesting host
3
intermediate name server
dns.ucdavis.edu
4
5
authoritative name server
dns.cs.ucdavis.edu
surf.eurecom.fr
hi.cs.ucdavis.edu
18
DNS: iterated queries
recursive query:
iterated query:
 contacted server
replies with name of
server to contact
 “I don’t know this
name, but ask this
server”
iterated query
2
 puts burden of name
resolution on
contacted name
server
 heavy load?
root name server
3
4
7
local name server
dns.eurecom.fr
1
8
requesting host
intermediate name server
dns.ucdavis.edu
5
6
authoritative name server
dns.cs.ucdavis.edu
surf.eurecom.fr
hi.cs.ucdavis.edu
19
DNS: caching and updating records
 once (any) name server learns mapping, it caches
mapping
 cache entries timeout (disappear) after some
time
 update/notify mechanisms under design by IETF

RFC 2136

http://www.ietf.org/html.charters/dnsind-charter.html
20
DNS records
DNS: distributed db storing resource records (RR)
RR format: (name,
 Type=A
 name is hostname
 value is IP address
value, type,ttl)
 Type=CNAME
 name is alias name for some
“cannonical” (the real) name
www.ibm.com is really
 Type=NS
servereast.backup2.ibm.com
 name is domain (e.g.
 value is cannonical name
foo.com)
 value is IP address of
 Type=MX
authoritative name
 value is name of mailserver
server for this domain
associated with name
21
DNS protocol, messages
DNS protocol : query and reply messages, both with
same message format
msg header
 identification: 16 bit #
for query, reply to query
uses same #
 flags:
 query or reply
 recursion desired
 recursion available
 reply is authoritative
22
DNS protocol, messages
Name, type fields
for a query
RRs in reponse
to query
records for
authoritative servers
additional “helpful”
info that may be used
23