Is it possible to share a UDP socket between server and client?

[timprepscius]

So I like to use the same socket between server and client operations so that I can usually detect WAN accessible port for a user-client to connect to.

Pool exists somewhere remote.
ServerNode N connects to pool via socket X
Pool discovers what ServerNode N's WAN accessible IP and port for socket X are.
ServerNode accepts on the same port X, and the Pool tells others to connect ServerNode N using the discovered IP and socket.

This doesn't always work of course, there are lots of edge cases, but it works pretty well most of the time.

Can this be done? I was reading on the lsquic, how somehow this isn't possible because of some mess up in a previous google version of quic, but maybe it's possible here? I'm unclear of the state of this.

[nibanks]

It is almost possible to share the socket, but due to some protocol complexities around how you look up the connection from the packet header during the handshake, server and client are unfortunately mutually exclusive. Post handshake they could theoretically share, but obviously you have to get through the handshake first. If you're interested in the nitty-gritty details, let me know and I will see about adding them later.

Edit: BTW, MsQuic used to support sharing until I discovered the edge case bug for which the fix required them to be exclusive.

[nibanks]

There might be a way to do it, but I haven't found one. The logic in this area is left up to the implementation a bit. So, as of right now, IMO, if an implementation supports clients sharing a UDP 4-tuple (on both the client and server side of the connection) then it's not possible to also share the socket between client and server.

[nibanks]

For more info, start reading this comment here: https://github.com/microsoft/msquic/blob/main/src/core/binding.c#L1390

[timprepscius]

Do you mean by "sharing a 4 tuple" as in multiple processes binding a udp port via reuse_addr (which, if I remember correctly, in both linux and posix causes all packets to be broadcast to all binding processes, although not sure)?

What do you mean by "sharing a 4 tuple?"

[nibanks]

QUIC allows for the same destination and source IP address and UDP port to be shared by multiple parallel connections. In other words, a client can create a single socket and run multiple parallel connections on the same socket. MsQuic supports this; but doing so requires the use of connection IDs to differentiate the packets received on that single socket so they can be directed to the appropriate connection. Hopefully this answers your question.

[timprepscius]

I understand the share 4 tuple statement now..

So in a nutshell, it seems you are saying: because you can't control the implementation of the other side, you are not guaranteed it will pick connection IDs which differentiate themselves from the connection IDs you are picking, and hence you are not sure to know that a new connection is being created? Something like this?

My brain is running through ways of solving this problem, however it really doesn't matter, I guess.

If I guarantee msquic is used on both sides, I assume there is still this problem?

Anyway, I won't waste your time with this anymore, thanks.