search

w3c / webtransport

WebTransport is a web API for flexible data transport
https://w3c.github.io/webtransport/
Other
845 stars 50 forks source link

When should a client initiated unidirectional stream be available on the server side? #618

Closed martenrichter closed 1 month ago

martenrichter commented 2 months ago

I am still trying to create working stream-limit tests with all two webtransport enabled browsers. I ran into another issue: I misused creating uni- and bidirectional streams as a matter of communication/synchronization in the tests. Chrome and Firefox behave quite differently. If I create a unidirectional stream with

await transport.createUnidirectionalStream()

Chromium immediately sends out a frame indicating the stream's creation, but Firefox does not (at least for 5 seconds). I had to push one byte into the unidirectional stream to let the server know about the stream. So the question is, is the behavior within spec? If not, I would file a bug with Firefox, and if yes, I think this can lead to trouble...

martinthomson commented 2 months ago

I think that I see what is happening. Firefox waits until you have something to send. That's pretty reasonable, in my view. No point in burning the resources until you need to use the stream.

In a protocol that uses QUIC directly, you don't see a stream creation at the receiving end until some data is sent.

Chrome is getting the sending out of the way, which might be better in some ways, even if that leads to more overhead.

Both are entirely valid.

martenrichter commented 2 months ago

I think that I see what is happening. Firefox waits until you have something to send. That is also my conclusion. Only bidirectional streams are opened immediately, which makes sense but is different. I do not understand Firefox code entirely yet and did not identify where it is handled differently.

That's pretty reasonable, in my view. No point in burning the resources until you need to use the stream.

In a protocol that uses QUIC directly, you don't see a stream creation at the receiving end until some data is sent.

Chrome is getting the sending out of the way, which might be better in some ways, even if that leads to more overhead.

Both are entirely valid. The question is, would it be desirable to have consistent behavior across browsers?

Ok, the test I am writing is a bit artificial, but in the case of the test that surfaced the different behavior, it took me a few days to find one cause the test is not running through (it runs without problems using my quiche-based client). However, I am debugging both sides of the C++ (or Rust) code with debuggers, debug printouts, etc. . If a developer-only with javascript knowledge on the UA side and some scripting language on the server side (either node.js or comparable) tries to find the differences, it may take considerable time.

If the different behavior remains, I would think a hint in the spec and may be here: https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/createUnidirectionalStream would be good for future developers.

jan-ivar commented 1 month ago

Meeting:

martenrichter commented 1 month ago

But this apply then only to unidi? And not to Bidi?

martinthomson commented 1 month ago

It applies to both, though the implementation of either could end up being different.

martenrichter commented 1 month ago

Okay, so for a client-initiated stream, we should always send the first bytes from the client. A protocol where the server sends first makes no sense. Furthermore (and this is also due to the nature of quick), we should never assume a specific order in which the streams arrive at the server side. So, the order in which the streams appear inside the stream of streams is not the order of initiation.