Clarify allowed messages during SETUP #324
Conversation
draft-ietf-moq-transport.md
Outdated
|
|
||
| This draft 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 currently close the session as a | ||
| 'Protocol Violation' if it receives a second bidirectional stream. | ||
| An endpoint MUST NOT open a unidirectional stream until after it has completed |
There was a problem hiding this comment.
I think this implies that the server has to wait until SERVER SETUP is acknowledged? It can really only know that when it receives the first non-setup control message.
Really the text should say "until after the receipt of a SUBSCRIBE message". It's used as both an acknowledgement of the SETUP handshake being completed and It's just a protocol violation to send OBJECTs without a SUBSCRIBE anyway. But I'm also fine with "until the receipt of the first non-SETUP message" just to keep things generic for the future.
There was a problem hiding this comment.
Never trust transport acks at the app layer! Definitely don't want to imply that. I can update it to:
An endpoint MUST not open a unidirectional stream or send an OBJECT* message until after receiving a SUBSCRIBE and sending a SUBSCRIBE OK.
That transitively means you can't do it during setup, since you can't send or receive a subscrbie* until after setup is complete. Would that work?
There was a problem hiding this comment.
That transitively means you can't do it during setup, since you can't send or receive a subscrbie* until after setup is complete.
Mostly true. Now that control messages are sent on the same stream as SETUP, you can abuse head-of-line blocking. If client only supports versions/extensions with the same SUBSCRIBE encoding, then the client can send the SUBSCRIBE immediately:
--> SETUP (stream 1)
--> SUBSCRIBE (stream 1)
<-- SETUP (stream 1)
<-- SUBSCRIBE_OK (stream 1)
<-- OBJECT (stream 2)
Your proposed text now allows this so that's gud. I think it can be simplified even further:
An endpoint MUST not send an OBJECT before receiving a corresponding SUBSCRIBE message.
This rules out publisher push, independent of the handshake itself.
There was a problem hiding this comment.
What Track ID would the OBJECTs have if a SUBSCRIBE hadn't been sent?
There was a problem hiding this comment.
I can add this MUST to the PR that makes it so the subscriber picks Track ID.
I think the intent of the draft was clear but this makes it explicit not to open a uni stream before setup exchange is done.
Fixes: #136