Use a single socket for accept and connect

[Frando]

Problem:

I'd like to use a s2n_quic socket both for accepting inbound connections and initiating outbound connections.

We're investigating using s2n_quic in a peer-to-peer scenario. There, it is very common for an endpoint to both act as a server (accepting incoming connections) and as a client (initiating outbound connections). When connecting to many peers and holding these connections for a longer time, it saves resources and ports to do it all over a single socket. It also makes holepunching easier if having a single socket for many connections.

If I read things correctly, QUIC as a protocol supports this just fine. Other implementations also support this, e.g. quinn::Endpoint has both connec and accept methods.

Solution:

Provide a connect method on Server or expose an Endpoint that can act both as a server (accept) and a client (connect).

• Does this change what s2n-quic sends over the wire? No
• Does this change any public APIs? --> Addition only

Requirements / Acceptance Criteria:

Out of scope:

[camshaft]

I agree that having a p2p capability would be useful. We're going to be investigating this use case in the next few months.

[cavemanloverboy]

I agree that having a p2p capability would be useful. We're going to be investigating this use case in the next few months.

any progress?

[camshaft]

Unfortunately no updates on this

[cavemanloverboy]

Unfortunately no updates on this

if you can provide some resources and an outline on what needs to be done (i.e. checklist), I could try to write something up over the next few weekends.

[camshaft]

That would be great! I will try to get a list of things together by Friday.

Initially, I think the biggest issue is going to be figuring out how to account for the use of Config::ENDPOINT_TYPE everywhere, since that's a const. The nice thing about it right now is all of the code gated behind that is compiled out for clients and servers.

[cavemanloverboy]

That would be great! I will try to get a list of things together by Friday.

Initially, I think the biggest issue is going to be figuring out how to account for the use of Config::ENDPOINT_TYPE everywhere, since that's a const. The nice thing about it right now is all of the code gated behind that is compiled out for clients and servers.

lmk if you've made any progress on making a list of resources/requirements.

[camshaft]

I haven't had a chance unfortunately. Looking at it a bit more, this is going to be a pretty large change that touches quite a bit of the codebase and I'm still not totally sure what it would look like at the end of the refactor. We're currently working on a few other refactors for performance improvements and my worry is we end up getting into complicated merge conflicts.

With that being said, I do want to get this feature addressed. But, due to priorities, it likely won't be at least a few months until we can get the time to actually define how it'll look in practice.