IHA præsentation1 Application Design based on TCP or UDP Lesson 6

IHA præsentation2 Outline for today The Internet Protocols: UDP & TCP Socket programming Application Design based on TCP/UPD

IHA præsentation3 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 transport network data link physical application transport network data link physical logical end-end transport

IHA præsentation4 Transport vs. network layer network layer: logical communication between hosts transport layer: logical communication between processes relies on, enhances, network layer services

IHA præsentation5 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 transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical application transport network data link physical logical end-end transport

IHA præsentation6 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 Application data (message) UDP segment format length checksum Length, in bytes of UDP segment, including header

IHA præsentation7 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æsentation8 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

IHA præsentation9 TCP segment structure source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number Receive window Urg data pnter checksum F SR PAU head len not used 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 willing to accept counting by bytes of data (not segments!) Internet checksum (as in UDP)

IHA præsentation10 TCP seq. #’s and ACKs Seq. #’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 User types ‘C’ host ACKs receipt of echoed ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ time simple telnet scenario

IHA præsentation11 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.

IHA præsentation12 Socket Programming

IHA præsentation13 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

IHA præsentation14 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 with buffers, variables socket controlled by application developer controlled by operating system host or server process TCP with buffers, variables socket controlled by application developer controlled by operating system host or server internet

IHA præsentation15 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?

IHA præsentation16 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: Port number: 80

IHA præsentation17 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

IHA præsentation18 Client/server socket interaction: TCP wait for incoming connection request connectionSocket = welcomeSocket.accept() create socket, port= x, for incoming request: welcomeSocket = ServerSocket() create socket, connect to hostid, port= x clientSocket = Socket() close connectionSocket read reply from clientSocket close clientSocket Server (running on hostid ) Client send request using clientSocket read request from connectionSocket write reply to connectionSocket TCP connection setup

IHA præsentation19 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

IHA præsentation20 Client/server socket interaction: UDP Server (running on hostid ) close clientSocket read datagram from clientSocket create socket, clientSocket = DatagramSocket() Client Create datagram with server IP and port=x; send datagram via clientSocket create socket, port= x. serverSocket = DatagramSocket() read datagram from serverSocket write reply to serverSocket specifying client address, port number

IHA præsentation21 Application Design based on TCP or UDP

IHA præsentation22 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

IHA præsentation23 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

IHA præsentation24 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

IHA præsentation25 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

IHA præsentation26 Application Design Application Designers should be aware of: Silly Window Syndrome

IHA præsentation27 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 bytes Network capacity used ineffeciently => adds to congestion in the network

IHA præsentation28 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

IHA præsentation29 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

IHA præsentation30 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

IHA præsentation31 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?

IHA præsentation32 Question & repetition

IHA præsentation33 Eksamen er uden forberedelse Eksamensspørgsmål udleveres