Subscriber Interactions

Subscribers interact with the Relays by sending a SUBSCRIBE (Section 6.4) control message for the tracks 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 subscriber is notified of the result of the subscription via a SUBSCRIBE_OK (Section 6.15) or SUBSCRIBE_ERROR Section 6.16 control message. The entity receiving the SUBSCRIBE MUST send only a single response to a given SUBSCRIBE of either SUBSCRIBE_OK or SUBSCRIBE_ERROR.

If a relay does not already have a subscription for the track, or if the subscription does not cover all the requested Objects, it will need to make an upstream subscription. The relay SHOULD NOT return a SUBCRIBE_OK until at least one SUBSCRIBE_OK has been received for the track, to ensure the Group Order is correct.

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 subscription remains active until the publisher of the track terminates the subscription with a SUBSCRIBE_DONE (see Section 6.19).

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 be protect against cache poisoning.

Objects MUST NOT be sent for unsuccessful subscriptions, and if a subscriber receives a SUBSCRIBE_ERROR after receiving objects, it MUST close the session with a 'Protocol Violation'.

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.

The application SHOULD use a relevant error code in SUBSCRIBE_ERROR, as defined below:

Table 2

Code	Reason
0x0	Internal Error
0x1	Invalid Range
0x2	Retry Track Alias
0x3	Track Does Not Exist
0x4	Unauthorized
0x5	Timeout

The application SHOULD use a relevant status code in SUBSCRIBE_DONE, as defined below:

Table 3

Code	Reason
0x0	Unsubscribed
0x1	Internal Error
0x2	Unauthorized
0x3	Track Ended
0x4	Subscription Ended
0x5	Going Away
0x6	Expired