Chapter 6 Datagram Delivery by UDP

1. Chapter 6 Datagram Delivery by UDP Just as the Internet Protocol uses the services of subnetworks, transport protocols build upon the services of IP. They rely on IP to deliver packets to the right place, and then they take over. Transport protocols have two major responsibilities. First, they must distinguish the traffic of different applications within a system. The second obligation facing a transport protocol is reliability. Recall that IP cannot guarantee delivery of packets. Nor does it typically ensure that the data within those packets arrives free from corruption. Transport protocols compensate for these problems, although different transport protocols compensate in different ways, and to different degrees.

2. Chapter 6 Datagram Delivery by UDP This chapter considers the simplest level of service--datagram delivery. Datagram delivery is not a guaranteed service, but it does protect against corruption The specific transport protocol that provides TCP/IP’s datagram delivery service is the User Datagram protocol, or UDP.

3. Chapter 6 Datagram Delivery by UDP Distinguishing Applications

4. Chapter 6 Datagram Delivery by UDP Distinguishing Applications

5. Chapter 6 Datagram Delivery by UDP Ports To identify different applications, TCP/IP protocols tag each packet with a number known as a port. Different applications use different values for port fields, and a transport protocol can use the port value to decide which application should receive a packet’s data. In this way, the port value acts like the IP next header field. The next header value distinguishes different transport protocols for IP, and the port values distinguishes different application protocols for a transport protocol.

6. Chapter 6 Datagram Delivery by UDP Ports Applications select a port in one of two ways. The two approaches correspond to the two roles that an application can play in a conversation. These roles correspond to a client and a server. When a client application needs to make a request, it must know how to get that request to a server; it must know, in advance, which port value to use for the particular application. A server, on the other hand, doesn’t have to know the port value to use for its response. It can have the client designate a port as part of the initial request.

7. Chapter 6 Datagram Delivery by UDP Ports Internet Protocol Encapsulation of data Data AP Protocol Header 16-bit port # TCP, UDP Header 32-bit address IP header 48-bit address Ethernet header Ethernet trailer

8. Chapter 6 Datagram Delivery by UDP Ports Port values that are predefined for specific applications are well-known ports.

9. Chapter 6 Datagram Delivery by UDP Ports Part of /etc/services file in www.csie.ndhu.edu.tw echo 7/udp discard 9/udp sink null daytime 13/udp chargen 19/udp ttytst source time 37/udp timserver name 42/udp nameserver domain 53/udp sunrpc 111/udp rpcbind tftp 69/udp ntp 123/udp # Network Time Protocol

10. Chapter 6 Datagram Delivery by UDP Ports biff 512/udp comsat who 513/udp whod syslog 514/udp talk 517/udp route 520/udp router routed new-rwho 550/udp new-who # experimental rmonitor 560/udp rmonitord # experimental monitor 561/udp # experimental kerberos 750/udp kdc # Kerberos key server ufsd 1008/udp ufsd nfsd 2049/udp nfs # NFS server daemon (clts) lockd 4045/udp # NFS lock daemon/manager bootps 67/udp # Bootstrap Protocol Server bootpc 68/udp # Bootstrap Protocol Client

11. Chapter 6 Datagram Delivery by UDP Ports • There are two ways for a process to have an Internet port assigned: • The process can request a specific port (from 5000 ~) • The process can let the system automatically assign a port For Internet Protocol: 1-1023: reserved ports 512-1023: ports assigned by rresvport() 1024-5000: ports automatically assigned by system 5001-65535: used by user

12. Chapter 6 Datagram Delivery by UDP Sockets By themselves, ports merely define application protocols. They do not identify actual application programs running in real machines. By combining port value with a network address, however, just such a distinction is possible. The combination is known as a socket. Different sockets can have the same values for both their port and network address.

13. Chapter 6 Datagram Delivery by UDP Sockets Same port, same IP address

14. Chapter 6 Datagram Delivery by UDP Sockets Socket Programming Iterative vs. Concurrent Server iterative server concurrent server connection-oriented protocol infrequent (Daytime) typical connectionless protocol typical infrequent (TFTP) Socket system calls Server Client create endpoint: socket() bind address: bind() specify queue: listen() wait for connection: accept() create endpoint: socket() bind address: bind() connect to server: connect() Transfer data: read(), write(0, recv(), send(), recvfrom(), sendto() Terminate: close(), shutdown()

15. Chapter 6 Datagram Delivery by UDP Sockets Socket Programming connection-oriented protocol blocked until connection from client socket() bind() listen() accept() read() write() reply request Client: socket() connect() write() read() connectionless protocol socket() bind() recvfrom() sendto() request reply Client: socket() bind() sendto() recvfrom()

16. Chapter 6 Datagram Delivery by UDP Sockets Socket Programming An Association {protocol, local-addr, local-process, foreign-addr, foreign-process} {udp, 203.64.100.101, 20, 203.64.80.11, 30} protocol local-addr, foreign addr, local-process foreign-process connection-oriented server socket() bind() listen(), accept() connection-oriented client socket() connect() connectionless server socket() bind() recvfrom() connectionless client socket() bind() sendto()

17. Chapter 6 Datagram Delivery by UDP Sockets Socket Programming Typical scenario for a concurrent server (connection-oriented) int sockfd,newsockfd; if ((sockfd=socket(...))<0) err_sys("socket error"); if ((bind(sockfd,...)<0) err_sys("bind error"); if (listen(sockfd,5)<0) err_sys("listen error"); for (;;) { newsockfd=accept(sockfd,...); /* 5-tuple association determined by accept system call for newsockfd */ if (newsockfd<0) err_sys("accept error"); if (fork()==0) { close(sockfd); /*child process */ doit(newsockfd); /* process the request */ exit(0); } close(newsockfd); /* parent */ }

18. Chapter 6 Datagram Delivery by UDP Datagram Delivery • UDP provides a particular type of service to applications called • datagram delivery. Datagram delivery is a connectionless service, • which means: • each datagram exists entirely independently of all other datagrams, even datagrams between the same sockets • there is no reference to tie multiple datagrams together • there is no mechanism that allows a receiver to acknowledge reception of a datagram • there is no reference that can establish a relative ordering of different datagrams

19. Chapter 6 Datagram Delivery by UDP Datagram Delivery In practice, this means that UDP provides a best effort delivery. That is, it does its best to transfer datagrams for its applications, but UDP makes no guarantees. Datagrams may get reordered, even lost, in transit, and the applications must be prepared for such event. UDP does provide one enhancement to the network service available from IP. It includes simple error-checking that can detect corrupted datagrams.

20. Chapter 6 Datagram Delivery by UDP Datagram Delivery The application has to handle the lost of packet 2 by itself.

21. Chapter 6 Datagram Delivery by UDP Datagram Delivery Datagrams experienced larger delay in Router B.

22. Chapter 6 Datagram Delivery by UDP User Datagram Protocol Why an application would use UDP instead of TCP. The answer lies in UDP’s simplicity. Since UDP has no connections, applications do not have to establish or clear them. When an application has data to send, it just sends them. This approach make things simpler for the application, and it can eliminate a substantial delay in communication. UDP is also ideal for those systems that are so limited that they cannot afford to implement TCP.

23. Chapter 6 Datagram Delivery by UDP User Datagram Protocol UDP header+data

24. Chapter 6 Datagram Delivery by UDP User Datagram Protocol With IPv4, however, a sender could effectively omit the checksum by setting its value to zero. Receivers disregarded the checksum. Even though this omission is no longer legal in IPv6, IPv6 implementations must still be prepared to receive UDP datagrams from systems using IPv4. Pseudo header

25. Chapter 6 Datagram Delivery by UDP User Datagram Protocol IPv4 UDP’s pseudo header for computing checksum Source IP Address Destination IP Address Zero protocol(17) UDP length

26. Chapter 6 Datagram Delivery by UDP User Datagram Protocol Constructing the UDP checksum 1. Prepend the pseudo header to the UDP datagram 2. If the application data contains an odd number of bytes, append a final byte of zero. (Do not increase the payload length or datagram length to include this byte.) 3. Set the checksum field to zero. 4. Calculate the sum of the resulting series of 16-bit values, using one’s complement arithmetic. 5. Use the complement of the summation result as the checksum.

27. Chapter 6 Datagram Delivery by UDP User Datagram Protocol Validating the UDP checksum 1. If the checksum value is zero, assume it is correct and skip the remaining steps. 2. Prepend the pseudo header to the UDP datagram 3. If the application data contains an odd number of bytes, append a final byte of zero. (Do not increase the payload length or datagram length to include this byte.) 4. Calculate the sum of the resulting series of 16-bit values, using one’s complement arithmetic. 5. If the result of this summation is 0xFFFF, the checksum is valid; otherwise, the checksum is invalid.