WebTransportSession shouldn't take ownership of Connection<C, B>

[ash-hashtag]

I believe the spec allows sharing the same connection for multiple sessions and multiple requests as well, since WebTransportSession is wrapping it Mutex anyway to store it, making the argument itself as Arc<Mutex<Connection<C, B>>> might be helpful.

Preferably async Mutex, as we have to use

async fn Connection::accept(&mut self)

for incoming requests

#289 and #186 are related

making the connection cloneable and keeping the mutability internally would allow sharing same connections for multiple sessions is probably better than having Arc<Mutex<Connection<C, B>>> everywhere

[Ruben2424]

I am not sure i understand what you want to do. Do you want to open streams from multiple tasks?

[ash-hashtag]

I believe webtransport draft, allows us to have multiple webtransport sessions over one connection. Which is one of the promised upgrades from Websockets where you'd need one dedicated connection for one Websocket.

Hence I'd like to accept multiple CONNECT requests (along with other http Requests) and make multiple WebTransportSessions over the same Connection, without giving up the entire Connection for one dedicated WebTransportSession.

which is not possible by current implementation.

Or Did I misunderstand, how webtransport is supposed to be.

[ash-hashtag]

Apologies, I've misunderstood the implementation a little. I have seen that WebTransportSession does handle any new incoming requests, and return them back for regular http request handling.

The flow of control feels odd. I expected, h3 server should always handle any incoming requests over a connection, one WebTransportSession should handle only one of the CONNECT request. So making WebTransportSession take over full control flow and return Requests for handling might not be counter-intuitive.

But I still don't think I could accept multiple webtransport CONNECT requests without having access to Connection

[Ruben2424]

I am not deep into the WebTransport spec myself. Feel free to make PRs to improve it/ add features etc. Or open issue(s).
Can you go into more detail what you proposed here in this issue? I cannot follow completely.
It would be appreciated.

If you consider working on it, keep in mind that the way h3 interacts with WebTransport atm is not ideal. I wrote that down in #293.

[ash-hashtag]

here is an example code (not real nor correct code), showing my intentions of what I wish to do

async fn handle_connection(conn: Connection) {

    // I wish to continue accepting requests on the connection, including more CONNECT requests on the same connection
    while let Some(Ok((request, stream))) = conn.accept().await {
        tokio::spawn(handle_request(request, stream, conn.clone()));
    }
    
}

async fn handle_request(request: Request, mut stream: Stream, conn: Connection) {
    match request.method() {
        Method::CONNECT => {
            /*
                connection is obviously required for webtransportsession to open more streams in its own session
                But we need connection for the next WT CONNECT request on the same connection as well, hence one WebTransportSession shouldn't take over the entire connection
            */
            let session = WebTransportSession::accept(request, stream, conn.clone()).await.unwrap();
            tokio::spawn(handle_webtransport_session(session));
        },

        Method::GET => {
            stream.send_response(
                Response::builder()
                        .status(StatusCode::OK)
                        .body("Hello".into())
                        .unwrap()                
            ).await.unwrap()
        }
        _ => {
            // anything else
        }
    }
}

I just wish to open multiple WebTransportSessions over the same connection. But it does feel messy to do it properly. I'll give it a try.

[jsclary]

The examples/webtransport_servers.rs#L162 has a TODO that seems to show where there might be a problem with the current API:

    loop {
        match conn.accept().await {
            Ok(Some(resolver)) => {
                // TODO: resolve request in a different task to not block the accept loop
                let (req, stream) = match resolver.resolve_request().await {

I'm not aware of any way to accomplish that so long as WebTransportSession consumes the connection. You're always potentially stuck blocking concurrent streams while waiting to get enough of the request to decide if it is webtransport.

Doesn't that mean all h3 streams are effectively serialized so long as webtransport support is enabled? If that's the case, it would only be within a connection so it isn't catastrophic but it could impact page load times. It would mean if the remote client is multithreaded, one of its threads could block all of its other threads by not sending the headers frame in a timely fashion after initiating the stream. Some lost packets could cause that as well? It'd also block handling of datagrams which seems worse but that's mostly specific to webtransport.