-
Notifications
You must be signed in to change notification settings - Fork 41
Put SUBSCRIBE_NAMESPACE on a stream, make Namespaces and PUBLISH independent #1344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
25a2c7e
89e380b
abafb02
1a6fe39
7e16420
a30cd61
4b21ba2
9c8cc68
9ae1039
c71ae77
a31e5b3
b5e6711
0132f29
2465b19
bd3ebc8
d58eff5
9e37747
13a3a6f
2e23347
c5e7fbf
49d3c32
4a76892
9949625
b969d51
24b2efe
6aba921
e6a6368
fe00420
a0e6b3b
8d39c86
35695e0
17e0d0a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -724,10 +724,14 @@ The first stream opened is a client-initiated bidirectional control stream where | |||||||||
| the endpoints exchange Setup messages ({{message-setup}}), followed by other | ||||||||||
| messages defined in {{message}}. | ||||||||||
|
|
||||||||||
| This specification only specifies a single use of bidirectional streams. Objects | ||||||||||
| are sent on unidirectional streams. Because there are no other uses of | ||||||||||
| bidirectional streams, a peer MAY close the session as a `PROTOCOL_VIOLATION` if | ||||||||||
| it receives a second bidirectional stream. | ||||||||||
| This specification only specifies two uses of bidirectional streams, the control | ||||||||||
| stream and SUBSCRIBE_NAMESPACE. Objects are sent on unidirectional streams. | ||||||||||
|
|
||||||||||
| A unidirectional stream containing Objects or bidirectional stream(s) containing a | ||||||||||
| SUBSCRIBE_NAMESPACE could arrive prior to the control stream, in which case the | ||||||||||
| data SHOULD be buffered until the control stream arrives and setup is complete. | ||||||||||
| If an implementation does not want to buffer, it MAY reset other bidirectional | ||||||||||
| streams before the session and control stream are established. | ||||||||||
|
|
||||||||||
| The control stream MUST NOT be closed at the underlying transport layer during the | ||||||||||
| session's lifetime. Doing so results in the session being closed as a | ||||||||||
|
|
@@ -1156,26 +1160,28 @@ The syntax of these messages is described in {{message}}. | |||||||||
|
|
||||||||||
| If the subscriber is aware of a namespace of interest, it can send | ||||||||||
| SUBSCRIBE_NAMESPACE to publishers/relays it has established a session with. The | ||||||||||
| recipient of this message will send any relevant PUBLISH_NAMESPACE, | ||||||||||
| PUBLISH_NAMESPACE_DONE or PUBLISH messages for that namespace, or more specific | ||||||||||
| part of that namespace. This includes echoing back PUBLISH or PUBLISH_NAMESPACE | ||||||||||
| messages to the endpoint that sent them. If an endpoint accepts its own | ||||||||||
| PUBLISH, this behaves as self-subscription described in {{subscriptions}}. | ||||||||||
|
|
||||||||||
| A publisher MUST send exactly one REQUEST_OK or | ||||||||||
| REQUEST_ERROR in response to a SUBSCRIBE_NAMESPACE. The subscriber | ||||||||||
| SHOULD close the session with a protocol error if it detects receiving more than | ||||||||||
| one. | ||||||||||
| recipient of this message will send any relevant NAMESPACE, | ||||||||||
| NAMESPACE_DONE or PUBLISH messages for that namespace, or more specific | ||||||||||
| part of that namespace. This includes echoing back published Tracks and/or Track | ||||||||||
| Namespaces under the SUBSCRIBE_NAMESPACE prefix to the endpoint that sent them. | ||||||||||
| If an endpoint accepts its own PUBLISH, this behaves as self-subscription described | ||||||||||
| in {{subscriptions}}. | ||||||||||
|
|
||||||||||
| The subscriber sends SUBSCRIBE_NAMESPACE on a new bidirectional stream and the | ||||||||||
| publisher MUST send a single REQUEST_OK or REQUEST_ERROR as the first message on the | ||||||||||
| bidirectional stream in response to a SUBSCRIBE_NAMESPACE. The subscriber | ||||||||||
| SHOULD close the session with a protocol error if it detects receiving more | ||||||||||
| than one. | ||||||||||
|
|
||||||||||
| The receiver of a REQUEST_OK or REQUEST_ERROR ought to | ||||||||||
| forward the result to the application, so the application can decide which other | ||||||||||
| publishers to contact, if any. | ||||||||||
|
|
||||||||||
| An UNSUBSCRIBE_NAMESPACE withdraws a previous SUBSCRIBE_NAMESPACE. It does not | ||||||||||
| prohibit original publishers from sending further PUBLISH_NAMESPACE or PUBLISH | ||||||||||
| messages, but relays MUST NOT send any further PUBLISH messages to a client | ||||||||||
| without knowing the client is interested in and authorized to receive the | ||||||||||
| content. | ||||||||||
| A SUBSCRIBE_NAMESPACE can be cancelled by closing the stream with | ||||||||||
| either a FIN or RESET_STREAM. Cancelling does not prohibit original publishers | ||||||||||
|
Comment on lines
+1180
to
+1181
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It can be cancelled by either the creator or the peer. |
||||||||||
| from sending further PUBLISH_NAMESPACE or PUBLISH messages, but relays MUST NOT | ||||||||||
| send any further PUBLISH messages to a client without knowing the client is | ||||||||||
| interested in and authorized to receive the content. | ||||||||||
|
|
||||||||||
| ## Publishing Namespaces | ||||||||||
|
|
||||||||||
|
|
@@ -1639,14 +1645,16 @@ The following Message Types are defined: | |||||||||
| |-------|-----------------------------------------------------| | ||||||||||
| | 0x6 | PUBLISH_NAMESPACE ({{message-pub-ns}}) | | ||||||||||
| |-------|-----------------------------------------------------| | ||||||||||
| | 0x8 | NAMESPACE ({{message-namespace}}) | | ||||||||||
| |-------|-----------------------------------------------------| | ||||||||||
| | 0x9 | PUBLISH_NAMESPACE_DONE ({{message-pub-ns-done}}) | | ||||||||||
| |-------|-----------------------------------------------------| | ||||||||||
| | 0xE | NAMESPACE_DONE ({{message-namespace-done}}) | | ||||||||||
| |-------|-----------------------------------------------------| | ||||||||||
| | 0xC | PUBLISH_NAMESPACE_CANCEL ({{message-pub-ns-cancel}})| | ||||||||||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It looks like we're repeating the mistake we had in HTTP/3 where we are adding streams without type identifiers and then have some semantic rules about what messages can appear where. Can we have an explicit type for bidi streams instead?
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @vasilvv the current PR is adequate, in that it either starts with CLIENT_SETUP or it starts with SUBSCRIBE_NAMESPACE. This is extensible since have varint frame type so have unlimited ways to start streams. It seems like it would be fairly redundant to have: SETUP_STREAM and SUB_NS_STREAM Right?
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess the counter-argument is if in the future you want to start a stream with a non-message. This is what webtransport ran into and it got a little ugly, but ultimately resolved it by reserving a frame type and giving it new semantics.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I definitely don't want to repeat that mistake, but in this case we are adding type/message identifiers.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I can see that this works, but I don't see why we would want to do that. If there are two types of streams, and they have basically disjoint message type list, why do we want them to have the same format? |
||||||||||
| |-------|-----------------------------------------------------| | ||||||||||
| | 0x11 | SUBSCRIBE_NAMESPACE ({{message-subscribe-ns}}) | | ||||||||||
| |-------|-----------------------------------------------------| | ||||||||||
| | 0x14 | UNSUBSCRIBE_NAMESPACE ({{message-unsub-ns}}) | | ||||||||||
| |-------|-----------------------------------------------------| | ||||||||||
|
|
||||||||||
| An endpoint that receives an unknown message type MUST close the session. | ||||||||||
| Control messages have a length to make parsing easier, but no control messages | ||||||||||
|
|
@@ -2967,6 +2975,27 @@ PUBLISH_NAMESPACE Message { | |||||||||
|
|
||||||||||
| * Parameters: The parameters are defined in {{version-specific-params}}. | ||||||||||
|
|
||||||||||
| ## NAMESPACE {#message-namespace} | ||||||||||
|
|
||||||||||
| The NAMESPACE message is similar to the PUBLISH_NAMESPACE message, except | ||||||||||
| it is sent on the response stream of a SUBSCRIBE_NAMESPACE request. | ||||||||||
| All NAMESPACE messages are in response to a SUBSCRIBE_NAMESPACE, so only | ||||||||||
| the namespace tuples after the 'Track Namespace Prefix' are included | ||||||||||
| in the 'Track Namespace Suffix'. | ||||||||||
|
|
||||||||||
| ~~~ | ||||||||||
| NAMESPACE Message { | ||||||||||
| Type (i) = 0x8, | ||||||||||
| Length (16), | ||||||||||
| Track Namespace Suffix (..), | ||||||||||
| } | ||||||||||
| ~~~ | ||||||||||
| {: #moq-transport-ns-format title="MOQT NAMESPACE Message"} | ||||||||||
|
|
||||||||||
| * Track Namespace Suffix: Specifies the final portion of a track's | ||||||||||
| namespace as defined in {{track-name}} after removing namespace tuples included in | ||||||||||
| 'Track Namespace Prefix' {message-subscribe-ns}. | ||||||||||
|
|
||||||||||
| ## PUBLISH_NAMESPACE_DONE {#message-pub-ns-done} | ||||||||||
|
|
||||||||||
| The publisher sends the `PUBLISH_NAMESPACE_DONE` control message to indicate its | ||||||||||
|
|
@@ -2985,6 +3014,27 @@ PUBLISH_NAMESPACE_DONE Message { | |||||||||
| * Request ID: The Request ID of the PUBLISH_NAMESPACE that is being terminated. See | ||||||||||
| {{message-subscribe-req}}. | ||||||||||
|
|
||||||||||
| ## NAMESPACE_DONE {#message-namespace-done} | ||||||||||
|
|
||||||||||
| The publisher sends the `NAMESPACE_DONE` control message to indicate its | ||||||||||
| intent to stop serving new subscriptions for tracks within the provided Track | ||||||||||
| Namespace. All NAMESPACE_DONE messages are in response to a SUBSCRIBE_NAMESPACE, | ||||||||||
| so only the namespace tuples after the 'Track Namespace Prefix' are included | ||||||||||
| in the 'Track Namespace Suffix'. | ||||||||||
|
|
||||||||||
| ~~~ | ||||||||||
| NAMESPACE_DONE Message { | ||||||||||
| Type (i) = 0xE, | ||||||||||
| Length (16), | ||||||||||
| Track Namespace Suffix (..) | ||||||||||
| } | ||||||||||
| ~~~ | ||||||||||
| {: #moq-transport-ns-done-format title="MOQT NAMESPACE_DONE Message"} | ||||||||||
|
|
||||||||||
| * Track Namespace Suffix: Specifies the final portion of a track's | ||||||||||
| namespace as defined in {{track-name}}. The namespace begins with the | ||||||||||
| 'Track Namespace Prefix' specified in {message-subscribe-ns}. | ||||||||||
|
|
||||||||||
| ## PUBLISH_NAMESPACE_CANCEL {#message-pub-ns-cancel} | ||||||||||
|
|
||||||||||
| The subscriber sends an `PUBLISH_NAMESPACE_CANCEL` control message to | ||||||||||
|
|
@@ -3014,16 +3064,18 @@ PUBLISH_NAMESPACE_CANCEL Message { | |||||||||
|
|
||||||||||
| ## SUBSCRIBE_NAMESPACE {#message-subscribe-ns} | ||||||||||
|
|
||||||||||
| The subscriber sends the SUBSCRIBE_NAMESPACE control message to a publisher to | ||||||||||
| request the current set of matching published namespaces and `Established` | ||||||||||
| subscriptions, as well as future updates to the set. | ||||||||||
| The subscriber sends a SUBSCRIBE_NAMESPACE control message on a new | ||||||||||
| bidirectional stream to a publisher to request the current set of matching | ||||||||||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How do you distinguish the control stream from this stream?
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's a new bidi stream and it starts with the SUBSCRIBE_NAMESPACE message.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So if the first stream I receive starts with SUBSCRIBE_NAMESPACE, I hold it pending one that starts with CLIENT_SETUP?
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Without 0RTT clearly described, which it isn't today, I'm unsure how that could happen?
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah @afrind if right. It depends on if the QUIC library returns streams in stream_id order, but any bidirectional stream should be buffered until the CLIENT_SETUP is processed. In fact, the same is true for any unidirectional streams if pipelining a PUBLISH is valid (debatable with max_request_id), but that's a lot easier to implement.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks, I understand the issue now. Yes, I can call out this potential issue.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. PTAL at 2465b19 |
||||||||||
| published namespaces and/or `Established` subscriptions, as well as future | ||||||||||
| updates to the set. | ||||||||||
|
|
||||||||||
| ~~~ | ||||||||||
| SUBSCRIBE_NAMESPACE Message { | ||||||||||
| Type (i) = 0x11, | ||||||||||
| Length (16), | ||||||||||
| Request ID (i), | ||||||||||
| Track Namespace Prefix (..), | ||||||||||
| Subscribe Options (i), | ||||||||||
ianswett marked this conversation as resolved.
Show resolved
Hide resolved
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can one send 2 subscribe_namespace with 2 different options
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, this falls under duplicate prefix text elsewhere. |
||||||||||
| Number of Parameters (i), | ||||||||||
| Parameters (..) ... | ||||||||||
| } | ||||||||||
|
|
@@ -3042,15 +3094,20 @@ SUBSCRIBE_NAMESPACE Message { | |||||||||
| Track Namespace Prefix consisting of 0 or greater than than 32 Track Namespace | ||||||||||
| Fields, it MUST close the session with a `PROTOCOL_VIOLATION`. | ||||||||||
|
|
||||||||||
| * Subscribe Options: Allows subscribers to request PUBLISH (0x00), | ||||||||||
| NAMESPACE (0x01), or both (0x02) for a given SUBSCRIBE_NAMESPACE request. | ||||||||||
suhasHere marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||
|
|
||||||||||
| * Parameters: The parameters are defined in {{version-specific-params}}. | ||||||||||
|
|
||||||||||
| The publisher will respond with REQUEST_OK or | ||||||||||
| REQUEST_ERROR. If the SUBSCRIBE_NAMESPACE is successful, the publisher will | ||||||||||
| immediately forward existing PUBLISH_NAMESPACE and PUBLISH messages that match | ||||||||||
| the Track Namespace Prefix that have not already been sent to this subscriber. | ||||||||||
| If the set of matching PUBLISH_NAMESPACE messages changes, the publisher sends | ||||||||||
| the corresponding PUBLISH_NAMESPACE or PUBLISH_NAMESPACE_DONE message. | ||||||||||
| The publisher will respond with REQUEST_OK or REQUEST_ERROR on the response half | ||||||||||
| of the stream. If the SUBSCRIBE_NAMESPACE is successful, the publisher will | ||||||||||
| send matching NAMESPACE messages on the response stream if they are requested. | ||||||||||
| If it is an error, the stream will be immediately closed via FIN. | ||||||||||
| Also, any matching PUBLISH messages without an `Established` Subscription will be | ||||||||||
| sent on the control stream. When there are changes to the namespaces or | ||||||||||
ianswett marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||
| subscriptions being published and the subscriber is subscribed to them, | ||||||||||
| the publisher sends the corresponding NAMESPACE, NAMESPACE_DONE, | ||||||||||
| or PUBLISH messages. | ||||||||||
|
|
||||||||||
| A subscriber cannot make overlapping namespace subscriptions on a single | ||||||||||
| session. Within a session, if a publisher receives a SUBSCRIBE_NAMESPACE with a | ||||||||||
|
|
@@ -3074,27 +3131,6 @@ set the FORWARD parameter to 1, or indicate that value by omitting the parameter | |||||||||
| (see {{subscriptions}}). | ||||||||||
|
|
||||||||||
|
|
||||||||||
| ## UNSUBSCRIBE_NAMESPACE {#message-unsub-ns} | ||||||||||
|
|
||||||||||
| A subscriber issues a `UNSUBSCRIBE_NAMESPACE` message to a publisher indicating | ||||||||||
| it is no longer interested in PUBLISH_NAMESPACE, PUBLISH_NAMESPACE_DONE and | ||||||||||
| PUBLISH messages for the specified track namespace prefix. | ||||||||||
|
|
||||||||||
| The format of `UNSUBSCRIBE_NAMESPACE` is as follows: | ||||||||||
|
|
||||||||||
| ~~~ | ||||||||||
| UNSUBSCRIBE_NAMESPACE Message { | ||||||||||
| Type (i) = 0x14, | ||||||||||
| Length (16), | ||||||||||
| Request ID (i), | ||||||||||
| } | ||||||||||
| ~~~ | ||||||||||
| {: #moq-transport-unsub-ann-format title="MOQT UNSUBSCRIBE_NAMESPACE Message"} | ||||||||||
|
|
||||||||||
| * Request ID: The Request ID of the SUBSCRIBE_NAMESPACE | ||||||||||
| ({{message-subscribe-ns}}) being cancelled by this message. | ||||||||||
|
|
||||||||||
|
|
||||||||||
| # Data Streams and Datagrams {#data-streams} | ||||||||||
|
|
||||||||||
| A publisher sends Objects matching a subscription on Data Streams or Datagrams | ||||||||||
|
|
||||||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR does not really provide a good way for implementations to figure out what stream is the control stream.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a type identifier at the beginning of the control stream, which is the SETUP messages.