Summary

  • RFC 3082 lets a user agent subscribe to service changes instead of repeatedly polling, with different notification designs for networks with and without Directory Agents.
  • If a DA disappears, service agents already told to notify can continue sending, while a newly arriving agent may miss the subscription. Continued old notices are not proof that new-service coverage survived.

A query is not a feed

The Service Location Protocol began with a deliberate asymmetry: service agents (SAs) advertised services, and user agents (UAs) asked for them when needed. That kept routine discovery demand-driven. An application that wanted its local view updated whenever a service appeared or vanished had to poll. RFC 3082, published in March 2001 as an Experimental Protocol, proposed a change feed so that such clients would not have to ask the network over and over. It did not become an Internet Standard.

The distinction sounds simple—ask once, then listen—but a notification system needs to answer another question: who tells a newly arrived sender that someone is listening? RFC 3082 gives that job to the network’s agents in two different ways, depending on whether Directory Agents (DAs) exist. The failure case is revealing because these agents do not hold one interchangeable copy of the same state.

Two topologies, two notification costs

In a small network without DAs, an SA announces registration and deregistration broadly by IP multicast, or IPv4 broadcast when multicast is unavailable. UAs receive notices for more service types and scopes than they may care about, then filter locally. That avoids needing a broker to tell a new SA which subscriptions exist, but pushes filtering to listeners and makes multicast reach and scope important.

In a larger DA-based network, a UA sends a Subscribe extension with a service request. The DA returns NotifyAt information identifying multicast groups for the requested service type and scopes. It can announce a new subscription to existing SAs; when a matching new SA registers, its SrvAck can carry the same NotifyAt instruction. The DA also issues a deregistration notice when an advertisement expires without an orderly shutdown. Most event announcements are still made by SAs, not relayed as a central stream by the DA.

The design distributes work, but it also distributes state. A DA tracks subscriptions; existing SAs learn group addresses; a UA joins those groups; and the multicast-address allocation has its own scope and lease. The DA waits a random zero to three seconds before announcing a newly seen subscription and suppresses its own announcement if it hears a matching one from another DA. That reduces duplicate notices. It does not replicate the UA’s subscription table or make multiple DAs one durable database.

What disappears—and what keeps going

Section 10 is unusually explicit about the partial failure. When a DA vanishes unexpectedly, the UA subscription information stored there is lost. UAs continue to receive notifications from existing SAs, because those SAs already received NotifyAt. But a new SA will not be informed of the subscription unless another DA also has that information.

The UA may not discover an alternate DA until it makes an active request. So a service can register after the old DA disappears but before the UA has discovered and subscribed through another DA. The already-known services may keep appearing in the feed; the newcomer may never appear there. The visible stream can look alive while its coverage has a hole.

RFC 3082 has a recovery path for old senders. They continue until subscription expiry; if no other DA is available, they ignore that expiry and keep notifying until a new DA is found. After registering with the new DA, an SA can learn from SrvAck whether the UA renewed. But the RFC itself notes the residual window: the procedure still does not inform SAs that start between the rebooted DA becoming available and the UA renewing its subscription. A UA concerned about every new service should subscribe to every newly discovered DA supporting its scopes. Redundant hardware alone cannot provide that coverage unless subscription state is present at the relevant DAs.

A notice is an observation, not a completed transaction

The rest of the protocol reinforces the need to keep records separate. Multicast announcements are repeated with exponential backoff for fifteen seconds. The stated purpose is to increase the probability that a message gets through, not to guarantee delivery or create a durable event log. A registration notification may overflow a UDP packet; its overflow bit tells a UA that it may need a later query to the SA or DA for missing attributes.

RFC 3082 also describes authentication blocks that a UA can verify, but authenticating a message does not prove that every listener received it, that the endpoint remains reachable, or that an application completed a transaction.

The useful operational chain is therefore: a UA’s subscription; a DA’s stored scope-and-type state; a NotifyAt instruction reaching an SA; multicast group membership; an event being emitted; a listener actually receiving it; a follow-up query if the payload is incomplete; and, separately, a usable service exchange. RFC 3082 specifies mechanisms for some transitions, but it does not collapse them into one end-to-end receipt.

That makes the title’s two halves compatible. RFC 3082 does not say that one DA failure silences the network. Existing SAs may continue, and alternate DAs may preserve coverage. It says something narrower and more useful: continuity for senders already informed is not the same as discovery coverage for senders that arrive later. Replacing polling with notifications changes where the system must remember who is listening—and which recovery step restores that memory.

Sources

Protocol and historical record: RFC 3082, RFC Editor record, Datatracker history, RFC 2608: SLPv2, RFC 2119, RFC 2373, RFC 2730, and RFC 2908. Editorial lenses only, not evidence for SLP behavior: Lu Heng, Running-Code Primacy and On Reality Layers.