Subscriber Interactions

Subscribers subscribe to tracks by sending a SUBSCRIBE (Section 8.7) 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 MUST have an established upstream subscription before sending SUBSCRIBE_OK in response to a downstream SUBSCRIBE. If a relay does not have sufficient information to send a FETCH_OK immediately in response to a FETCH, it MUST withhold sending FETCH_OK until it does.

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.

Relays MUST be able to process objects for the same Full Track Name from multiple publishers and forward objects to active matching subscriptions. The same object SHOULD NOT be forwarded more than once on the same subscription.

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. Because SUBSCRIBE_UPDATE only allows narrowing a subscription, relays that aggregate upstream subscriptions can subscribe using the Largest Object filter to avoid churn as downstream subscribers with disparate filters subscribe and unsubscribe from a track.