-
Notifications
You must be signed in to change notification settings - Fork 12
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
Add negotiation for pooling support #25
Conversation
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.
I don't think this proposal works when the server sends its SETTINGS first
Once an HTTP/3 implementation has the SETTINGS_ENABLE_WEBTRANSPORT from both | ||
sides, the following should happen: | ||
|
||
* If one of client's or server's value is "0", and another value is either "0" |
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 doesn't handle the case where client sends 0 and server sends 2. Why not simply say: if any endpoint sent 0 then WebTransport is not supported on this connection - which means clients MUST NOT send the special CONNECT request, and servers MUST fail it with a certain error.
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.
No, it handles it with a connection error (third bullet point).
| S = 0 | N/A | N/A | N/A | | ||
+-------+-------+-------------+----------------+ | ||
| S = 1 | N/A | Normal mode | Normal mode | | ||
+-------+-------+-------------+----------------+ |
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.
What's the point of having the client tell the server whether it wants to be exclusive or not?
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.
It's not about whether it's exclusive or not, it's about whether the client intends to send a WebTransport request or not.
A different way to design this would be to say that the setting advertises the maximum number of Http3Transport sessions that the endpoint is willing to support. The maximum number in any session is then the minimum of the client and server value. E.g. if either side sends 0, its off. If either side sends > 0 its on but pooling only works if both send > 1. |
@LPardue your design wouldn't allow a server to say "I'd like either HTTP or WT, but not both on the same connection" though, right? |
Sorry, I might have enterd on the wrong axis of thinking about pooling as sharing one connection for WebTransport only, not mixing with conventional HTTP/3. Although, I'm not sure I follow how the proposal here satisfies the ""I'd like either HTTP or WT, but not both on the same connection" either. |
@LPardue In my understanding, this PR doesn't handle the "I'd like either HTTP or WT, but not both on the same connection" use-case. And I think that's what some folks were asking for. |
Co-authored-by: David Schinazi <[email protected]>
Co-authored-by: David Schinazi <[email protected]>
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.
I still don't understand how this works. How does the server know what value to send?
HTTP/3 and has a WebTransport request that it intends to send over the | ||
connection in question. |
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.
Does this mean the client has to have a request in mind before sending the SETTING? Is pre-connecting allowed?
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.
Sure, as long as you're fine with the resulting connection being usable for a single WebTransport.
* If server's value is "2", and client's value is "0" or "1", the connection | ||
MUST be closed with a connection error. |
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.
Echoing @DavidSchinazi's earlier point -- this makes it challenging to run a web server and an exclusive-only web transport server on the same address/port. The server can send SETTINGS in 0.5-RTT, and it won't know if the client is going to send 0 (HTTP) or 2 (WT). Alternately, the server can wait to receive the client SETTINGS before sending its own, but that's suboptimal for other reasons.
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.
Somewhat related is that there is a completely incompatible set of modes here -- C=1, S=2. These clients can't talk at all, even if the client would prefer pooled connections but would settle for exclusive ones.
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.
I'm confused. I don't think you can run a non-exclusive server and and exclusive server on the same port without multiplexing by something like ALPN.
If the client prefers pooled version, it can send C=1. C=1, S=1 results in pooled WebTransport, C=1, S=2 results in exclusive WebTransport.
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.
Per the text and the table, C=1, S=2 is an error.
Co-authored-by: David Schinazi <[email protected]>
It sounds like calling C=2 "exclusive" was a mistake. Renamed it. |
Abandoning per discussion on #34. |
No description provided.