Add guidelines on how CBOR messages are mapped onto streams about openscreenprotocol HOT 5 OPEN

MAX_STREAMS is negotiated between peers as a transport parameter. We should just tell agents to set MAX_STREAMS to a limit that is high enough so that it does not limit the protocol in practice.

An application sending 1 message/ms and allowing retransmissions for 10 seconds would have 10,000 concurrent streams. We can just set a minimum MAX_STREAMS of 2^17 to provide additional headroom.

from openscreenprotocol.

Correction: MAX_STREAMS limits the cumulative number of streams that can be opened per connection. For long lived connections, we will need a higher value. For a year-long connection, that could be as high as 400M according to the math above.

from openscreenprotocol.

In current Open Screen Library, QuicSteam is used as unidirectional stream, see CreateOutgoingStream and CreateIncomingStream. One endpoint can only use the incoming stream to read message. If it want to send message to peer, it need to create a new outgoing stream.

If we can change the QuicStream to bidirectional, then the incoming stream can also be used to send message and there is no need to create a new one. Beside, we can also call CloseWriteSide or CloseReadSide to turn a bidirectional stream to a unidirectional stream for scenario where unidirectional stream is really needed. WDYT?

from openscreenprotocol.

For my understanding; what drove the original one message per stream design? Is it to avoid relying solely on the variable-length integer and CBOR for message framing?

from openscreenprotocol.