Application Design based on TCP or UDP

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. 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 TCP/UPD: Transport services IHA præsentation

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

5. 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 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 logical end-end transport Internet transport-layer protocols IHA præsentation

6. 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! UDP: more 32 bits source port # dest port # Length, in bytes of UDP segment, including header checksum length Application data (message) UDP segment format IHA præsentation

7. 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? UDP checksum Goal: detect “errors” (e.g., flipped bits) in transmitted segment IHA præsentation

8. 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 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 IHA præsentation

9. 32 bits source port # dest port # sequence number acknowledgement number head len not used Receive window U A P R S F checksum Urg data pnter Options (variable length) application data (variable length) 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) IHA præsentation

10. 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 time TCP seq. #’s and ACKs Host B Host A User types ‘C’ Seq=42, ACK=79, data = ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ Seq=79, ACK=43, data = ‘C’ host ACKs receipt of echoed ‘C’ Seq=43, ACK=80 simple telnet scenario IHA præsentation

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

12. Socket Programming IHA præsentation

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

14. process process TCP with buffers, variables TCP with buffers, variables socket socket Socket-programming using TCP Socket: a door between application process and end-end-transport protocol (UCP or TCP) TCP service: reliable transfer of bytesfrom 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 IHA præsentation

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

16. 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 identifierincludes 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 Addressing processes IHA præsentation

17. 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 Socket programming with TCP IHA præsentation

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

19. 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 UDP provides unreliable transfer of groups of bytes (“datagrams”) between client and server application viewpoint Socket programming with UDP IHA præsentation

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

21. Application Designbased onTCP or UDP IHA præsentation

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

23. client/server 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 IHA præsentation

24. peer-peer 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 IHA præsentation

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

26. Application Design • Application Designers should be aware of: • Silly Window Syndrome IHA præsentation

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 => total of 45-50 bytes • Network capacity used ineffeciently • => adds to congestion in the network IHA præsentation

28. Syndrome created by the sender • Nagle’s Algorithm • Thesending 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 IHA præsentation

29. 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æsentation

30. Syndrome 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 IHA præsentation

31. 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æsentation

32. Question & repetition IHA præsentation

33. Eksamen er uden forberedelse Eksamensspørgsmål udleveres IHA præsentation