Data Communication I

Lecture 2a

presented by Werner Wild, CEO Evolution Innsbruck, San Francisco, Zurich Contact: info@evolution.at

Todays Lecture Plan

Networking Part II  Architecture of networked applications  Implementation  API  Performance requirements  HTTP Protocol


Layers: Logical Communication

E.g. transport  take data from app  add addressing, application reliability check info to form transport datagram network  send datagram data link to peer physical  wait for peer to ack receipt  analogy: post office
data application transport network data data link physical network data link physical ack application transport network data link physical

data application transport network data link physical

Layers: Physical Communication

data application transport network data link physical application transport network data link physical network data link physical application transport network data link physical

data application transport network data link physical

Protocol layering and data

Each layer takes data from above
 

adds header information to create new data unit passes new data unit to layer below
source
M

destination application transport network link physical

M Ht M Hn Ht M Hl Hn Ht M message segment datagram frame

Ht HnHt Hl HnHt

M M M

application transport network link physical

Layers in Action
Application M M

Transport Internet

Ht Hi Ht

M M

Ht Hi Ht

M M

Media access

Hm Hi Ht

Hm Hi Ht

Delay and Loss in Networks

processing queueing transmission propagation

dnode = dproc + dqueue + dtrans + dprop

Queuing Delay
  

Packets may be lost!

11.00 10.00 9.00 8.00 7.00 6.00 5.00 4.00 3.00

Varies from packet to packet Depends on traffic Consider a router:

A = arrival rate (pkts/sec) R = transmission rate (bits/sec) L = average packet size (bits) R/L = max rate of packet transmission AL/R = traffic intensity

Average Qdelay

2.00 1.00 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8

AL/R
0.9

Part 2: Application Layer

Our goals:  conceptual aspects of network application protocols client-server paradigm service models  learn by examining standard protocols


specific protocols:
http (today) smtp pop dns

programming network applications

socket API

Some Definitions
 

A process is a program running on a host. Within one host, two processes communicate with interprocess communication. Processes running in different hosts communicate with an application-layer protocol.

A user agent is an interface between the user and the network application. Web:browser E-mail: mail reader streaming audio/video: media player

A Client-Server Application Clientapplication transport Client: network  initiates contact (speaks first) data link  typically requests physical service from server,  for Web, client is implemented in browser; for e-mail, in mail reader Server:  provides requested service to client  e.g., Web server sends requested Web page, mail server delivers email

application transport network data link physical

A Network Application
User Agent Client Protocol messages Service Server Protocol

User Agent Client2 Protocol

Protocol interface Protocol messages

ApplicationApplication-layer protocols (cont).

API: application programming interface  The interface between application and transport layers  socket: Internet API
two processes communicate by sending data into a socket, reading data out of a socket

Q: how does a process identify the other process with which it wants to communicate?

Naming and Addressing



Identifying objects is a core problem.

http://www.mcs.vuw.ac.nz:80 Domain name protocol IP address
globally unique

port port

protocol
host specific

Sockets and Ports



Sockets provide an API for application

Protocol

Port is external connection point (address) of a socket Different transport protocols

different socket spaces (tcp & udp have same port numbers, but different implementations).

Well known ports (e.g. 80 for http).

Alternative Architectures
 

Messaging Request-response Do-operation Streaming

Sender

Receiver

Client Client

Server

Server

Sender

Receiver

Transport requirements of common apps

Data loss
 

Bandwidth


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

some apps (e.g., multimedia) require minimum amount of bandwidth to be effective other apps (elastic apps) make use of whatever bandwidth they get

Transport requirements of common apps

Application file transfer e-mail Web documents real-time audio/video stored audio/video interactive games financial apps Data loss no loss no loss loss-tolerant loss-tolerant loss-tolerant loss-tolerant no loss Bandwidth elastic elastic elastic audio: 5Kb-1Mb video:10Kb-5Mb same as above few Kbps up elastic Time Sensitive no no no yes, 100s msec yes, few secs yes, 100s msec yes and no

TCP Services
    

connection-oriented: setup required between client, server reliable transport: between sending and receiving process flow control: sender wont overwhelm receiver congestion control: throttle sender when network overloaded does not provide: timing, minimum bandwidth guarantees

UDP Services
 

Best effort data transfer between sending and receiving process Does not provide: connection setup, reliability, flow control, congestion control, timing, or bandwidth guarantees

Q: Why bother? Why is there a UDP?

Internet Applications: Their Protocols and Transport Protocols

Application e-mail remote terminal access Web file transfer streaming multimedia remote file server Internet telephony Application layer protocol smtp [RFC 821] telnet [RFC 854] http [RFC 2068] ftp [RFC 959] proprietary (e.g. RealNetworks) NFS proprietary (e.g., Vocaltec) Underlying transport protocol TCP TCP TCP TCP TCP or UDP TCP or UDP typically UDP

The Web: the http protocol

http: hypertext transfer protocol
 

Webs application layer protocol client-server model: client: browser that requests, receives, renders Web objects server: Web server sends objects in response to requests

PC running Explorer

Server running Apache Web server Mac running Navigator

The http protocol: more

http:


http is stateless


 

client initiates TCP connection (creates socket) to server, port 80 server accepts TCP connection from client http messages (applicationlayer protocol messages) exchanged between browser (http client) and Web server (http server) TCP connection closed

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

http example
Suppose user enters URL
(contains text, www.someSchool.edu/someDepartment/home.index references to 10 jpeg images)

1a. http client initiates TCP connection to http server (process) at www.someSchool.edu. Port 80 is default for http server. 2. http client sends http request message (containing URL) into TCP connection socket

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, sends message into socket

time

http example
Suppose user enters URL
(contains text, www.someSchool.edu/someDepartment/home.index references to 10 jpeg images)

1a. http client initiates TCP connection to http server (process) at www.someSchool.edu. Port 80 is default for http server. 2. http client sends http request message (containing URL) into TCP connection socket

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, sends message into socket

time

http example (cont.)

4. http server closes TCP
connection.

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

time

Persistent connections
Non-persistent


Persistent
 

http/1.0: server parses request, responds, closes TCP connection 2 RTTs to fetch object TCP connection object request/transfer each transfer suffers from TCPs initially slow sending rate many browsers open multiple parallel connections

default for htp/1.1 on same TCP connection: server, parses request, responds, parses new request,.. client sends requests for all referenced objects as soon as it receives base HTML. fewer RTTs, less slow start.

Sources


For the preparation of this lectures a lot of sources where used my special thanks go to :
Univ. Auckland Univ. California San Diego (UCSD) Univ. Hongkong many others

The End

Thank you for your attention !