Introduction to Computer Networking Guy Leduc Chapter 2 ... · transfer protocol Web’s application layer protocol client/server model! client: browser that requests, receives, (using

1

© From Computer Networking, by Kurose&Ross 2: Application Layer 2-1

Introduction to Computer Networking

Guy Leduc

Chapter 2 Application Layer Computer Networking: A

Top Down Approach, 7th edition. Jim Kurose, Keith RossAddison-Wesley, April 2016


Chapter 2: outline

❒  2.1 Principles of network applications❒  2.2 Web and HTTP❒  2.3 DNS❒  2.4 Socket programming with UDP and TCP

2


Chapter 2: Application LayerOur 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!  DNS

❒  creating network applications!  socket API


Some network apps

❒  e-mail❒  web❒  instant messaging❒  remote login❒  P2P file sharing❒  multi-user network

games❒  streaming stored video

(YouTube, Hulu, Netflix)

❒  voice over IP (e.g., Skype)

❒  real-time video conferencing

❒  social networking❒  search❒  …❒  …

3


Creating a network appwrite 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 architectures

Possible structure of applications:! Client-server! Peer-to-peer (P2P)

4


Client-server architecture

server: ❒  always-on host❒  permanent IP address❒  data centers for scaling

clients:❒  communicate with server❒  may be intermittently connected❒  may have dynamic IP

addresses❒  do not communicate directly

with each other

client/server


P2P architecture❒  no always-on server❒  arbitrary end systems directly

communicate❒  peers request service from

other peers, provide service in return to other peers!  self scalability – new peers

bring new service capacity, as well as new service demands

❒  peers are intermittently connected and change IP addresses!  complex management

peer-peer

5


Hybrid of client-server and P2PSkype

!  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/

locationBitTorrent

! exchanging file chunks between users is P2P!  tracker: maintains list of peers participating in

torrent


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

!  aside: applications with P2P architectures have client processes & server processes

clients, servers

6


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 to deliver message to socket at receiving process

Internet

controlled by OS

controlled by app developer

transport

application

physical

link

network

process

transport

application

physical

link

network

process socket


Addressing processes

❒  to receive messages, process must have identifier

❒  host device has (at least) one IP address

❒  Q: does IP address of host on which process runs suffice for identifying the process?

❒  identifier includes both IP address and port number associated with process on host

❒  example port numbers:!  HTTP server: 80!  mail server: 25

❒  to send HTTP message to gaia.cs.umass.edu web server:!  IP address: 128.119.245.12!  port number: 80

❒  more shortly…

"  A: no, many processes can be running on same host

7


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

❒  Rules for when and how processes send & respond to messages

Open protocols:❒  defined in RFCs❒  allows for

interoperability❒  e.g., HTTP, SMTP

Proprietary protocols:❒  e.g., Skype


What transport service does an app need?Data integrity❒  some apps (e.g., file

transfer, web transactions) require 100% reliable data transfer

❒  other apps (e.g., audio) can tolerate some loss

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, …

8


Transport service requirements of common apps

Application

file transfere-mail

Web documentsreal-time audio/video

stored audio/videointeractive gamesinstant messaging

Data loss

no lossno lossno lossloss-tolerant

loss-tolerantloss-tolerantno loss

Throughput

elasticelasticelasticaudio: 5kbps-1Mbpsvideo:10kbps-5Mbpssame as above few kbps upelastic

Time Sensitive

nononoyes, 100’s msec

yes, few secsyes, 100’s msecyes and no


Internet transport protocols services

TCP service:❒  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 throughput guarantees, security

❒  connection-oriented: setup required between client and server processes

UDP service:❒  unreliable data transfer

between sending and receiving process

❒  does not provide: reliability, flow control, congestion control, timing, throughput guarantee, security, connection setup

Q: Why bother? Why is there a UDP?

9


Internet apps: application, transport protocols

Application

e-mailremote terminal access

Web file transfer

streaming multimedia

Internet telephony

Applicationlayer protocol

SMTP [RFC 2821]Telnet [RFC 854]HTTP [RFC 2616]FTP [RFC 959]HTTP (e.g. Youtube),RTP [RFC 1889]SIP, RTP, proprietary(e.g., Skype)

Underlyingtransport protocol

TCPTCPTCPTCPTCP or UDP

typically UDP


Securing TCP

TCP & UDP ❒  no encryption❒  cleartext passwords

sent into socket traverse Internet in cleartext

SSL ❒  provides encrypted TCP

connection❒  data integrity❒  end-point authentication

SSL is at app layer❒  Apps use SSL libraries,

which “talk” to TCPSSL socket API#  cleartext passwords

sent into socket traverse Internet encrypted

# See Chapter 8 of book

10


Chapter 2: outline

❒  2.1 Principles of network applications ❒  2.2 Web and HTTP❒  2.3 DNS❒  2.4 Socket programming with UDP and TCP


Web and HTTP

First, a review…❒  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 (Universal Resource Locator):

http://www.someschool.edu:8080/someDept/pic.gif

host name or IP addr

path nameport (if nonstandard)

protocolname

11


HTTP overview

HTTP: hypertext transfer protocol

❒  Web’s application layer protocol

❒  client/server model!  client: browser that

requests, receives, (using HTTP protocol) and “displays” Web objects

!  server: Web server sends (using HTTP protocol) objects in response to requests

PC runningFirefox browser

server running

Apache Webserver

iphone runningSafari browser

HTTP requestHTTP response

HTTP request

HTTP response


HTTP overview (continued)

Uses TCP (why?):❒  client initiates TCP connection

(creates socket) to server, port 80

❒  server accepts TCP connection from client

❒  HTTP messages (application-layer protocol messages) exchanged between browser (HTTP client) and Web server (HTTP server)

❒  TCP connection closed

HTTP is “stateless”❒  server maintains no

information about past client requests

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

aside

12


HTTP connections

non-persistent HTTP❒  at most one object

sent over TCP connection! connection then

closed❒  downloading

multiple objects required multiple connections

persistent HTTP❒ multiple objects can

be sent over single TCP connection between client, server


Non-persistent HTTPSuppose user enters URL

www.someSchool.edu/someDepartment/home.index

1a. HTTP client initiates TCP connection to HTTP server (process) at www.someSchool.edu on port 80

2. HTTP client sends HTTP request message (containing URL) into TCP connection socket. Message indicates that client wants object someDepartment/home.index

1b. HTTP server at host www.someSchool.edu waiting for TCP connection at port 80. “accepts” connection, notifying client

3. HTTP server receives request message, forms response message containing requested object, and sends message into its socket

time

(contains text, references to 10

jpeg images)

13


Non-persistent HTTP (cont.)

5. HTTP client receives response 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. HTTP server closes TCP connection.

time


Non-persistent HTTP: response timeRTT (definition): Round Trip Time:

time to send a small packet to travel from client to server and back

HTTP 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❒  non-persistent HTTP response

time =

2 RTT + file transmission time

time to transmit file

initiate TCPconnection

RTTrequestfile

RTT

filereceived

time time

File transmission time = file size / average throughput of underlying TCP connection

14


Persistent HTTP

Non-persistent 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

❒  client sends requests as soon as it encounters a referenced object

❒  as little as one RTT for all the referenced objects when requests are pipelined


HTTP request message

❒  two types of HTTP messages: request, response❒  HTTP request message:

!  ASCII (human-readable format)

request line(GET, POST, HEAD commands)

header lines

carriage return, line feed at startof line indicatesend of header lines

GET /index.html HTTP/1.1\r\nHost: www-net.cs.umass.edu\r\nUser-Agent: Firefox/3.6.10\r\nAccept: text/html,application/xhtml+xml\r\nAccept-Language: en-us,en;q=0.5\r\nAccept-Encoding: gzip,deflate\r\nAccept-Charset: ISO-8859-1,utf-8;q=0.7\r\nKeep-Alive: 115\r\nConnection: keep-alive\r\n\r\n

carriage return characterline-feed character

Whyneeded?

} Persistent mode

15


HTTP request message: general format

request line

header lines

body

method sp sp cr lf version URL

cr lf value header field name

cr lf value header field name

~ ~ ~ ~

cr lf

entity body ~ ~ ~ ~

:

:


Uploading form input

POST method:❒  When Web page includes form input❒  Input is uploaded to server in entity body

The GET method can also be used in this case:❒  Input is uploaded in URL field of request line:

http://www.somesite.com/animalsearch?monkeys&banana

Query string

16


Method types

HTTP/1.0❒  GET❒  POST

!  send data to a remote resource specified in URL field

❒  HEAD!  asks server to leave

requested object out of response

!  it’s a GET without the content

HTTP/1.1❒  GET, POST, HEAD❒  PUT

!  uploads file/object in entity body to path specified in URL field (creation or update of an object)

!  URL: where to store the file

❒  DELETE!  Deletes file/object

specified in the URL field


HTTP response message

status line (protocol status code status phrase)

header lines

data, e.g., requested HTML file

HTTP/1.1 200 OK\r\n Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n Server: Apache/2.0.52 (CentOS)\r\n Last-Modified: Tue, 30 Oct 2007 17:00:02 GMT\r\n ETag: "17dc6-a5c-bf716880"\r\n Accept-Ranges: bytes\r\n Content-Length: 2652\r\n Keep-Alive: timeout=10, max=100\r\n Connection: Keep-Alive\r\n Content-Type: text/html; charset=ISO-8859-1\r\n \r\n data data data data data ...

17


HTTP response status codes

200 OK!  request succeeded, requested object later in this msg

301 Moved Permanently!  requested object moved, new location specified later in this

msg (Location:)400 Bad Request

!  request msg not understood by server404 Not Found

!  requested document not found on this server505 HTTP Version Not Supported

#  status code appears in 1st line in server-to-client response message.

#  some sample codes:


Trying out HTTP (client side) for yourself

1. Telnet to your favorite Web server:

Opens TCP connection to port 80(default HTTP server port) at gaia.cs.umass.edu.Anything typed in sent to port 80 at gaia.cs.umass.edu

2. Type in a GET HTTP request:

By typing this in (hit carriagereturn twice), you sendthis minimal (but complete) GET request to HTTP server

3. Look at response message sent by HTTP server!

GET /kurose_ross/interactive/index.php HTTP/1.1Host: gaia.cs.umass.edu

telnet gaia.cs.umass.edu 80

18


User-server state: cookies

Many major Web sites use cookies

Four components:1) cookie header line of

HTTP response message2) cookie header line in

HTTP request message3) cookie file kept on user’s

host, managed by user’s browser

4) back-end database at Web site

Example:❒  Susan always access

Internet from PC❒  visits specific e-

commerce site for first time

❒  when initial HTTP request arrives at site, site creates: ! unique ID! entry in backend

database for ID


Cookies: keeping “state” (cont.)client server

usual http response msg

usual http response msg

cookie file

one week later:

usual http request msgcookie: 1678 cookie-

specificaction

access

ebay 8734 usual http request msg Amazon servercreates ID

1678 for user create entry

usual http response set-cookie: 1678 ebay 8734

amazon 1678

usual http request msgcookie: 1678 cookie-

specificaction

accessebay 8734amazon 1678

backenddatabase

19


Cookies (continued)What cookies can be used

for:❒  authorization❒  shopping carts❒  recommendations❒  user session state (Web

e-mail)

Cookies and privacy:❒  cookies permit sites to

learn a lot about you❒  you may supply name

and e-mail to sites

aside

How to keep “state”:❒  protocol endpoints: maintain state at sender/receiver

over multiple transactions❒  cookies: http messages carry stateAny security issue?


Web caches (proxy server)

❒  user sets browser: Web accesses via cache

❒  browser sends all HTTP requests to cache!  object in cache:

cache returns object !  else cache requests

object from origin server, then returns object to client

goal: satisfy client request without involving origin server

client

proxyserver

client

HTTP request

HTTP response

HTTP request HTTP request

origin server

origin server

HTTP response HTTP response

20


More about Web caching

❒  cache acts as both client and server!  server for original

requesting client!  client to origin server

❒  typically cache is installed by ISP (university, company, residential ISP)

Why Web caching?1.  reduce response time for

client request2.  reduce traffic on an

institution’s access link3.  reduce load on servers

❒  Internet dense with caches: enables “poor” content providers to effectively deliver content (but so too does P2P file sharing)


Caching example:

originservers

public Internet

institutionalnetwork 1 Gbps LAN

1.54 Mbps access link

assumptions:!  avg object size: 100 Kbits!  avg request rate from browsers to

origin servers: 15/sec!  avg data rate to browsers:

1.5 Mbps!  RTT from institutional router to

any origin server: 2 sec!  access link rate: 1.54 Mbps

consequences:!  LAN utilization: 0.15%!  access link utilization = 99%!  total delay = Internet delay +

access delay + LAN delay = 2 sec + minutes + µsecs

problem!

21






consequences:!  LAN utilization: 0.15%!  access link utilization = 99%!  total delay = Internet delay + access

delay + LAN delay = 2 sec + minutes + usecs

Caching example: fatter access link

originservers


15.4 Mbps

15.4 Mbps

msecsCost: increased access link speed (not cheap!)

9.9%

public Internet







consequences:!  LAN utilization:!  access link utilization =


Caching example: install local cache

originservers


local web cache

??

How to compute link utilization, delay?

Cost: web cache (cheap!)

public Internet

22


Caching example: install local cache Calculating access link

utilization, delay with cache:suppose cache hit rate is 0.4

40% requests satisfied at cache, 60% requests satisfied at origin

originservers


!  access link utilization: 60% of requests use access link

!  data rate to browsers over access link = 0.6*1.5 Mbps = 0.9 Mbps

!  utilization = 0.9/1.54 = 58%

! total delay"  = 0.6 * (delay from origin servers)

+ 0.4 * (delay when satisfied at cache)"  = 0.6 (2.01) + 0.4 (~msecs) "  = ~ 1.2 secs"  less than with 15.4 Mbps link (and cheaper too!)

public Internet


local web cache


Conditional GET

❒  Goal: don’t send object if cache has up-to-date cached version!  no object transmission

delay!  lower link utilization

❒  cache: specify date of cached copy in HTTP requestIf-modified-since:

<date>

❒  server: response contains no object if cached copy is up-to-date: HTTP/1.0 304 Not

Modified

HTTP request msg If-modified-since: <date>

HTTP response HTTP/1.0

304 Not Modified

object not

modified after

<date>

HTTP request msg If-modified-since: <date>

HTTP response HTTP/1.0 200 OK

<data>

object modified

after <date>

server local web cache

23


Chapter 2: outline



DNS: Domain Name System

People: many identifiers:!  SSN, name, passport #

Internet hosts, routers:!  IP address (32 bit) - used

for addressing datagrams!  “name”, e.g.,

www.yahoo.com - used by humans

Q: how to map between IP address and name, and vice versa?

Domain Name System:❒  distributed database

implemented in hierarchy of many name servers

❒  application-layer protocol host, name servers communicate to resolve names (address/name translation)!  note: core Internet function,

implemented as application-layer protocol

!  complexity at network’s “edge”

24


DNS: services, structure why not centralize DNS?❒  single point of failure❒  traffic volume❒  distant centralized database❒  maintenance

DNS services❒  hostname to IP address

translation❒  host aliasing

!  canonical, alias names❒  mail server aliasing❒  load distribution

!  replicated Web servers: many IP addresses correspond to one name

A: doesn’t scale!


Root DNS Servers

com DNS servers org DNS servers edu DNS servers

poly.edu DNS servers

umass.edu DNS servers yahoo.com

DNS servers amazon.com DNS servers

pbs.org DNS servers

DNS: a distributed, hierarchical database

Client wants IP for www.amazon.com; 1st approx:❒  client queries root server to find com DNS server❒  client queries com DNS server to get amazon.com DNS

server❒  client queries amazon.com DNS server to get IP

address for www.amazon.com

25


DNS: root name servers

a. Verisign, Los Angeles CA (5 other sites)b. USC-ISI Marina del Rey, CAl. ICANN Los Angeles, CA (41 other sites)

e. NASA Mt View, CAf. Internet Software C.Palo Alto, CA (and 48 other sites)

i. Netnod, Stockholm (37 other sites)

k. RIPE London (17 other sites)

m. WIDE Tokyo(5 other sites)

c. Cogent, Herndon, VA (5 other sites)d. U Maryland College Park, MDh. ARL Aberdeen, MDj. Verisign, Dulles VA (69 other sites )

g. US DoD Columbus, OH (5 other sites)

# Managed by 13 organizations# Over 400 root name “servers” scattered all over

the world


TLD, authoritative servers

❒  Top-level domain (TLD) servers:!  responsible for .com, .org, .net, .edu, .jobs, …

and all top-level country domains, e.g.: .uk, .fr, .be! Network Solutions maintains servers for .com TLD! DNS Belgium for the .be 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

26


Local DNS name server

❒  does not strictly belong to hierarchy❒  each ISP (residential ISP, company,

university) has one! also called “default name 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


requesting hostcis.poly.edu

gaia.cs.umass.edu

root DNS server

local DNS serverdns.poly.edu

1

23

4

5

6

authoritative DNS serverdns.cs.umass.edu

78

TLD DNS server

DNS name resolution example

❒  host at cis.poly.edu wants IP address for gaia.cs.umass.edu

iterated query:#  contacted server

replies with next server to contact

#  “I don’t know this name, but ask this server”

#  caching in local DNS"  can skip steps

27


45

6

3

recursive query:!  puts burden of name

resolution on contacted name server

!  heavy load at upper levels of hierarchy?

!  caching, where?requesting host

cis.poly.edu

gaia.cs.umass.edu

root DNS server

local DNS serverdns.poly.edu

1

27

authoritative DNS serverdns.cs.umass.edu

8

TLD DNS server

DNS name resolution example


DNS: caching, updating 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 (Dynamic DNS):

!  RFC 2136

28


DNS recordsDNS: distributed db storing resource records (RR)

❒  Type=NS!  name is domain, DNS zone

(e.g. foo.com)!  value is hostname of

authoritative name server for this domain

!  domain name ≠ hostname

RR format: (name, value, type, ttl)

❒  Type=A (or AAAA)!  name is hostname

(aka FQDN)!  value is IPv4 (or IPv6)

address

❒  Type=CNAME!  name is alias name for some

“canonical” (the real) name www.ibm.com is really servereast.backup2.ibm.com!  value is canonical name

❒  Type=MX!  value is name of mailserver

associated with the domain name


DNS protocol, messages❒  query and reply messages, both with same message format

(usually sent over UDP, why?)

msg header!  identification: 16 bit # for

query, reply to query uses same #

!  flags:"  query or reply"  recursion desired "  recursion available"  reply is authoritative

identification flags

# questions

questions (variable # of questions)

# additional RRs# authority RRs

# answer RRs

answers (variable # of RRs)

authority (variable # of RRs)

additional info (variable # of RRs)

2 bytes 2 bytes

29


name, type fields for a query

RRs in responseto query

records forauthoritative servers

additional “helpful”info that may be used

identification flags

# questions

questions (variable # of questions)

# additional RRs# authority RRs

# answer RRs

answers (variable # of RRs)

authority (variable # of RRs)

additional info (variable # of RRs)

2 bytes 2 bytes

DNS protocol, messages


Inserting records into DNS❒  example: new startup “Network Utopia”❒  register name networkutopia.com at DNS registrar (e.g.,

Network Solutions)!  provide names, IP addresses of authoritative name server

(primary and secondary)!  registrar inserts two RRs into com TLD server:

(networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, 212.212.212.1, A)

❒  create authoritative server Type A record for www.networkutopia.com; Type MX record for networkutopia.com

30


Chapter 2: outline



Socket programming

goal: learn how to build client/server applications that communicate using sockets

socket: door between application process and end-end-transport protocolSocket API introduced in BSD4.1 UNIX, 1981

Internet

controlled by OS

controlled by app developer

transport

application

physical

link

network

process

transport

application

physical

link

network

process socket

31


Socket programming

Two socket types for two transport services:!  UDP: unreliable datagram!  TCP: reliable, byte stream-oriented

Application Example:1.  Client reads a line of characters (data) from its keyboard

and sends the data to the server.2.  The server receives the data and converts characters to

uppercase.3.  The server sends the modified data to the client.4.  The client receives the modified data and displays the line

on its screen.


Socket programming with UDP

UDP: no “connection” between client & server❒  no handshaking before sending data❒  sender explicitly attaches IP destination address and

port # to each application data unit❒  rcvr extracts sender IP address and port# from

received data unitUDP: transmitted data may be lost or received

out-of-order

Application viewpoint:❒  UDP provides unreliable transfer of groups of bytes

(“datagrams”) between client and server

32


Client/server socket interaction: UDP

closeclientSocket

Server

read datagram fromclientSocket

write reply toserverSocketspecifying clienthost address,port number

create socket,clientSocket = DatagramSocket()

Client

Create datagram with server IP and port=x; send datagram request via clientSocket

port# unspecified,dynamically assigned by OS,no binding necessary

discoversclient hostaddress,port #

create socket, port=x, for incoming request:serverSocket = DatagramSocket(x)

read request fromserverSocket

socket call+ bind call


UDP observations & questions❒  Both client and server use DatagramSocket ❒ Dest IP and port are explicitly attached to app data

unit by client and server❒ Can multiple clients use the server?

! How many sockets needed by server?! How many port numbers used at server side?

33


Socket programming with TCPClient must contact server❒  server process must first be

running❒  server must have created

socket (door) that welcomes client’s contact (welcoming socket)

Client contacts server by:❒  creating TCP socket

specifying IP address, port number of server process

❒  When client creates socket: client TCP establishes connection to server TCP

❒  When contacted by client, server TCP creates new socket for server process to communicate with that particular client!  allows server to talk with

multiple clients!  source IP and source port

numbers used to distinguish clients (more in Chap 3)

TCP provides reliable, in-order transfer of bytes (“pipe”) between client and server

application viewpoint


Client/server socket interaction: TCP

wait for incomingconnection requestconnectionSocket =welcomeSocket.accept()

closeconnectionSocket

read reply fromclientSocket

closeclientSocket

send request usingclientSocketread request from

connectionSocket

write reply toconnectionSocket

TCP connection setup

create socket,connect to serverid, port=x

clientSocket = Socket(serverid,x)

parametersof server

connection socket≠

welcome socket,

but both are associated with the same port x

Create welcome socket, port=x, for incoming connections:welcomeSocket =

ServerSocket(x)

Server (running on serverid) Client

socket call+ bind call+ listen call

socket call+ connect call

34


TCP observations & questions

❒  Two types of socket primitives: ! ServerSocket and Socket

❒ When client knocks on serverSocket’s “door,” server creates connectionSocket and completes TCP connection

❒ Dest IP and port are not explicitly attached to app data unit by client and server

❒ Can multiple clients use the server?! How many sockets needed by server? ! How many port numbers used at server side?


Chapter 2: Summary

❒  application architectures!  client-server!  P2P

❒  application service requirements:!  reliability, throughput,

delay❒  Internet transport service

model!  connection-oriented,

reliable: TCP!  unreliable, datagrams:

UDP

our study of network apps now complete!❒  specific protocols:

!  HTTP!  DNS

❒  socket programming:!  TCP, UDP sockets

35


Chapter 2: Summary

❒  typical request/reply message exchange:!  client requests info or

service!  server responds with

data, status code❒  message formats:

!  headers: fields giving info about data

!  data: info being communicated

Most importantly: learned about protocols

Important themes: ❒  control vs. data msgs❒  centralized vs.

decentralized ❒  stateless vs. stateful❒  reliable vs. unreliable

msg transfer ❒  “complexity at network

edge”

Documents

Introduction to Computer Networking Guy Leduc Chapter 2 ... · transfer protocol Web’s application layer protocol client/server model! client: browser that requests, receives, (using