Application Design based on TCP or UDP

IHA præsentation 1

Application Design based on TCP or UDP

Lesson 6

IHA præsentation 2

Outline for today

• The Internet Protocols: UDP & TCP

• Socket programming

• Application Design based on TCP/UPD

IHA præsentation 3

TCP/UPD: Transport services

•provide logical communication between app processes running on different hosts•transport protocols run in end systems

•send side: breaks app messages into segments, passes to network layer•rcv side: reassembles segments into messages, passes to app layer

•more than one transport protocol available to apps

•Internet: TCP and UDP

application

transportnetworkdata linkphysical

application


logical end-end transport

IHA præsentation 4

Transport vs. network layer

•network layer: logical communication between hosts

•transport layer: logical communication between processes

•relies on, enhances, network layer services

IHA præsentation 5

Internet transport-layer protocols

•reliable, in-order delivery: TCP•Connection-oriented

• Handshake to setup com.•congestion control •flow control•connection setup

•unreliable, unordered delivery: UDP•connectionless•no-frills extension of “best-effort” IP

•services not available: •delay guarantees•bandwidth guarantees

application

transportnetworkdata linkphysical network

data linkphysical

networkdata linkphysical





application


logical end-end transport

IHA præsentation 6

UDP: more

•often used for streaming multimedia apps

•loss tolerant•rate sensitive

•other UDP uses•DNS•SNMP

•reliable transfer over UDP: add reliability at application layer

•application-specific error recovery!

source port # dest port #

32 bits

Applicationdata

(message)

UDP segment format

length checksumLength, in

bytes of UDPsegment,including

header

IHA præsentation 7

UDP checksum

Sender:•treat segment contents as sequence of 16-bit integers•checksum: addition (1’s complement sum) of segment contents•sender puts checksum value into UDP checksum field

Receiver:•compute checksum of received segment•check if computed checksum equals checksum field value:

•NO - error detected•YES - no error detected. But maybe errors nonetheless?

Goal: detect “errors” (e.g., flipped bits) in transmitted segment

IHA præsentation 8

TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581

•full duplex data:•bi-directional data flow in same connection•MSS: maximum segment size

•connection-oriented: •handshaking (exchange of control msgs) init’s sender, receiver state before data exchange

•flow controlled:•sender will not overwhelm receiver

•point-to-point:•one sender, one receiver

•reliable, in-order byte steam:•no “message boundaries”

•pipelined:•TCP congestion and flow control set window size

•send & receive buffers

socketdoor

T C Psend buffer

T C Preceive buffer

socketdoor

segm ent

applicationwrites data

applicationreads data

IHA præsentation 9

TCP segment structure

source port # dest port #

32 bits

applicationdata

(variable length)

sequence number

acknowledgement numberReceive window

Urg data pnterchecksum

FSRPAUheadlen

notused

Options (variable length)

URG: urgent data (generally not used)

ACK: ACK #valid

PSH: push data now(generally not used)

RST, SYN, FIN:connection estab(setup, teardown

commands)

# bytes rcvr willingto accept

countingby bytes of data(not segments!)

Internetchecksum

(as in UDP)

IHA præsentation 10

TCP seq. #’s and ACKsSeq. #’s:

•byte stream “number” of first byte in segment’s data

ACKs:•seq # of next byte expected from other side•cumulative ACK

Q: how receiver handles out-of-order segments

•A: TCP spec doesn’t say, - up to implementor

Host A Host B

Seq=42, ACK=79, data = ‘C’

Seq=79, ACK=43, data = ‘C’

Seq=43, ACK=80

Usertypes

‘C’

host ACKsreceipt

of echoed‘C’

host ACKsreceipt of

‘C’, echoesback ‘C’

timesimple telnet scenario


Question

Suppose you want to do a transaction from a remote client to a server as fast as possible.

Would you use UDP or TCP? Why ?

You would use UDP. With UDP, the transaction can be completed in one roundtrip time (RTT) - the client sends the transaction request into a UDP socket, and the server sends the reply back to the client's UDP socket. With TCP, a minimum of two RTTs are needed - one to set-up the TCP connection, and another for the client to send the request, and for the server to send back the reply.


Socket Programming


Socket programming

Socket API• introduced in BSD4.1 UNIX, 1981

• explicitly created, used, released by apps

• client/server paradigm

• two types of transport service via socket API:

• unreliable datagram • reliable, byte stream-

oriented

a host-local, application-created,

OS-controlled interface (a “door”) into which

application process can both send and

receive messages to/from another

application process

socket

Goal: learn how to build client/server application that communicate using sockets


Socket-programming using TCP

Socket: a door between application process and end-end-transport protocol (UCP or TCP)

TCP service: reliable transfer of bytes from one process to another

process

TCP withbuffers,

variables

socket

controlled byapplicationdeveloper

controlled byoperating

system

host orserver

process

TCP withbuffers,

variables

socket

controlled byapplicationdeveloper

controlled byoperatingsystem

host orserver

internet


Addressing processes

•to receive messages, process must have identifier

•host device has unique 32-bit IP address

•Q: does IP address of host suffice for identifying the process?


Addressing processes

•to receive messages, process must have identifier

•host device has unique 32-bit IP address

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

•A: No, many processes can be running on same host

•identifier includes both IP address and port numbers 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


Socket programming with TCP

Client must contact server•server process must first be running•server must have created socket (door) that welcomes client’s contact

Client contacts server by:•creating client-local 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 client

•allows server to talk with multiple clients•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()

create socket,port=x, forincoming request:welcomeSocket =

ServerSocket()

create socket,connect to hostid, port=xclientSocket =

Socket()

closeconnectionSocket

read reply fromclientSocket

closeclientSocket

Server (running on hostid) Client

send request usingclientSocketread request from

connectionSocket

write reply toconnectionSocket

TCP connection setup


Socket programming with UDP

UDP: no “connection” between client and server•no handshaking•sender explicitly attaches IP address and port of destination to each packet•server must extract IP address, port of sender from received packet

UDP: transmitted data may be received out of order, or lost

application viewpoint

UDP provides unreliable transfer of groups of bytes (“datagrams”)

between client and server


Client/server socket interaction: UDP

Server (running on hostid)

closeclientSocket

read datagram fromclientSocket

create socket,clientSocket = DatagramSocket()

Client

Create datagram with server IP andport=x; send datagram via clientSocket

create socket,port= x.serverSocket = DatagramSocket()

read datagram fromserverSocket

write reply toserverSocketspecifying client address,port number


Application Designbased on

TCP or UDP


Application Design

• Application Architecure to choose?• Client-Server architecture

• Peer-to- peer architecture

• Hybrid of client-server and P2P

• What services do the application requires?• TCP

• UDP


Client-server architecture

server:

•always-on host•permanent IP address•server farms for scaling

clients:•communicate with server•may be intermittently connected•may have dynamic IP addresses•do not communicate directly with each other

client/server


Pure P2P architecture

•no always-on server

•arbitrary end systems directly communicate

•peers are intermittently connected and change IP addresses

Highly scalable but difficult to manage

peer-peer


Hybrid of client-server and P2P

Skype• 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/location

• user registers its IP address with central server when it comes online

• user contacts central server to find IP addresses of buddies


Application Design

• Application Designers should be aware of:• Silly Window Syndrome

•


Silly Window Syndrome

• Problem• Sender only creates data slowly, or

• Receiver consumes data slowly.

• Example• Packet size 5 – 10 bytes + 20 bytes (TCP Hdr) + 20 IP Hdr => total

of 45-50 bytes • Network capacity used ineffeciently• => adds to congestion in the network


Syndrome created by the sender

Nagle’s Algorithm

1. The sending TCP sends the first piece of data it receives from the sending application even if it is only 1 byte

2. After sending the first segment, the sending TCP accumelates data in the output buffer and waits until either the receiving TCP sends ACK or until enough data has accumelated to fill a maximum-size segment. At this time the sending TCP can send a segment

3. Step 2 is repeated for the rest of the transmission


Syndrome created by the sender

Nagle’s Algorithm Effect

• If sending application is faster than network:• Transmission buffer becomes full =>• Segments are larger (maximum-size segments)

• If network is faster than sending application:• ACKs received before buffer is full =>• Segments are smaller

How to enable Nagle’s Algorithm:

Socket option: TCP_NODELAY


Syndrome created by the receiver

1. Sender creates data in blocks of 1kbyte2. Receiver consumes data 1 byte at a time3. Receiver buffer is 4 kbytes4. Sender sends 4 kbytes of data5. Receiver advertises a window size of zero6. Sender stops sending data7. Receiving application reads 1 byte8. Receiving TCP announces a window size of 1 byte9. Sending TCP sends 1 byte of data

Inefficient usage of network


Syndrome created by the receiver

Clark’s Solution

Send ACK as soon as the data arrives, but Announce a window size of zero until either there is enough space to accommodate a segment of max. Size or until half of the buffer is empty

Delayed Acknowledgement

Delay sending ACK. The receiver waits until there is a decent amount of space in its incoming buffer before acknowledging the arrived segments. => Sender can not slid its window, and stops sending data.

What happens if we wait to long before sending ACK?


Question & repetition


Eksamen er uden forberedelse

Eksamensspørgsmål udleveres

Application Design based on TCP or UDP

Documents

Transcript of Application Design based on TCP or UDP