0% found this document useful (0 votes)
4 views

4.Application_Part2

The document provides an overview of the Application Layer in computer networks, focusing on DNS, P2P applications, video streaming, and socket programming. It details the structure and services of the Domain Name System (DNS), including its hierarchical organization, caching mechanisms, and security concerns. Additionally, it discusses the evolution of DNS from a centralized hosts.txt file to a distributed database, addressing issues like naming conflicts and the need for scalability.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views

4.Application_Part2

The document provides an overview of the Application Layer in computer networks, focusing on DNS, P2P applications, video streaming, and socket programming. It details the structure and services of the Domain Name System (DNS), including its hierarchical organization, caching mechanisms, and security concerns. Additionally, it discusses the evolution of DNS from a centralized hosts.txt file to a distributed database, addressing issues like naming conflicts and the need for scalability.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 71

Computer Networks and Applications

COMP 3331/COMP 9331


Week 3

Application Layer (DNS, P2P, Video


Streaming and CDN, Socket programming)

Reading Guide: Chapter 2, Sections 2.4 -2.7


2. Application Layer: outline
2.1 principles of network applications 2.5 P2P applications
2.2 Web and HTTP 2.6 video streaming and content
2.3 electronic mail distribution networks (CDNs)
§ SMTP 2.7 socket programming with
2.4 DNS UDP and TCP

A nice overview https://www.thegeeksearch.com/beginners-guide-to-dns/

2
DNS: Domain Name System
people: many identifiers: Domain Name System:
• TFN, name, passport # § distributed database
Internet hosts, routers: implemented in hierarchy of
• IP address (32 bit) - used for many name servers
addressing datagrams § application-layer protocol: hosts,
• “name”, e.g., cs.umass.edu - name servers communicate to
used by humans resolve names (address/name
Q: how to map between IP translation)
address and name, and vice • note: core Internet function,
versa ? implemented as application-
layer protocol
• complexity at network’s “edge”
3
DNS: History
v Initially all host-address mappings were in a hosts.txt file (in /etc/hosts):
§ Maintained by the Stanford Research Institute (SRI)
§ Changes were submitted to SRI by email
§ New versions of hosts.txt periodically FTP’d from SRI
§ An administrator could pick names at their discretion

v As the Internet grew this system broke down:


Jon Postel
§ SRI couldn’t handle the load; names were not unique; hosts had inaccurate copies of
hosts.txt

v The Domain Name System (DNS) was invented to fix this

http://www.wired.com/2012/10/joe-postel/
4
DNS: services, structure
DNS services Q: Why not centralize DNS?
§ hostname to IP address § single point of failure
translation § traffic volume
§ host aliasing § distant centralized database
• canonical, alias names
§ maintenance
§ mail server aliasing A: doesn‘t scale!
§ load distribution § Comcast DNS servers
• replicated Web servers: alone: 600B DNS queries
many IP addresses per day
correspond to one name

5
Goals
v No naming conflicts (uniqueness)
v Scalable
§ many names
§ (secondary) frequent updates
v Distributed, autonomous administration
§ Ability to update my own (domains’) names
§ Don’t have to track everybody’s updates
v Highly available
v Lookups should be fast

6
Key idea: Hierarchy
Three intertwined hierarchies

§ Hierarchical namespace
• As opposed to original flat namespace

§ Hierarchically administered
• As opposed to centralised

§ (Distributed) hierarchy of servers


• As opposed to centralised storage

7
Hierarchical Namespace
root

edu com gov mil org net uk fr …

berkeley ucla v “Top Level Domains” are at the top


v Domains are sub-trees
eecs sims § E.g: .edu., berkeley.edu., eecs.berkeley.edu.
v Name is leaf-to-root path
§ instr.eecs.berkeley.edu.
instr
v Depth of tree is arbitrary (limit 128)
v Name collisions trivially avoided
§ each domain is responsible

8
Hierarchical Administration
root

edu com gov mil org net uk fr

berkeley ucla Authoritative NS

eecs sims
§ A zone corresponds to a distinct contiguous portion of the
DNS name space that is managed by an administrative authority
instr
§ E.g., UCB controls names: *.berkeley.edu and *.sims.berkeley.edu

v E.g., EECS controls names: *.eecs.berkeley.edu


9
Server Hierarchy
v Top of hierarchy: Root servers
§ Location hardwired into other servers

v Next Level: Top-level domain (TLD) servers


§ .com, .edu, etc. (several new TLDs introduced recently)
§ Managed professionally

v Bottom Level: Authoritative DNS servers


§ Store the name-to-address mapping
§ Maintained by the corresponding administrative authority

10
Server Hierarchy
v Each server stores a (small!) subset of the total DNS database

v An authoritative DNS server stores “resource records” for all


DNS names in the domain that it has authority for

v Each server can discover the server(s) that are responsible for
the other portions of the hierarchy
§ Every server knows the root server(s)
§ Root server(s) knows about all top-level domains

11
Credits: Prof David Wetherall, UoW

DNS: a distributed, hierarchical database


Root NS

TLDs = Top Level Domains … …


NS

pk au

Authoritative NS
edu

unsw

cse

Local NS
Titanium
robot.cs.washington.edu.
washington.edu
.edu
12
DNS: root name servers
§ official, contact-of-last-resort
by name servers that can not 13 logical root name “servers”
worldwide each “server” replicated
resolve name many times (~200 servers in US)
§ incredibly important Internet
function
• Internet couldn’t function without
root servers
• DNSSEC – provides security
(authentication and message
integrity)
§ ICANN (Internet Corporation for
Assigned Names and Numbers)
manages root DNS domain
13
DNS: root name servers

www.root-servers.org

14
TLD: authoritative servers
Top-Level Domain (TLD) servers:
§ responsible for .com, .org, .net, .edu, .aero, .jobs, .museums,
and all top-level country domains, e.g.: .cn, .uk, .fr, .ca, .jp
§ Network Solutions: authoritative registry for .com, .net
TLD
§ Educause: .edu TLD

Authoritative DNS servers:


§ organization’s own DNS server(s), providing authoritative hostname
to IP mappings for organization’s named hosts
§ can be maintained by organization or service provider

15
Local DNS name servers
§ does not strictly belong to hierarchy
§ each ISP (residential ISP, company, university) has one
• also called “default name server”
§ Hosts learn about the local DNS server via a host configuration
protocol (e.g., DHCP)
§ Client application
• Obtain hostname (e.g., from URL)
• Do gethostbyname() to trigger DNS request to its local DNS server
§ when host makes DNS query, query is sent to its local DNS server
• has local cache of recent name-to-address translation pairs (but may be
out of date!)
• acts as proxy, forwards query into hierarchy
16
DNS name resolution: iterated query
root DNS server
Example: host at
engineering.nyu.edu wants IP
2
address for gaia.cs.umass.edu 3
TLD DNS server
Iterated query: 1 4

§ contacted server 8 5

replies with name of requesting host at local DNS server


server to contact engineering.nyu.edu dns.nyu.edu
gaia.cs.umass.edu
6
§ “I don’t know this
7

name, but ask this


server” authoritative DNS server
dns.cs.umass.edu

17
DNS name resolution: recursive query
root DNS server
Example: host at
engineering.nyu.edu wants IP 3
2
address for gaia.cs.umass.edu 7 6
Recursive query: 1 TLD DNS server

§ puts burden of 8
name resolution on requesting host at
engineering.nyu.edu
local DNS server
dns.nyu.edu 5 4
contacted name gaia.cs.umass.edu

server
§ heavy load at authoritative DNS server
dns.cs.umass.edu
upper levels of
hierarchy?
18
Caching, Updating DNS Records
§ once (any) name server learns mapping, it caches mapping
• cache entries timeout (disappear) after some time (TTL)
• TLD servers typically cached in local name servers
• thus root name servers not often visited

§ cached entries may be out-of-date (best-effort name-to-


address translation!)
• if name host changes IP address, may not be known Internet-wide until
all TTLs expire!
§ update/notify mechanisms proposed IETF standard
• RFC 2136
§ Negative caching (optional)
• Remember things that don’t work
• E.g., misspellings like www.cnn.comm and www.cnnn.com 19
DNS records
DNS: distributed database storing resource records (RR)
RR format: (name, value, type, ttl)

type=A type=CNAME
§ name is hostname § name is alias name for some
§ value is IP address “canonical” (the real) name
§ www.ibm.com is really
type=NS servereast.backup2.ibm.com
§ name is domain (e.g., § value is canonical name
foo.com)
§ value is hostname of type=MX
authoritative name server § value is name of mailserver
for this domain associated with name
20
DNS protocol messages
DNS query and reply messages, both have same format:
2 bytes 2 bytes

identification flags
message header:
# questions # answer RRs
§ identification: 16 bit # for query,
reply to query uses same # # authority RRs # additional RRs

§ flags: questions (variable # of questions)


• query or reply
• recursion desired answers (variable # of RRs)

• recursion available authority (variable # of RRs)


• reply is authoritative
additional info (variable # of RRs)

21
DNS protocol messages
DNS query and reply messages, both have same format:
2 bytes 2 bytes

identification flags

# questions # answer RRs

# authority RRs # additional RRs

name, type fields for a questions (variable # of questions)


query
RRs in response to query answers (variable # of RRs)

records for authoritative authority (variable # of RRs)


servers
additional “ helpful” info that additional info (variable # of RRs)
may be used
22
An Example Try this out yourself. Part of Lab 3

23
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 NS, A RRs into .com TLD server:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
§ create authoritative server locally with IP address 212.212.212.1
• Containing type A record for www.networkuptopia.com
• Containing type MX record for networkutopia.com

24
Updating DNS records
v Remember that old records may be cached in other
DNS servers (for up to TTL)
v General guidelines
§ Record the current TTL value of the record
§ Lower the TTL of the record to a low value (e.g., 30
seconds)
§ Wait the length of the previous TTL
§ Update the record
§ Wait for some time (e.g., 1 hour)
§ Change the TTL back to your previous time

25
Reliability
v DNS servers are replicated (primary/secondary)
§ Name service available if at least one replica is up
§ Queries can be load-balanced between replicas
v Usually, UDP used for queries
§ Need reliability: must implement this on top of UDP
§ Spec supports TCP too, but not always implemented
v DNS uses port 53
v Try alternate servers on timeout
§ Exponential backoff when retrying same server
v Same identifier for all queries
§ Don’t care which server responds

26
CDN example (more later)

Many well-known sites are


hosted by CDNs. A simple way to
check using dig is shown here.

27
Do you trust your DNS server?
v Censorship

https://wikileaks.org/wiki/Alternative_DNS

v Logging
§ IP address, websites visited, geolocation data and more
§ E.g., Google DNS:
https://developers.google.com/speed/public-dns/privacy

29
DNS security
DDoS attacks Redirect attacks
§ bombard root servers with § man-in-middle
traffic • intercept DNS queries
• not successful to date § DNS poisoning
• traffic filtering • send bogus relies to DNS
• local DNS servers cache IPs server, which caches DNSSEC
of TLD servers, allowing root Exploit DNS for DDoS [RFC 4033]
server bypass
§ send queries with spoofed
§ bombard TLD servers source address: target IP
• potentially more dangerous § requires amplification

30
DNS Cache Poisoning
v Suppose you are a bad guy and you control the name server
for drevil.com. Your name server receives a request to resolve
www.drevil.com. and it responds as follows:

;; QUESTION SECTION:
;www.drevil.com. IN A

;; ANSWER SECTION:
www.drevil.com 300 IN A 129.45.212.42

;; AUTHORITY SECTION:
drevil.com 86400 IN NS dns1.drevil.com.
drevil.com 86400 IN NS google.com
A drevil.com machine, not google.com
;; ADDITIONAL SECTION:
google.com 600 IN A 129.45.212.222

v Solution: Do not allow DNS servers to cache IP address mappings


unless they are from authoritative name servers
DNS Cache Poisoning Test - https://www.grc.com/dns/dns.htm 31
NOT ON EXAM

DoH (RFC 8484) and DoT (RFC 7858)


v DoT: DNS over Transport Layer Security (TLS)
v DoH: DNS over HTTPS (or HTTP2)
v Increase user privacy and security
v DoT: port 853, DoH: port 443
v DoH traffic masked with other HTTPS traffic
v Cloudflare, Google, etc. have publicly accessible DoT resolvers and OS
support is also available
v Chrome and Mozilla support DoH, OS support coming soon (or already
there)
v DoT: https://developers.google.com/speed/public-dns/docs/dns-over-tls
v DoH: https://developers.cloudflare.com/1.1.1.1/dns-over-https
32
Quiz: DNS (1)
v If a local DNS server has no clue about where to find the address for a
hostname then the_____

a) Server starts crying


Answer:
b) Server asks the root DNS server

c) Server asks its neighbouring DNS server

d) Request is not processed

33
Quiz: DNS (2)

v Which of the following are respectively maintained by the client-


side ISP and the domain name owner?

a) Root DNS server, Top-level domain DNS server Answer:


b) Root DNS server, Local DNS server
c) Local DNS server, Authoritative DNS server
d) Top-level domain DNS server, Authoritative DNS server
e) Authoritative DNS server, Top-level domain DNS server

34
Quiz: DNS (3)

v Suppose you open your email program and send an email to


[email protected], your email program will trigger which
type of DNS query?

a) A
Answer:
b) NS
c) CNAME
d) MX
e) All of the above

35
Quiz: DNS (4)

v You open your browser and type www.pollev.com. The minimum


number of DNS requests sent by your local DNS server to obtain
the corresponding IP address is:

A. 0
Answer:
B. 1

C. 2

D. 3

E. 42

36
2. Application Layer: outline
2.1 principles of network applications 2.5 P2P applications
2.2 Web and HTTP 2.6 video streaming and content
2.3 electronic mail distribution networks (CDNs)
§ SMTP 2.7 socket programming with
2.4 DNS UDP and TCP

37
Peer-to-peer (P2P) architecture
§ no always-on server mobile network

§ arbitrary end systems directly national or global ISP

communicate
§ peers request service from other
peers, provide service in return to
other peers local or
regional
• self scalability – new peers bring new ISP
service capacity, and new service demands home network content

§ peersare intermittently connected provider


network datacenter

and change IP addresses network

• complex management
§ examples: P2P file sharing (BitTorrent), enterprise
network
streaming (KanKan), VoIP (Skype),
Cryptocurrency (Bitcoin) 38
File distribution: client-server vs P2P
Q: how much time to distribute file (size F) from one
server to N peers?
• peer upload/download capacity is limited resource

u s: server
upload capacity
d i: peer i
file, size F us
u1 d1 u2 d2
download capacity
server
di
uN network (with abundant
bandwidth) ui
dN
u i: peer i upload
capacity

39
File distribution time: client-server
§ server transmission: must
sequentially send (upload) N file
copies: F
us
• time to send one copy: F/us
di
• time to send N copies: NF/us network
ui
§ client: each client must download
file copy
• dmin = min client download rate
• slowest client download time: F/dmin
time to distribute F
to N clients using Dc-s > max{NF/us,,F/dmin}
client-server approach
increases linearly in N 40
File distribution time: P2P
§ server transmission: must upload
at least one copy:
F
• time to send one copy: F/us us

§ client: each client must download di

file copy network


ui
• slowest client download time: F/dmin
§ clients: as aggregate must download NF bits
• max upload rate (limiting max download rate) is us + Sui
time to distribute F
to N clients using DP2P > max{F/us,,F/dmin,,NF/(us + Sui)}
P2P approach
increases linearly in N …
… but so does this, as each peer brings service capacity 41
Client-server vs. P2P: example
client upload rate = u, F/u = 1 hour, us = 10u
3.5
P2P
Minimum Distribution Time
3
Client-Server
2.5

1.5

0.5

0
0 5 10 15 20 25 30 35

N
42
P2P file distribution: BitTorrent
§ file divided into 256KB chunks
§ peers in torrent send/receive file chunks
tracker: tracks peers torrent: group of peers
participating in torrent exchanging chunks of a
file

Alice arrives …
… obtains list
of peers from tracker
… and begins exchanging
file chunks with peers in torrent

43
P2P file distribution: BitTorrent
§ peer joining torrent:
• has no chunks, but will accumulate
them over time from other peers
• registers with tracker to get list of
peers, connects to subset of peers
(“neighbors”)
§ while downloading, peer uploads chunks to other peers
§ peer may change peers with whom it exchanges chunks
§ churn: peers may come and go
§ once peer has entire file, it may (selfishly) leave or
(altruistically) remain in torrent

44
BitTorrent: requesting, sending file chunks
Requesting chunks: Sending chunks: tit-for-tat
§ at any given time, § Alice sends chunks to those
different peers have four peers currently sending
different subsets of file her chunks at highest rate
chunks
• other peers are choked by Alice
§ periodically, Alice asks (do not receive chunks from her)
each peer for list of • re-evaluate top 4 every10 secs
chunks that they have
§ every 30 secs: randomly
§ Alice requests missing
chunks from peers, select another peer, starts
rarest first (why?) sending chunks
• “optimistically unchoke” this peer
• newly chosen peer may join top 4
45
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

higher upload rate: find better


trading partners, get file faster !

46
Quiz: BitTorrent
Answer:
v BitTorrent uses tit-for-tat in each round to

a) Determine which chunks to download


b) Determine from which peers to download chunks
c) Determine to which peers to upload chunks
d) Determine which peers to report to the tracker as
uncooperative
e) Determine whether or how long it should stay after
completing download

47
Video Streaming and CDNs: context
§ stream video traffic: major consumer of Internet
bandwidth
• Netflix, YouTube, Amazon Prime: 80% of residential ISP
traffic (2020)
§ challenge: scale - how to reach ~1B users?
• single mega-video server won’t work (why?)
§ challenge: heterogeneity
§ different users have different capabilities (e.g., wired
versus mobile; bandwidth rich versus bandwidth poor)
§ solution: distributed, application-level infrastructure
48
Multimedia: video spatial coding example: instead
of sending N values of same
color (all purple), send only two
values: color value (purple) and
§ video: sequence of images
number of repeated values (N)

displayed at constant rate ……………………..


……………….…….
• e.g., 24 images/sec
§ digital image: array of pixels
• each pixel represented by bits
§ coding: use redundancy within
and between images to decrease frame i
# bits used to encode image
• spatial (within image)
• temporal (from one image to temporal coding example:
instead of sending
next) complete frame at i+1,
send only differences from
frame i frame i+1

49
Multimedia: video spatial coding example: instead
of sending N values of same
color (all purple), send only two
values: color value (purple) and

§ CBR: (constant bit rate): video number of repeated values (N)

encoding rate fixed ……………………..


……………….…….
§ VBR: (variable bit rate): video
encoding rate changes as amount
of spatial, temporal coding
changes
§ examples: frame i
• MPEG 1 (CD-ROM) 1.5 Mbps
• MPEG2 (DVD) 3-6 Mbps
temporal coding example:
• MPEG4 (often used in instead of sending
complete frame at i+1,
Internet, 64Kbps – 12 Mbps) send only differences from
frame i frame i+1

50
Streaming multimedia: DASH
§ DASH: Dynamic, Adaptive Streaming over HTTP
§ server:
• divides video file into multiple chunks
• each chunk stored, encoded at different rates
• manifest file: provides URLs for different chunks Internet

§ client: client

• periodically measures server-to-client bandwidth


• consulting manifest, requests one chunk at a time
• chooses maximum coding rate sustainable given current bandwidth
• can choose different coding rates at different points in time
(depending on available bandwidth at time)

51
Streaming multimedia: DASH
§ “intelligence” at client: client
determines
• when to request chunk (so that buffer
starvation, or overflow does not occur)
• what encoding rate to request (higher
quality when more bandwidth available)

• where to request chunk (can request


from URL server that is “close” to client
or has high available bandwidth)

Streaming video = encoding + DASH + playout buffering


52
Content distribution networks (CDNs)
§ challenge: how to stream content (selected from
millions of videos) to hundreds of thousands of
simultaneous users?
§ option 1: single, large “mega-server”
• single point of failure
• point of network congestion
• long path to distant clients
• multiple copies of video sent over outgoing link

….quite simply: this solution doesn’t scale


53
Content distribution networks (CDNs)
§ challenge: how to stream content (selected from
millions of videos) to hundreds of thousands of
simultaneous users?
§ option 2: store/serve multiple copies of videos at
multiple geographically distributed sites (CDN)
• enter deep: push CDN servers deep into
many access networks
• close to users
• Akamai: 240,000 servers deployed in more than
120 countries (2015)
• bring home: smaller number (10’s) of larger
clusters in POPs near (but not within) access
networks
• used by Limelight
54
2. Application Layer: outline
2.1 principles of network applications 2.5 P2P applications
2.2 Web and HTTP 2.6 video streaming and content
2.3 electronic mail distribution networks (CDNs)
§ SMTP 2.7 socket programming with
2.4 DNS UDP and TCP

55
DNS protocol messages
DNS query and reply messages, both have same format:
2 bytes 2 bytes

identification flags

# questions # answer RRs

# authority RRs # additional RRs

name, type fields for a questions (variable # of questions)


query
RRs in response to query answers (variable # of RRs)

records for authoritative authority (variable # of RRs)


servers
additional “ helpful” info that additional info (variable # of RRs)
may be used
56
An Example Try this out yourself. Part of Lab 3

57
Content distribution networks (CDNs)
§ CDN: stores copies of content at CDN nodes
• e.g., Netflix stores copies of MadMen
§ subscriber requests content from CDN
• directed to nearby copy, retrieves content
• may choose different copy if network path congested

… …


manifest file

where’s Madmen?

… …
58
Content distribution networks (CDNs)

OTT: “over the top”

… …
Internet host-host communication as a service


OTT challenges: coping with a congested Internet

§ from which CDN node to retrieve content?


§ viewer behavior in presence of congestion?

§ what content to place in which CDN node?

59
CDN content access: a closer look
Bob (client) requests video http://netcinema.com/6Y7B23V
§ video stored in CDN at http://KingCDN.com/NetC6y&B23V

1. Bob gets URL for video


http://netcinema.com/6Y7B23V
from netcinema.com web page 2. resolve http://netcinema.com/6Y7B23V
2 via Bob’s local DNS
1
6. request video from 5 Bob’s
KINGCDN server, local DNS
streamed via HTTP server
3. netcinema’s DNS returns CNAME for
netcinema.com 4
http://KingCDN.com/NetC6y&B23V

netcinema’s
authoratative DNS KingCDN
KingCDN.com
authoritative DNS
60
Case study: Netflix
Amazon cloud upload copies of
multiple versions of
video to CDN servers
CDN
server
Netflix registration,
accounting servers
Bob browses
Netflix video Manifest CDN
2 server
file,
1 3 requested
Bob manages returned for
Netflix account
specific CDN
video 4 server
DASH server
selected,
contacted,
streaming begins 61
Quiz: CDN

v The role of the CDN provider’s authoritative DNS name server in a


content distribution network, simply described, is:
a) to provide an alias address for each browser access to the “origin
server” of a CDN website
b) to map the query for each CDN object to the CDN server closest
to the requestor (browser)
c) to provide a mechanism for CDN “origin servers” to provide paths
for clients (browsers)
d) none of the above, CDN networks do not use DNS

Answer:

62
2. Application Layer: outline
2.1 principles of network applications 2.5 P2P applications
2.2 Web and HTTP 2.6 video streaming and content
2.3 electronic mail distribution networks (CDNs)
§ SMTP 2.7 socket programming with
2.4 DNS UDP and TCP

Please see example code (C, Java, Python) on course website


Labs 2 & 3 will include a socket programming exercise

63
Socket programming
goal: learn how to build client/server applications that
communicate using sockets
socket: door between application process and end-end-
transport protocol
application application
socket controlled by
process process app developer

transport transport
network network controlled
link
by OS
link Internet
physical physical

-64
Socket programming with UDP
UDP: no “connection” between client & server
v no handshaking before sending data
v sender explicitly attaches IP destination address and port # to each
packet
v receiver extracts sender IP address and port# from received
packet
UDP: transmitted data may be lost or received out-of-order
Application viewpoint:
vUDP provides unreliable transfer of groups of bytes (“segments”)
between client and server
65
Pseudo code UDP client
v Create socket
v Loop
§ (Send UDP segment to known port and IP addr of server)

§ (Receive UDP segment as a response from server)


v Close socket

66
Pseudo code UDP server
v Create socket
v Bind socket to a specific port where clients can contact
you
v Loop
§ (Receive UDP segment from client X)

§ (Send UDP segment as reply to client X)


v Close socket

Note: The IP address and port number of the client must be extracted from the client’s message

67
Socket programming with TCP
Client must contact server § when contacted by client, server
v server process must first be TCP creates new socket for server
running process to communicate with that
v server must have created socket particular client
(door) that welcomes client’s • allows server to talk with multiple
contact clients
• source port numbers used to
Client contacts server by:
distinguish clients (more when we
v Creating TCP socket, specifying IP study TCP)
address, port number of server
process Application viewpoint
v when client creates socket: client TCP provides reliable, in-order
TCP establishes connection to byte-stream transfer (“pipe”)
server TCP between client and server

68
TCP Sockets

69
Pseudo code TCP client
v Create socket (ConnectionSocket)
v Do an active connect specifying the IP address and port
number of server
v Read and write data into ConnectionSocket to
communicate with client
v Close ConnectionSocket

70
Pseudo code TCP server
v Create socket (WelcomingSocket)
v Bind socket to a specific port where clients can contact
you
v Register with the OS your willingness to listen on that
socket for clients to contact you
v Loop
§ Accept new connection(ConnectionSocket)
§ Read and write data into ConnectionSocket to communicate
with client
§ Close ConnectionSocket
v Close WelcomingSocket

71
Summary
our study of network apps now complete!
§ application architectures § specific protocols:
• client-server • HTTP
• P2P
• SMTP, IMAP
§ application service requirements:
• DNS
• reliability, bandwidth, delay
§ Internet transport service model • P2P: BitTorrent, DHT
• connection-oriented, reliable: § video streaming, CDNs
TCP § socket programming:
• unreliable, datagrams: UDP TCP, UDP sockets

72

You might also like