Relocate webtransport streams initialisation from HTTP3 connection accept loop to streams type #55425
Conversation
…loop to streams type
dotnet-issue-labeler
bot
added
the
area-networking
dotnet-policy-service
bot
added
the
community-contribution
|
Thanks for your PR, @AliKhalili. Someone from the team will get assigned to your PR shortly and we'll get it reviewed. |
| @@ -245,6 +254,48 @@ private async ValueTask<long> TryReadStreamHeaderAsync() | |||
| } | |||
| } | |||
|
|
|||
| private async ValueTask<long> TryReadWebTransportStreamSessionIdAsync() | |||
There was a problem hiding this comment.
It's a function with identical implementation in both Control and Request Streams; struggling to find an ideal location
AliKhalili
requested review from
halter73,
BrennanConroy,
JamesNK and
mgravell
as code owners
| private async ValueTask<long> TryReadWebTransportStreamSessionIdAsync() | ||
| { | ||
| // https://ietf-wg-webtrans.github.io/draft-ietf-webtrans-http3/draft-ietf-webtrans-http3.html#section-4.1-1 | ||
| while (_isClosed == 0) |
There was a problem hiding this comment.
_isClosed is declared as volatile. Writes to it are done via Interlocked.Exchange, so I'd prefer if the reads are done via Volatile.Read (explicitly).
It makes the code also easier to read / follow, as it's clear the memory-ordering is considered.
The same on other places where _isClosed is read.
There was a problem hiding this comment.
Thanks for your review, that's a genuine concern and I noticed that. However, the current implementation(Http3ControlStream) doesn't use the Volatile.Read method as you said, and I didn't want to alter any implementation conventions to avoid submitting a PR with numerous changes. I'm happy to address that though.
| SequencePosition start = default; | ||
| try | ||
| { | ||
| while (_isClosed == 0) |
There was a problem hiding this comment.
Here _isClosed isn't declared as volatile, so it should be Volatile.Reads and writes (L96)?
There was a problem hiding this comment.
Good catch, in Http3Stream it's not defined as volatile, and I believe we should treat them the same way and make it volatile as well in Http3Stream.
|
Looks like this PR hasn't been active for some time and the codebase could have been changed in the meantime. |
dotnet-policy-service
bot
added
the
pending-ci-rerun
|
Hi @amcasey, Any update on when this PR might be looked at would be appreciated. Thank you! |
|
@AliKhalili Sorry for the delay - I've been out sick. I'm starting to work through my backlog of reviews, but I'm not entirely recovered. |
|
@amcasey sorry to hear that. I hope you have a speedy recovery. Don't worry, I'm not in a rush at all. |
Relocate webtransport streams initialisation from HTTP3 connection accept loop to streams type
Description
This PR aims to remove all
webtransportstream initialisation from theHttp3Connectionaccept loop and relocate them to the appropriate location within stream types. Unidirectional streams will be transitioned to theControlStream, responsible for managing Unidirectional streams. Additionally, Bidirectional streams will be moved to theRequestStream, functioning similarly to theControlStreamby reading the stream header and executing the proper method to handle incoming streams.With this PR, I've tried to resolve the performance issue highlighted in the #42789. Considering this comment as a guideline, the current implementation of webtransport is based on draft02. Before updating to the latest draft version of webtransport (version 09), addressing the current implementation issues would facilitate any upcoming changes.
I also made efforts to adhere to existing code base conventions and avoid introducing significant changes. As a side effect of this relocation from connection to streams, we no longer need to manage pending streams. This PR also removes all pending stream-related stuff. Your feedback on these modifications is highly appreciated to ensure the refinement and appropriateness of the code.
Fixes #42789