Transport Overview and UDP Transport Layer 1 Goals












![UDP: User Datagram Protocol [RFC 768] r “no frills, ” “bare bones” Internet transport UDP: User Datagram Protocol [RFC 768] r “no frills, ” “bare bones” Internet transport](https://slidetodoc.com/presentation_image_h/e2276723cfb39515583b7d841da9fa5a/image-13.jpg)



- Slides: 16
Transport Overview and UDP Transport Layer 1
Goals r Understand transport services m Multiplexing and Demultiplexing m Reliable data transfer m Flow control m Congestion control r TCP and UDP Transport Layer 2
Transport services and protocols r provide logical communication network data link physical nd -e nd le ca gi lo network data link physical t or sp an tr between app processes running on different hosts r transport protocols run in end systems m send side: breaks app messages into segments, passes to network layer m rcv side: reassembles segments into messages, passes to app layer r more than one transport protocol available to apps m Internet: TCP and UDP application transport network data link physical Transport Layer 3
Transport vs. network layer r network layer: logical communication between hosts r transport layer: logical communication between processes m relies on, enhances, network layer services Household analogy: 12 kids sending letters to 12 kids r processes = kids r app messages = letters in envelopes r hosts = houses r transport protocol = Ann and Bill r network-layer protocol = postal service Transport Layer 4
Internet transport-layer protocols r reliable, in-order delivery (TCP) r services not available: m delay guarantees m bandwidth guarantees network data link physical t or sp no-frills extension of “best-effort” IP network data link physical an tr m nd delivery: UDP -e nd r unreliable, unordered le m network data link physical ca gi m congestion control flow control connection setup network data link physical lo m application transport network data link physical Transport Layer 5
Multiplexing/demultiplexing Multiplexing at send host: gathering data from multiple sockets, enveloping data with header (later used for demultiplexing) Demultiplexing at rcv host: delivering received segments to correct socket = socket application transport network link = process P 3 P 1 application transport network P 2 P 4 application transport network link physical host 1 physical host 2 physical host 3 Transport Layer 6
How demultiplexing works r host receives IP datagrams each datagram has source IP address, destination IP address m each datagram carries 1 transport-layer segment m each segment has source, destination port number (recall: well-known port numbers for specific applications) r host uses IP addresses & port numbers to direct segment to appropriate socket m 32 bits source port # dest port # other header fields application data (message) TCP/UDP segment format Transport Layer 7
Connectionless demultiplexing r Create sockets with port numbers: Datagram. Socket my. Socket 1 = new Datagram. Socket(99111); Datagram. Socket my. Socket 2 = new Datagram. Socket(99222); r UDP socket identified by two-tuple: (dest IP address, dest port number) r When host receives UDP segment: m m checks destination port number in segment directs UDP segment to socket with that port number r IP datagrams with different source IP addresses and/or source port numbers directed to same socket Transport Layer 8
Connectionless demux (cont) Datagram. Socket server. Socket = new Datagram. Socket(6428); P 2 SP: 6428 DP: 9157 SP: 6428 DP: 5775 SP: 9157 client IP: A P 1 P 3 DP: 6428 server IP: C SP: 5775 DP: 6428 Client IP: B SP provides “return address” Transport Layer 9
Connection-oriented demux r TCP socket identified by 4 -tuple: m m source IP address source port number dest IP address dest port number r recv host uses all four values to direct segment to appropriate socket r Server host may support many simultaneous TCP sockets: m each socket identified by its own 4 -tuple r Web servers have different sockets for each connecting client m non-persistent HTTP will have different socket for each request Transport Layer 10
Connection-oriented demux (cont) P 1 P 4 P 5 P 2 P 6 P 1 P 3 SP: 5775 DP: 80 S-IP: B D-IP: C client IP: A SP: 9157 DP: 80 S-IP: A D-IP: C SP: 9157 server IP: C DP: 80 S-IP: B D-IP: C Client IP: B Transport Layer 11
Connection-oriented demux: Threaded Web Server P 1 P 2 P 4 P 1 P 3 SP: 5775 DP: 80 S-IP: B D-IP: C client IP: A SP: 9157 DP: 80 S-IP: A D-IP: C SP: 9157 server IP: C DP: 80 S-IP: B D-IP: C Client IP: B Transport Layer 12
UDP: User Datagram Protocol [RFC 768] r “no frills, ” “bare bones” Internet transport protocol r “best effort” service, UDP segments may be: m lost m delivered out of order to app r connectionless: m no handshaking between UDP sender, receiver m each UDP segment handled independently of others Transport Layer 13
UDP: more r often used for streaming multimedia apps m loss tolerant m rate sensitive Length, in bytes of UDP segment, including header r other UDP uses m DNS m SNMP r reliable transfer over UDP: add reliability at application layer m application-specific error recovery! 32 bits source port # dest port # length checksum Application data (message) UDP segment format Transport Layer 14
UDP checksum Goal: detect “errors” (e. g. , flipped bits) in transmitted segment Sender: Receiver: r treat segment contents as r compute checksum of sequence of 16 -bit integers r checksum: addition (1’s complement sum) of segment contents r sender puts checksum value into UDP checksum field received segment r check if computed checksum equals checksum field value: m NO - error detected m YES - no error detected. But maybe errors nonetheless? More later …. Transport Layer 15
Internet Checksum Example r Note m When adding numbers, a carryout from the most significant bit needs to be added to the result r Example: add two 16 -bit integers 1 1 0 0 1 1 1 0 1 0 1 wraparound 1 1 0 1 1 sum 1 1 0 1 1 0 0 checksum 1 0 0 0 0 1 1 Transport Layer 16