Http3 client API vs server API about neqo HOT 4 CLOSED

@ddragana @martinthomson

from neqo.

When I did this for minhq, the client and server implementation shared some common code (qpack, handling messages, etc...), but the API was very different.

The client establishes a connection and makes requests. It receives pushes associated with requests/responses.

The server establishes a listening port, which results in multiple connections (but you hide the connections from the main API). It handles requests and can push associated with those requests.

minhq has a highly concurrent API, which is fundamentally different to neqo, but the basic ideas should be followed.

from neqo.

Yeah. Currently we have Http3Connection that can be used as a client or server, (I guess depending on if the transport::Connection was created with new_client or new_server). We also have RequestStreamClient and RequestStreamServer classes, so there already is client- or server-specific code, it just is selectively called depending on role checks at runtime.

One way to refactor might be to flip things around and have the role-specific code drive things, since ultimately the APIs will be role-specific. If there's a Http3Client class then maybe it can directly include much of what was in RequestStreamClient. The issue then becomes less about handling the differences between the two roles, and more about minimizing the duplication of code around qpack and control streams. Maybe Http3Client has a Http3CommonStreamHandler member where all that can go, and be used internally also by Http3Server?

I think we're in a good position now to do this refactor, because the current code has reached a point where it generally works, and also has tests that will ensure refactored code also mostly works. But in the long run I think we'll be happier if the distinct client and server APIs are different types.

@ddragana what do you think? Does this sound like the right direction? If we agree to proceed with this approach, would you have time in the next week or so to tackle this, or is #10 going to keep you busy? This is a bit of a blocker for me, so I'd like to get somebody going on this relatively soon.

from neqo.

Yeah. Currently we have Http3Connection that can be used as a client or server, (I guess depending on if the transport::Connection was created with new_client or new_server). We also have RequestStreamClient and RequestStreamServer classes, so there already is client- or server-specific code, it just is selectively called depending on role checks at runtime.

One way to refactor might be to flip things around and have the role-specific code drive things, since ultimately the APIs will be role-specific. If there's a Http3Client class then maybe it can directly include much of what was in RequestStreamClient. The issue then becomes less about handling the differences between the two roles, and more about minimizing the duplication of code around qpack and control streams. Maybe Http3Client has a Http3CommonStreamHandler member where all that can go, and be used internally also by Http3Server?

In my second round of refactoring the http3 code I was planning to do something like this. I do not like it either having 2 roles and always changing behavior in the code depending on the role.

About Http3CommonStreamHandler: There are some parts common to both roles, but a lot of differences are there as well, like handling setting. But that is solvable as well by supplying a hanlde if needed.

I can take a look at this.

I think we're in a good position now to do this refactor, because the current code has reached a point where it generally works, and also has tests that will ensure refactored code also mostly works. But in the long run I think we'll be happier if the distinct client and server APIs are different types.

@ddragana what do you think? Does this sound like the right direction? If we agree to proceed with this approach, would you have time in the next week or so to tackle this, or is #10 going to keep you busy? This is a bit of a blocker for me, so I'd like to get somebody going on this relatively soon.

from neqo.