- Forward


User Datagram Protocol (UDP)
An Introduction


Prof. David Bernstein
James Madison University

Computer Science Department
bernstdh@jmu.edu

Print

Overview
Back SMYC Forward
  • Specification:
    • RFC 768
  • Purpose:
    • Provide a mechanism for applications to send and receive messages
  • Assumptions:
    • IP is used as the underlying network/internetwork layer protocol
    • Applications are associated with ports
Properties
Back SMYC Forward
  • Not Connection/Session-Oriented:
    • No handshaking
    • No state information
  • Unreliable:
    • Delivery is not guaranteed
    • Order is not guaranteed
    • Duplication protection is not provided
  • Message-Oriented:
    • Transmission of complete messages
  • Not Controlled:
    • No flow control
    • No congestion control
The Demultiplexing Process
Back SMYC Forward
  • Recall:
    • UDP needs to know what process/application to deliver datagrams to
  • The Socket:
    • The process/application can be characterized by a two-tuple (called a socket) consisting of the destination IP address (which is in the IP frame) and port (which is in the UDP frame)
Moving through the Stack/Layers
Back SMYC Forward
  • Moving Down:
    • The UDP segment becomes the payload of the IP datagram
  • Moving Up:
    • The payload of the UDP datagram is handed off to the process bound to the destination port
Required Functionality of "Receivers"
Back SMYC Forward
  1. Create a "receiver" on a particular port
  2. Receive datagrams from any address/port
Required Functionality of "Senders"
Back SMYC Forward
  1. Create a "sender" on any port
  2. Send datagrams to a particular address/port
Header Format
Back SMYC Forward
  • Source Port (16 bits) [optional]
  • Destination Port (16 bits)
  • Length in Octets (16 bits) [includes the 8 octets in the header]
  • Checksum (16 bits) [optional]
Common Application-Layer Protocol Styles Using UDP
Back SMYC Forward
  • Sender and Receiver:
    • One participant sends (periodic) messages
    • One participant receives (periodic) messages
  • Requestor and Responder:
    • One participant sends (periodic) requests
    • One participant responds to (periodic) requests
  • Registrant and Responder:
    • One participant registers and later unregisters
    • One participant maintains a list of registered participants and sends to them
  • Registrant and Responder with Heartbeat/Confirmation:
    • One participant registers and later unregisters
    • One participant maintains a list of registered participants and sends to them
    • Either the registrant periodically sends a heartbeat or the registrar periodically requests confirmation
There's Always More to Learn
Back -