How SSDP Uses UDP for UPnP Device Discovery

The Simple Service Discovery Protocol (SSDP) serves as the discovery foundation for Universal Plug and Play (UPnP) architectures, enabling networked devices to automatically discover one another and advertise their services. By utilizing the User Datagram Protocol (UDP) instead of connection-oriented protocols like TCP, SSDP provides a lightweight, connectionless mechanism for rapid multicast communication across local networks. This article explains how SSDP leverages UDP multicast and unicast messaging to announce device presence, search for available network services, and establish seamless plug-and-play connectivity without requiring manual user configuration or centralized directory servers.

The Role of UDP in SSDP

SSDP relies on HTTP over UDP, often referred to as HTTPU (HTTP Unicast/Multicast over UDP). Standard HTTP operations rely on TCP to maintain a reliable, dedicated connection between a client and a server. In contrast, local network discovery benefits from broadcasting messages simultaneously to multiple devices. UDP is inherently connectionless and supports multicast transmission, making it the ideal transport layer protocol for SSDP.

SSDP operates over standard reserved networking endpoints: * Port: UDP port 1900 * IPv4 Multicast Address: 239.255.255.250 * IPv6 Multicast Address: [FF02::C] (link-local) or [FF05::C] (site-local)

Device Advertisement: The NOTIFY Method

When a UPnP-compatible device (such as a media server, printer, or smart router) connects to a local network, it must inform other nodes of its existence and available capabilities. It achieves this by sending multicast UDP datagrams to the SSDP multicast group address on port 1900 using the NOTIFY method.

These advertisements contain standard HTTP-style headers, including: * NT (Notification Type): Identifies the device type or service being advertised. * NTS (Notification Sub-Type): Indicates the event type, commonly ssdp:alive when the device joins the network or renews its lease, and ssdp:byebye when gracefully disconnecting. * LOCATION: Contains a URL (typically HTTP over TCP) pointing to the device’s XML description file, which outlines its full capabilities and control endpoints. * CACHE-CONTROL: Specifies the duration (in seconds) that other devices should consider the advertisement valid before discarding it. * USN (Unique Service Name): A unique identifier for the specific device instance or service.

Because UDP does not guarantee delivery, devices typically broadcast ssdp:alive notifications multiple times upon startup to minimize the risk of dropped packets.

Service Discovery: The M-SEARCH Method

When a control point (such as a smartphone, PC, or application) wants to find devices on the network, it does not need to query individual IP addresses. Instead, it sends an active discovery request using the M-SEARCH method over UDP multicast to 239.255.255.250:1900.

The M-SEARCH request defines search criteria using the ST (Search Target) header. A control point can search for: * All available devices (ST: ssdp:all) * Root devices only (ST: upnp:rootdevice) * A specific device type or unique service identifier

Any device on the local network listening on UDP port 1900 that matches the ST criteria processes the request. To prevent network congestion caused by simultaneous replies, the M-SEARCH request includes an MX (Maximum Wait Time) header, instructing devices to randomize their response delay within the specified window (e.g., 1 to 5 seconds).

Unicast UDP Responses

While discovery queries and presence notifications use UDP multicast to reach the entire subnet, the response to an M-SEARCH request is sent via unicast UDP.

The responding device sends an HTTP/1.1 200 OK datagram directly back to the IP address and UDP port from which the control point initiated the search. This response includes the device’s LOCATION, ST, USN, and CACHE-CONTROL headers. Once the control point receives this UDP datagram, it switches from SSDP to standard TCP-based HTTP requests to download the XML device description file indicated in the LOCATION header and begin direct control interactions.