Application Design based on TCP or UDP

1
Application Design based on TCP or UDP

• Lesson 6

2
Outline for today

• The Internet Protocols UDP TCP
• Socket programming
• Application Design based on TCP/UPD

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

4
Transport vs. network layer

• network layer logical communication between
  hosts
• transport layer logical communication between
  processes
• relies on, enhances, network layer services

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

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!

32 bits
source port
dest port
Length, in bytes of UDP segment, including header
checksum
length
Application data (message)
UDP segment format
7
UDP 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?

8
TCP 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

9
TCP 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)
10
TCP 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
11
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.
12
Socket Programming
13
Socket 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

14
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

controlled by application developer
controlled by application developer
controlled by operating system
controlled by operating system
internet
host or server
host or server
15
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?

16
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

17
Socket 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)

18
Client/server socket interaction TCP
Server (running on hostid)
Client
19
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

20
Client/server socket interaction UDP
Server (running on hostid)
create socket, port x.
serverSocket DatagramSocket()
21
Application Designbased onTCP or UDP
22
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

23
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

24
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

25
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

26
Application Design

• Application Designers should be aware of
• Silly Window Syndrome

27
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 gt total of 45-50 bytes
• Network capacity used ineffeciently
• gt adds to congestion in the network

28
Syndrome 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

29
Syndrome 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
30
Syndrome created by the receiver

1. Sender creates data in blocks of 1kbyte
2. Receiver consumes data 1 byte at a time
3. Receiver buffer is 4 kbytes
4. Sender sends 4 kbytes of data
5. Receiver advertises a window size of zero
6. Sender stops sending data
7. Receiving application reads 1 byte
8. Receiving TCP announces a window size of 1 byte
9. Sending TCP sends 1 byte of data

Inefficient usage of network
31
Syndrome 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?
32
Question repetition
33
Eksamen er uden forberedelse Eksamensspørgsmål
udleveres