Implementing Accept for UDP

UDP sockets have a 'connect' call, but do not have an 'accept' call for server applications. There are socket APIs that benefit performance-wise from a connected UDP socket (e.g. recvmmsg/sendmmsg) and is the best performing system call for a single-flow with very high packet rates (any thing higher requires kernel-bypass like DPDK).

Anyhow, I am unable to find a solution that implements accept for a UDP server, so my thoughts are to do the following:

Server socket listens until receiving a packet from a client
Server calls connect on the socket, thus allowing traffic to be sent to the client using the accelerated connected apis (i.e. connected sendmmsg over unconnected sendmmsg)
Server listens on a cloned socket of #1

In order to solve the accept thing, I am not sure how to clone #1. The user of my "server" library is passing in a socket file descriptor, meaning they have the control of what options they configured, (SO_RECVBUFF, etc) -- I don't have visibility in to it. Unfortunately, in order to clone it, I now need that visiblity.

Anyway, if there is another way to solve the accept thing, or clone the socket, I'd love to know! Thank you!

Solution

There's no built-in capacity to clone a socket. You would need to keep track of whatever options you set on one socket and set those on a new socket.

You have a larger problem however. If you have multiple UDP sockets open on the same port and a unicast packet comes in, only one of those sockets will receive it and you can't accurately predict which one it will be. So the whole concept of having a "listening" socket and multiple "accepted" sockets for UDP connections won't work.

Your program will need to have a single socket that handles all incoming packets and multiplexes them based on the sender, possibly with one thread to receive and one thread per client but try it without threads first.

EDIT:

Given the use of connected UDP sockets, it looks like you can have one unconnected socket as the listener and a connected socket for each remote endpoint you want to talk to. Since there's no clone function, this means any new socket you create to handle a different endpoint will briefly be in an unconnected state between when the socket is created and when connect is called on that socket. During that time, incoming packets not associated with a connected socket could come to the "listener" or it could come to this new socket before it connects. You'll need to handle this case in your application, most likely by having the connected socket drop unknown packets and by having clients retrying their initial "connection" until they receive a response.