There are two ways to publish through a relay:
-
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.
-
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. 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 sends a PUBLISH_NAMESPACE_DONE. A subscriber indicates it will no longer subcribe to Tracks in a namespace it previously responded PUBLISH_NAMESPACE_OK to by sending a PUBLISH_NAMESPACE_CANCEL.
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 tuples 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 forward SUBSCRIBE messages to all matching publishers and 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 active 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 SUBSCRIBE_UPDATE with Forward=1 to all publishers. If there are no active 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 subscribed (via SUBSCRIBE_NAMESPACE) to the Track's namespace or prefix thereof.
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 active subscribers, 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.
8.4.1. Graceful Publisher Network Switchover
This section describes a behavior that a publisher MAY choose to implement to allow for a better user experience when switching between networks, such as WiFi to Cellular or vice versa.
If the original publisher detects it is likely to need to switch networks, for example because the WiFi signal is getting weaker, and it does not have QUIC connection migration available, it establishes a new session over the new interface and sends PUBLISH_NAMESPACE and/or PUBLISH messages. The relay will establish subscriptions and the publisher publishes Objects on both sessions. Once the subscriptions have migrated over to the session on the new network, the publisher can stop publishing Objects on the old network. The relay will attempt to deduplicate Objects received on both subscriptions. Ideally, the subscriptions downstream from the relay do no observe this change, and keep receiving the Objects on the same subscription.
8.4.2. Graceful Publisher Relay Switchover
This section describes a behavior that a publisher MAY choose to implement to allow for a better user experience when a relay sends them a GOAWAY.
When a publisher receives a GOAWAY, it starts the process of connecting to a new relay and sends PUBLISH_NAMESPACE and/or PUBLISH messages, but it does not immediately stop publishing Objects to the old Relay. The new Relay will establish subscriptions and the publisher can start sending new Objects to the new relay instead of the old Relay. Once Objects are going to the new Relay, the published namespaces and subscriptions to the old relay can be withdrawn or terminated.