Application Layer

Overview

Shivkumar Kalyanaraman Biplab Sikdar • Conceptual + implementation aspects of

[email protected] [email protected] network application protocols
– client server paradigm
– service models
• Specific protocols:
– http, ftp, smtp, pop, dns
• Sockets
Rensselaer Polytechnic Institute Adapted in part from J. Kurose
1 Rensselaer Polytechnic Institute 2
Shivkumar Kalvanaraman, Biplab Sikdar (Umass) Shivkumar Kalvanaraman, Biplab Sikdar

Applications and app-layer protocols

Recap: Reference Models Application: communicating,
TCP/IP Model TCP/IP Protocols OSI Ref Model distributed processes
application
– running in network transport
Application hosts in “user space”
network
data link
Application FTP Telnet HTTP physical

Presentation – exchange messages to

implement app
Session
Transport TCP UDP – e.g., email, file transfer,
Transport the Web
Internetwork IP Network Application-layer protocols
– one “piece” of an app application
Host to EtherPacketPoint-to- Datalink application transport
– define messages transport
network
network
data link
Network net Radio Point Physical exchanged by apps and data link
physical
physical

actions taken
“Top-down” approach means we will first learn the – user services provided
application layer and then learn about lower layers by lower layer protocols
Rensselaer Polytechnic Institute 3 Rensselaer Polytechnic Institute 4
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

Network applications: some jargon Client-server paradigm

• A process is a program • A user agent is an
Typical network app has two application
that is running within a interface between pieces: client and server
transport
network
host. the user and the data link
physical

• Within the same host, network Client: request

two processes application. • initiates contact with
communicate with
interprocess – Web:browser server (“speaks first”)
communication defined – E-mail: mail reader • typically requests reply
by the OS. – streaming service from server,
• Processes running in audio/video: media application
transport

different hosts player • for Web, client is network

data link
physical
communicate with an implemented in
application-layer browser; for e-mail, in
protocol
mail reader
Rensselaer Polytechnic Institute 5 Rensselaer Polytechnic Institute 6
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

1
 Application-layer protocols
Client-server paradigm
API: application Q: how does a process
Typical network app has two application “identify” the other
pieces: client and server
transport
network
programming process with which it
data link
physical interface wants to communicate?
Server: request • defines interface – IP address of host
• provides requested between application running other process
service to client, via and transport layer – “port number” -
replies • socket: Internet API allows receiving host
reply to determine to which
• e.g., Web server application
– two processes local process the
sends requested Web transport
network
communicate by message should be
data link sending data into delivered
page, mail server physical
socket, reading data
delivers e-mail out of socket

Rensselaer Polytechnic Institute 7 Rensselaer Polytechnic Institute 8

Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

What Transport Service does an App need? Transport service requirements of common
apps
Data loss Timing
• some apps (e.g., audio) • some apps (e.g., Application Data loss Bandwidth Time Sensitive
can tolerate some loss Internet telephony,
• other apps (e.g., file interactive games) file transfer no loss elastic no
transfer, telnet) require require low delay to e-mail no loss elastic no
100% reliable data be “effective” Web documents loss-tolerant elastic no
transfer real-time audio/video loss-tolerant audio: 5Kb-1Mb yes, 100’s msec
video:10Kb-5Mb
Bandwidth stored audio/video loss-tolerant same as above yes, few secs
• some apps (e.g., multimedia) require minimum interactive games loss-tolerant few Kbps up yes, 100’s msec
financial apps no loss elastic yes and no
amount of bandwidth to be “effective”
• other apps (“elastic apps”) make use of
whatever bandwidth they get

Rensselaer Polytechnic Institute 9 Rensselaer Polytechnic Institute 10

Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

Services provided by Internet transport Internet apps: their protocols and transport
protocols protocols
TCP service:
UDP service:
• connection-oriented: setup Application Underlying
• unreliable data
required between client, transfer between Application layer protocol transport protocol
server
sending and
• reliable transport between e-mail smtp [RFC 821] TCP
receiving process remote terminal access telnet [RFC 854] TCP
sending and receiving • does not provide: Web http [RFC 2068] TCP
process
connection setup, file transfer ftp [RFC 959] TCP
• flow control: sender won’t reliability, flow streaming multimedia proprietary TCP or UDP
overwhelm receiver control, congestion (e.g. RealNetworks)
• congestion control: control, timing, or remote file server NSF TCP or UDP
throttle sender when bandwidth guarantee Internet telephony proprietary typically UDP
network overloaded (e.g., Vocaltec)

• does not provide: timing, Q: why bother? Why is

minimum bandwidth there a UDP?
guarantees
Rensselaer Polytechnic Institute 11 Rensselaer Polytechnic Institute 12
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

2
 The Web: the http protocol The http protocol: more
http: hypertext http is “stateless”
http: TCP transport service:
transfer protocol • server maintains
• client initiates TCP
• Web’s application no information
htt
pr
connection (creates
layer protocol equ socket) to server, port 80 about past client
PC running ht est
• client/server model tp requests
Explorer res
pon • server accepts TCP aside
se
– client: browser that connection from client Protocols that maintain
requests, receives, • http messages “state” are complex!
“displays” Web est
equ Server (application-layer
pr ons
e • past history (state) must
objects htt esp running protocol messages)
ttpr Apache Web be maintained
– server: Web server h
server
exchanged between
sends objects in browser (http client) and • if server/client crashes,
response to Mac running Web server (http server) their views of “state”
requests Navigator • TCP connection closed may be inconsistent,
• http1.0: RFC 1945 must be reconciled
• http1.1: RFC 2068 Rensselaer Polytechnic Institute 13 Rensselaer Polytechnic Institute 14
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

http example http example (cont.)

Suppose user enters URL www. (contains text,
School.edu/Department/home.index references to 10 4. http server closes
jpeg images) 5. http client receives TCP connection.
1a. http client initiates TCP response message
connection to http server 1b. http server at host www. containing html file,
(process) at www. School.edu waiting for TCP displays html.
School.edu. Port 80 is connection at port 80. Parsing html file, finds
default for http server. “accepts” connection, 10 referenced jpeg
notifying client time objects
2. http client sends http 6. Steps 1-5 repeated for
request message 3. http server receives request
(containing URL) into TCP message, forms response each of 10 jpeg
connection socket message containing requested objects
object
(Department/home.index),
time sends message into socket
Rensselaer Polytechnic Institute 15 Rensselaer Polytechnic Institute 16
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

Non-persistent and persistent connections http message format: request

Non-persistent Persistent • two types of http messages: request,
• HTTP/1.0 • default for HTTP/1.1
response
• server parses request, • on same TCP
responds, and closes connection: server, • http request message:
parses request,
TCP connection responds, parses new – ASCII (human-readable format)
• 2 RTTs to fetch each request,.. request line
object • Client sends requests (GET, POST, GET /somedir/page.html HTTP/1.0
HEAD commands) User-agent: Mozilla/4.0
• Each object transfer for all referenced
Accept: text/html, image/gif,image/jpeg
suffers from slow objects as soon as it header Accept-language:fr
start receives base HTML. lines
• Fewer RTTs and less
(extra carriage return, line feed)
slow start. Carriage return,
But most 1.0 browsers use line feed
indicates end
parallel TCP connections. of message
Rensselaer Polytechnic Institute 17 Rensselaer Polytechnic Institute 18
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

3
 http request message: general format http message format: response
status line
(protocol
status code HTTP/1.0 200 OK
status phrase) Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
header
Content-Length: 6821
lines
Content-Type: text/html

data data data data data ...

data, e.g.,
requested
html file

Rensselaer Polytechnic Institute 19 Rensselaer Polytechnic Institute 20

Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

http response status codes Trying out http (client side) for
In first line in server->client response message. yourself
A few sample codes: 1. Telnet to your favorite Web server:
200 OK Opens TCP connection to port 80
– request succeeded, requested object later in telnet www.eurecom.fr 80 (default http server port) at www.eurecom.fr.
this message Anything typed in sent
to port 80 at www.eurecom.fr
301 Moved Permanently
– requested object moved, new location specified 2. Type in a GET http request:
later in this message (Location:)
400 Bad Request GET /~ross/index.html HTTP/1.0 By typing this in (hit carriage
return twice), you send
– request message not understood by server this minimal (but complete)
GET request to http server
404 Not Found
– requested document not found on this server 3. Look at response message sent by http
505 HTTP Version Not Supported server!
Rensselaer Polytechnic Institute 21 Rensselaer Polytechnic Institute 22
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

User-server interaction: authentication User-server interaction: cookies

Authentication goal: control • server sends
server “cookie” to client in client server
access to server client
• stateless: client presents response msg
usual http request msg Set-cookie: 1678453 usual http request msg
authorization in each
401: authorization req. • client presents usual http response +
request WWW authenticate: Set-cookie: #
• authorization: typically cookie in later
name, password requests
usual http request msg cookie: 1678453 usual http request msg
– authorization: + Authorization:line cookie: # cookie-
header line in request • server matches spectific
usual http response msg presented-cookie usual http response msg action
– Sends header line with server-stored
WWW authenticate: usual http request msg info usual http request msg
cookie-
if unauthorized + Authorization:line – authentication cookie: #
spectific
Browser caches name & password so usual http response msg time – remembering user usual http response msg action
that user does not have to repeatedly
preferences
enter it. Rensselaer Polytechnic Institute 23 Rensselaer Polytechnic Institute 24
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

4
 User-server interaction: conditional Web Caches (proxy server)
GET
• Goal: don’t send Goal: satisfy client request without involving origin server
object if client has up- client server • user sets browser:
to-date stored Web accesses via web
(cached) version http request msg cache origin
If-modified-since: object server
• client: specify date of <date>
not • client sends all http
requests to web cache htt
Proxy
cached copy in http http response modified pr server est
equ equ
request client http est pr nse
HTTP/1.0 – if object at web
304 Not Modified res htt e spo
If-modified-since: cache, web cache pon pr
se htt
est
<date> immediately returns htt
equ pr
• server: response object in http pr nse equ
http request msg htt espo htt
pr
est
contains no object if response p r esp
tt ons
object
If-modified-since:
h e
cached copy up-to- <date> – else requests object
modified client
date: http response from origin server, origin
HTTP/1.0 304 Not HTTP/1.1 200 OK
then returns http server
Modified …
<data> response to client
Rensselaer Polytechnic Institute 25 Rensselaer Polytechnic Institute 26
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

Why Web Caching? Content Delivery: motivation

Assume: cache is origin Networks
“close” to client servers
Browsers
(e.g., in same public
Internet
network)
• smaller response
time: cache 1.5 Mbps
“closer” to client institutional access link
network
• decrease traffic to
distant servers 10 Mbps LAN

– link out of
institutional/local
institutional
ISP network often cache Web Server
bottleneck
Rensselaer Polytechnic Institute 27 Rensselaer Polytechnic Institute 28
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

Content Delivery: idea

Content Delivery: congestion • Reduces load on server
• Avoids network congestion
Networks
• “Inverse” Web Caching
Browsers

Browsers

Routers
Replicated
content

Content Sink
Router
Content Source

Web Server
Rensselaer Polytechnic Institute Web Servers 29 Rensselaer Polytechnic Institute 30
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

5
 CDN: Architectural Layout ftp: the file transfer protocol
4 Request
Routing(RR) FTP file transfer
FTP FTP
1 user client server
interface
Client
5 user
Distribution 2 at host local file remote file
Origin system system
6
System
3
Surrogate
• transfer file to/from remote host
• client/server model
q Publisher informs RR of Content Availability. – client: side that initiates transfer
q Content Pushed to Distribution System. (either to/from remote)
q Client Requests Content, Requested redirected to RR. – server: remote host
q RR finds the most suitable Surrogate • ftp: RFC 959
q Surrogate services client request. • ftp server: port 21
Rensselaer Polytechnic Institute 31 Rensselaer Polytechnic Institute 32
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

ftp: separate control, data connections ftp commands, responses

• ftp client contacts ftp
Sample commands: Sample return codes
server at port 21,
specifying TCP as • sent as ASCII text over • status code and
transport protocol control channel phrase (as in http)
• two parallel TCP TCP control connection • USER username • 331 Username OK,
port 21 • PASS password password required
connections opened:
– control: exchange • LIST returns list of file • 125 data
commands, responses TCP data connection in current directory connection
FTP port 20 FTP
between client, server. client server • RETR filename already open;
“out of band control” retrieves (gets) file transfer starting
– data: file data to/from • STOR filename stores • 425 Can’t open
server (puts) file onto remote data connection
• ftp server maintains host • 452 Error writing
“state”: current directory, file
earlier authentication
Rensselaer Polytechnic Institute 33 Rensselaer Polytechnic Institute 34
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

Electronic Mail outgoing

Three major components: message queue Electronic Mail: mail servers
• user agents user mailbox
user Mail Servers user
• mail servers agent
• mailbox contains agent
• simple mail transfer mail incoming messages mail
user user
protocol: smtp server agent server
(yet to be read) for user agent
SMTP mail • message queue of SMTP
User Agent mail
server user outgoing (to be sent) server user
• a.k.a. “mail reader” SMTP agent
mail messages SMTP agent
• composing, editing, • smtp protocol between
reading mail messages SMTP SMTP
mail user mail servers to send user
agent mail
• e.g., Eudora, Outlook, server email messages server agent
elm, Netscape – client: sending mail
user user
Messenger agent server agent
• outgoing, incoming user user
agent – “server”: receiving
messages stored on agent
mail server
server Rensselaer Polytechnic Institute
Shivkumar Kalvanaraman, Biplab Sikdar
35 Rensselaer Polytechnic Institute
Shivkumar Kalvanaraman, Biplab Sikdar
36

6
 Electronic Mail: smtp [RFC 821] Sample smtp interaction
• uses tcp to reliably transfer email msg
from client to server, port 25 S: 220 hamburger.edu
C: HELO crepes.fr
• direct transfer: sending server to S: 250 Hello crepes.fr, pleased to meet you
receiving server C: MAIL FROM: <[email protected]>
S: 250 [email protected]... Sender ok
• three phases of transfer C: RCPT TO: <[email protected]>
– handshaking (greeting) S: 250 [email protected] ... Recipient ok
C: DATA
– transfer of messages S: 354 Enter mail, end with "." on a line by itself
– closure C: Do you like ketchup?
C: How about pickles?
• command/response interaction C: .
– commands: ASCII text S: 250 Message accepted for delivery
C: QUIT
– response: status code and phrase S: 221 hamburger.edu closing connection
• messages must be in 7-bit ASCII
Rensselaer Polytechnic Institute 37 Rensselaer Polytechnic Institute 38
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

Try smtp interaction for yourself: smtp: final words

• smtp uses persistent Comparison with http
connections
• http: pull
• smtp requires that
• email: push
message (header &
• telnet servername 25 body) be in 7-bit ascii • both have ASCII
• see 220 reply from server • certain character command/response
strings are not interaction, status
• enter HELO, MAIL FROM, RCPT TO, permitted in message codes
(e.g., CRLF.CRLF).
DATA, QUIT commands Thus message has to • http: each object is
be encoded (usually encapsulated in its
above lets you send email without into either base-64 or own response
using email client (reader) quoted printable) message
• smtp server uses • smtp: multiple objects
CRLF.CRLF to message sent in a
determine end of multipart message
Rensselaer Polytechnic Institute 39 Rensselaer Polytechnic Institute 40
Shivkumar Kalvanaraman, Biplab Sikdar message Shivkumar Kalvanaraman, Biplab Sikdar

Mail message format Message format: multimedia extensions

smtp: protocol for
• MIME: multimedia mail extension, RFC
exchanging email
msgs 2045, 2056
RFC 822: standard for header • additional lines in msg header declare
blank
text message format: line MIME content type
• header lines, e.g., From: [email protected]
– To: MIME version To: [email protected]
– From: body Subject: Picture of yummy crepe.
method used MIME-Version: 1.0
– Subject: to encode data Content-Transfer-Encoding: base64
different from smtp Content-Type: image/jpeg
commands! multimedia data
• body type, subtype, base64 encoded data .....
parameter declaration .........................
– the “message”, ASCII
characters only ......base64 encoded data
encoded data

Rensselaer Polytechnic Institute 41 Rensselaer Polytechnic Institute 42

Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

7
 MIME types Multipart Type
From: [email protected]
Content-Type: type/subtype; parameters To: [email protected]
Subject: Picture of yummy crepe.
Text MIME-Version: 1.0
• example subtypes: Video Content-Type: multipart/mixed; boundary=98766789
plain, html • example subtypes: --98766789
mpeg, quicktime Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain
Image
• example subtypes: Application Dear Bob,
jpeg, gif • other data that must Please find a picture of a crepe.
be processed by --98766789
Content-Transfer-Encoding: base64
reader before
Audio Content-Type: image/jpeg
“viewable”
• exampe subtypes:
• example subtypes: base64 encoded data .....
basic (8-bit mu-law .........................
msword, octet-
encoded), 32kadpcm ......base64 encoded data
stream
(32 kbps coding) Rensselaer Polytechnic Institute 43 --98766789-- Rensselaer Polytechnic Institute 44
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

Mail access protocols authorization phase

POP3 protocol
S: +OK POP3 server ready
SMTP SMTP POP3 or • client commands: C: user alice
user user S: +OK
agent IMAP agent – user: declare
C: pass hungry
username S: +OK user successfully logged on
sender’s mail receiver’s mail – pass: password
server server
C: list
• server responses S: 1 498
– +OK S: 2 912
• SMTP: delivery/storage to receiver’s server S: .
• Mail access protocol: retrieval from server – -ERR C: retr 1
transaction phase, client: S: <message 1 contents>
– POP: Post Office Protocol [RFC 1939] S: .
• authorization (agent <-->server) and download • list: list message C: dele 1
– IMAP: Internet Mail Access Protocol [RFC 1730] numbers C: retr 2
S: <message 1 contents>
• more features (more complex) • retr: retrieve S: .
message by number C: dele 2
• manipulation of stored msgs on server
• dele: delete C: quit
– HTTP: Hotmail , Yahoo! Mail, etc. S: +OK POP3 server signing off
Rensselaer Polytechnic Institute 45 • quit Rensselaer Polytechnic Institute 46
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

DNS: Domain Name System DNS name servers

People: many identifiers: Domain Name System:
• no server has all name-to-IP
– SSN, name, Passport • distributed database Why not centralize
implemented in hierarchy address mappings
# DNS?
of many name servers local name servers:
Internet hosts, routers:
• application-layer protocol • single point of failure – each ISP, company has
– IP address (32 bit) -
used for addressing host, routers, name • traffic volume local (default) name server
servers to communicate
datagrams – host DNS query first goes
to resolve names • distant centralized
– “name”, e.g., (address/name to local name server
gaia.cs.umass.edu - database
translation) authoritative name server:
used by humans
– note: core Internet • maintenance – for a host: stores that
Q: map between IP function implemented host’s IP address, name
addresses and name ? as application-layer
doesn’t scale! – can perform
protocol
name/address translation
– complexity at
for that host’s name
network’s “edge” 47
Rensselaer Polytechnic Institute Rensselaer Polytechnic Institute 48
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

8
 DNS: Root name servers Simple DNS example
root name server
host surf.eurecom.fr
• contacted by local wants IP address of
name server that can gaia.cs.umass.edu
not resolve name 2 4
1. Contacts its local DNS 3
• root name server: 5
server,
– contacts dns.eurecom.fr
authoritative name 2. dns.eurecom.fr
server if name contacts root name local name server authorititive name server
mapping not server, if necessary dns.eurecom.fr dns.umass.edu
known
3. root name server 1 6
– gets mapping contacts authoritative
– returns mapping to name server,
local name server dns.umass.edu, if
requesting host
• ~ dozen root name necessary surf.eurecom.fr
gaia.cs.umass.edu

servers worldwide
Rensselaer Polytechnic Institute 49 Rensselaer Polytechnic Institute 50
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

DNS exampleroot name server DNS: iterated queries

root name server
recursive query:
Root name 6
• puts burden of name iterated query
2 2
3 resolution on 3
server: 7
contacted name
4
• may not know server
authoritative • heavy load? 7

name server local name server intermediate name server

iterated query: local name server intermediate name server
dns.eurecom.fr dns.umass.edu dns.eurecom.fr dns.umass.edu
• may know 4 5 • contacted server 5 6
1 8 1 8
intermediate replies with name of
name server: server to contact
authoritative name server authoritative name server
who to contact requesting host dns.cs.umass.edu • “I don’t know this dns.cs.umass.edu
name, but ask this requesting host
to find surf.eurecom.fr surf.eurecom.fr
server”
authoritative gaia.cs.umass.edu gaia.cs.umass.edu
name server Rensselaer Polytechnic Institute 51 Rensselaer Polytechnic Institute 52
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

DNS: caching and updating DNS records

DNS: distributed db storing resource records
records (RR)
• once (any) name server learns mapping,
RR format: (name, value, type,ttl)
it caches mapping
– cache entries timeout (disappear) after • Type=A • Type=CNAME
some time – name is hostname – name is an alias name
– value is IP address for some “cannonical”
• update/notify mechanisms under design (the real) name
by IETF • Type=NS
– value is cannonical
– name is domain (e.g.
– RFC 2136 name
foo.com)
– http://www.ietf.org/html.charters/dnsin • Type=MX
– value is IP address
d-charter.html of authoritative – value is hostname of
name server for this mailserver associated
domain with name
Rensselaer Polytechnic Institute 53 Rensselaer Polytechnic Institute 54
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

9
 DNS protocol, messages DNS protocol, messages
DNS protocol : query and reply messages,
both with same message format Name, type fields
for a query
msg header
• identification: 16 bit # RRs in reponse
for query, repy to to query
query uses same # records for
• flags: authoritative servers
– query or reply
additional “helpful”
– recursion desired info that may be used
– recursion available
– reply is
authoritative Rensselaer Polytechnic Institute 55 Rensselaer Polytechnic Institute 56
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

Sockets TCP sockets

Goal: learn models of client/server application Socket: a door between application process
that communicate using sockets and end-end-transport protocol (UCP or
TCP)
Socket API
socket TCP service: reliable transfer of bytes from
• introduced in BSD4.1 one process to another
UNIX, 1981 a host-local, application-
created/owned,
• explicitly created, controlled by
OS-controlled interface controlled by
used, released by apps process process application
(a “door”) into which application developer
• client/server paradigm application process can developer socket socket
both send and controlled by TCP with TCP with controlled by
• two types of transport buffers, operating
receive messages to/from operating buffers,
service via socket API: internet variables system
system variables
another (remote or
– unreliable datagram local) application process
host or host or
– reliable, byte server
server
stream-oriented
Rensselaer Polytechnic Institute 57 Rensselaer Polytechnic Institute 58
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

TCP sockets TCP Sockets

• When client creates socket: Example client-server app: Input stream: sequence
Client must contact server
client TCP establishes • client reads line from of bytes into process
• server process must connection to server TCP standard input
first be running Output stream:
• When contacted by client, (inFromUser stream) , sequence of bytes
• server must have server TCP creates new sends to server via out of process
created socket (door) socket for server process socket (outToServer
that welcomes client’s stream)
to communicate with client
iinFromServer

contact
outToServer

– allows server to talk with • server reads line from

Client contacts server by: multiple clients socket
• creating client-local • server converts line to
TCP socket application viewpoint
uppercase, sends back to
client inFromUser
• specifying IP address, TCP provides reliable, in-order
port number of server transfer of bytes (“pipe”) • client reads, prints
process between client and server modified line from socket client socket
(inFromServer stream)
Rensselaer Polytechnic Institute 59 Rensselaer Polytechnic Institute 60
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

10
 Client/server socket interaction: TCP UDP Sockets
UDP: no “connection”
Server (running on hostid) Client between client and
create socket, server
port=x, for
incoming request: • no handshaking
welcomeSocket =
ServerSocket() • sender explicitly
TCP attaches IP address application viewpoint
wait for incoming create socket,
connection request connection setup connect to hostid, port=x and port of UDP provides unreliable transfer
clientSocket =
connectionSocket =
welcomeSocket.accept()
Socket() destination of groups of bytes (“datagrams”)
• server must extract IP between client and server
send request using
read request from clientSocket address, port of
connectionSocket
sender from received
write reply to datagram
connectionSocket read reply from
clientSocket UDP: transmitted data
close
connectionSocket close may be received out
clientSocket
of order, or lost
Rensselaer Polytechnic Institute 61 Rensselaer Polytechnic Institute 62
Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

Client/server socket interaction: UDP Application Layer: Summary

Our study of network apps now complete!
Server (running on hostid) Client
• application service • specific protocols:
create socket, create socket,
requirements:
port=x, for – http
incoming request:
clientSocket =
DatagramSocket()
– reliability,
serverSocket = bandwidth, delay – ftp
DatagramSocket()
Create, address (hostid, port=x, • client-server paradigm – smtp, pop3
send datagram request
using clientSocket • Internet transport – dns
read request from
serverSocket service model • sockets
write reply to
– connection- – client/server
serverSocket oriented, reliable:
specifying client read reply from implementation
host address,
clientSocket TCP
port umber close – unreliable, – using tcp, udp
clientSocket
datagrams: UDP sockets

Rensselaer Polytechnic Institute 63 Rensselaer Polytechnic Institute 64

Shivkumar Kalvanaraman, Biplab Sikdar Shivkumar Kalvanaraman, Biplab Sikdar

Application Layer: Summary

Most importantly: learned about protocols
• typical request/reply • control vs. data msgs
message exchange: – in-based, out-of-band
– client requests info or • centralized vs.
service
decentralized
– server responds with
data, status code • stateless vs. stateful
• message formats: • reliable vs. unreliable msg
transfer
– headers: fields giving
info about data • “complexity at network
– data: info being edge”
communicated • security: authentication
Rensselaer Polytechnic Institute 65
Shivkumar Kalvanaraman, Biplab Sikdar

11