aws
Use a single socket for accept and connect
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:
I agree that having a p2p capability would be useful. We're going to be investigating this use case in the next few months.
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?
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.
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.
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_TYPEeverywhere, since that's aconst. 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.
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.