Publisher Interactions

There are two ways to publish through a relay:

1. Send a PUBLISH message for a specific Track to the relay. The relay MAY respond with PUBLISH_OK in Forward State=0 until there are known subscribers for new Tracks.

2. Send a PUBLISH_NAMESPACE message for a Track Namespace to the relay. This enables the relay to send SUBSCRIBE or FETCH messages to publishers for Tracks in this Namespace in response to requests received from subscribers.

Relays MUST verify that publishers are authorized to publish the set of Tracks whose Track Namespace matches the namespace in a PUBLISH_NAMESPACE, or the Full Track Name in PUBLISH. Relays MUST NOT assume that an authorized publisher of a single Track is implicitly authorized to publish any other Tracks or Track Namespaces. If a Publisher would like Subscriptions in a Namespace routed to it, it MUST send an explicit PUBLISH_NAMESPACE. The authorization and identification of the publisher depends on the way the relay is managed and is application specific.

When a publisher wants to stop new subscriptions for a published namespace, it cancels the request (see Section 3.3.2) to withdraw the PUBLISH_NAMESPACE. A subscriber indicates it will no longer subscribe to Tracks in a namespace it previously responded PUBLISH_NAMESPACE_OK to by cancelling the PUBLISH_NAMESPACE request.

A Relay connects publishers and subscribers by managing sessions based on the Track Namespace or Full Track Name. When a SUBSCRIBE message is sent, its Full Track Name is matched exactly against existing upstream subscriptions.

Namespace Prefix Matching is further used to decide which publishers receive a SUBSCRIBE and which subscribers receive a PUBLISH. In this process, the fields in the Track Namespace are matched sequentially, requiring an exact match for each field. If the published or subscribed Track Namespace has the same or fewer fields than the Track Namespace in the message, it qualifies as a match.

For example: A SUBSCRIBE message with namespace=(foo, bar) and name=x will match sessions that sent PUBLISH_NAMESPACE messages with namespace=(foo) or namespace=(foo, bar). It will not match a session with namespace=(foobar).

Relays MUST send SUBSCRIBE messages to all matching publishers. This includes matching both Established subscriptions on the Full Track Name and Namespace Prefix Matching against published Namespaces. Relays MUST forward PUBLISH_NAMESPACE or PUBLISH messages to all matching subscribers.

When a Relay needs to make an upstream FETCH request, it determines the available publishers using the same matching rules as SUBSCRIBE. When more than one publisher is available, the Relay MAY send the FETCH to any of them.

When a Relay receives an authorized SUBSCRIBE for a Track with one or more Established upstream subscriptions, it MUST reply with SUBSCRIBE_OK. If the SUBSCRIBE has Forward State=1 and the upstream subscriptions are in Forward State=0, the Relay MUST send REQUEST_UPDATE with Forward=1 to all publishers. If there are no Established upstream subscriptions for the requested Track, the Relay MUST send a SUBSCRIBE request to each publisher that has published the subscription's namespace or prefix thereof. If the SUBSCRIBE has Forward=1, then the Relay MUST use Forward=1 when subscribing upstream.

When a relay receives an incoming PUBLISH message, it MUST send a PUBLISH request to each subscriber that has sent SUBSCRIBE_TRACKS for the Track's namespace or a prefix thereof. However, if the relay is holding a downstream SUBSCRIBE awaiting a publisher for this Track (see Section 10.2.6), it MUST proceed with the SUBSCRIBE and MUST NOT also forward the PUBLISH to that subscriber.

When a relay receives an authorized PUBLISH_NAMESPACE for a namespace that matches one or more existing subscriptions to other upstream sessions, it MUST send a SUBSCRIBE to the publisher that sent the PUBLISH_NAMESPACE for each matching subscription. When it receives an authorized PUBLISH message for a Track that has Established downstream subscriptions, it MUST respond with PUBLISH_OK. If at least one downstream subscriber for the Track has Forward State=1, the Relay MUST use Forward State=1 in the reply.

If a Session is closed due to an unknown or invalid control message or Object, the Relay MUST NOT propagate that message or Object to another Session, because it would enable a single Session error to force an unrelated Session, which might be handling other subscriptions, to be closed.