Title: Application Design based on TCP or UDP
1Application Design based on TCP or UDP
2Outline for today
- The Internet Protocols UDP TCP
- Socket programming
- Application Design based on TCP/UPD
3TCP/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
4Transport vs. network layer
- network layer logical communication between
hosts - transport layer logical communication between
processes - relies on, enhances, network layer services
5Internet 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
6UDP 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!
32 bits
source port
dest port
Length, in bytes of UDP segment, including header
checksum
length
Application data (message)
UDP segment format
7UDP checksum
- Goal detect errors (e.g., flipped bits) in
transmitted segment
- Sender
- treat segment contents as sequence of 16-bit
integers - checksum addition (1s 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?
8TCP Overview RFCs 793, 1122, 1323, 2018, 2581
- 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
- full duplex data
- bi-directional data flow in same connection
- MSS maximum segment size
- connection-oriented
- handshaking (exchange of control msgs) inits
sender, receiver state before data exchange - flow controlled
- sender will not overwhelm receiver
9TCP segment structure
URG urgent data (generally not used)
counting by bytes of data (not segments!)
ACK ACK valid
PSH push data now (generally not used)
bytes rcvr willing to accept
RST, SYN, FIN connection estab (setup,
teardown commands)
Internet checksum (as in UDP)
10TCP seq. s and ACKs
- Seq. s
- byte stream number of first byte in segments
data - ACKs
- seq of next byte expected from other side
- cumulative ACK
- Q how receiver handles out-of-order segments
- A TCP spec doesnt say, - up to implementor
Host B
Host A
User types C
Seq42, ACK79, data C
host ACKs receipt of C, echoes back C
Seq79, ACK43, data C
host ACKs receipt of echoed C
Seq43, ACK80
simple telnet scenario
11Question
- 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.
12Socket Programming
13Socket programming
Goal learn how to build client/server
application that communicate using sockets
- 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
14Socket-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
controlled by application developer
controlled by application developer
controlled by operating system
controlled by operating system
internet
host or server
host or server
15Addressing 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?
16Addressing 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
17Socket programming with TCP
- Client must contact server
- server process must first be running
- server must have created socket (door) that
welcomes clients 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)
18Client/server socket interaction TCP
Server (running on hostid)
Client
19Socket 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
20Client/server socket interaction UDP
Server (running on hostid)
create socket, port x.
serverSocket DatagramSocket()
21Application Designbased onTCP or UDP
22Application 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
23Client-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
24Pure 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
25Hybrid 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
26Application Design
- Application Designers should be aware of
- Silly Window Syndrome
-
27Silly 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 gt total of 45-50 bytes - Network capacity used ineffeciently
- gt adds to congestion in the network
28Syndrome created by the sender
- Nagles Algorithm
- The sending TCP sends the first piece of data it
receives from the sending application even if it
is only 1 byte - 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 - Step 2 is repeated for the rest of the
transmission
29Syndrome created by the sender
- Nagles Algorithm Effect
- If sending application is faster than network
- Transmission buffer becomes full gt
- Segments are larger (maximum-size segments)
- If network is faster than sending application
- ACKs received before buffer is full gt
- Segments are smaller
How to enable Nagles Algorithm Socket option
TCP_NODELAY
30Syndrome created by the receiver
- Sender creates data in blocks of 1kbyte
- Receiver consumes data 1 byte at a time
- Receiver buffer is 4 kbytes
- Sender sends 4 kbytes of data
- Receiver advertises a window size of zero
- Sender stops sending data
- Receiving application reads 1 byte
- Receiving TCP announces a window size of 1 byte
- Sending TCP sends 1 byte of data
Inefficient usage of network
31Syndrome created by the receiver
- Clarks 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. gt Sender can not slid its
window, and stops sending data.
What happens if we wait to long before sending
ACK?
32Question repetition
33Eksamen er uden forberedelse Eksamensspørgsmål
udleveres