Subscriber Interactions

Subscribers subscribe to tracks by sending a SUBSCRIBE (Section 7.4) control message for each track of interest. Relays MUST ensure subscribers are authorized to access the content associated with the track. The authorization information can be part of subscription request itself or part of the encompassing session. The specifics of how a relay authorizes a user are outside the scope of this specification.

The relay will have to send an upstream SUBSCRIBE and/or FETCH if it does not have all the objects in the FETCH, or is not currently subscribed to the full requested range. In this case, it SHOULD withhold sending its own SUBSCRIBE_OK until receiving one from upstream. It MUST withhold FETCH_OK until receiving one from upstream.

For successful subscriptions, the publisher maintains a list of subscribers for each track. Each new OBJECT belonging to the track within the subscription range is forwarded to each active subscriber, dependent on the congestion response.

A caching relay saves Objects to its cache identified by the Object's Full Track Name, Group ID and Object ID. Relays MUST be able to process objects for the same Full Track Name from multiple publishers and forward objects to active matching subscriptions. If multiple objects are received with the same Full Track Name, Group ID and Object ID, Relays MAY ignore subsequently received Objects or MAY use them to update the cache. Implementations that update the cache need to protect against cache poisoning.

A relay MUST NOT reorder or drop objects received on a multi-object stream when forwarding to subscribers, unless it has application specific information.

Relays MAY aggregate authorized subscriptions for a given track when multiple subscribers request the same track. Subscription aggregation allows relays to make only a single upstream subscription for the track. The published content received from the upstream subscription request is cached and shared among the pending subscribers.