UDP "accept" proposed
Subsystems (2)
One of the frustrations of creating UDP servers using BSD sockets is that there isn't an easy way for a server to pass off a socket for a particular client instance to a handler thread or process.
By contrast, with TCP you can "accept" an incoming connection, and pass the socket representing that connection off to any arbitrary handler.
But UDP servers that want to play well with stateful firewalls and NAT are forced to aggregate their entire connection pool onto a single socket, since BSD sockets don't have the equivalent of an "accept" mechanism to provide a connection-specific socket.
This is a disaster from a performance perspective because you can't take a UDP server that binds to a single port and efficiently scale it up across multiple threads or processors because you must operate off a single socket.
So why can't I "accept" a UDP socket? The conventional response would be that UDP is connectionless and that "accept" is meaningless outside the context of a connection. UDP may be connectionless, but it's not stateless. The tuple of (local address/port, remote address/port) concisely defines the state of a UDP session between a client and server. Netfilter connection tracking recognizes this statefulness, but unfortunately BSD sockets do not.
I would like to propose that Linux adds a userspace API method to allow UDP sockets to be "accepted":
int accept_udp(int sockfd, const struct sockaddr *addr, socklen_t *addrlen, int flags)
accept_udp will return a new UDP socket which is bound to the original local address/port of sockfd but which is additionally bound to the source address/port denoted by addr. This socket will only receive datagrams having a source address of addr, and when used with send(), will transmit datagrams to addr.
This socket, while open, will have priority in the sense of receiving any datagrams having a source address of addr that would normally have been received by sockfd. When closed, datagrams from addr will revert to being received by sockfd.
This abstraction allows UDP servers to follow the same scalable event loop as TCP servers, i.e. bind to local socket, then:
1. recvfrom to read a packet
2. call accept_udp on socket, passing the source address of packet read in (1)
3. pass the return socket of accept_udp to a handler thread
4. repeat
This would require the UDP implementation in the kernel to understand how to dispatch incoming UDP datagrams to sockets based on the tuple of (source addr, local addr) rather than just local addr as is currently the case.
But this would be a huge performance win for UDP servers (I'm thinking about OpenVPN in particular) because making the kernel smarter about dispatching UDP datagrams would make it much easier to develop scalable UDP servers on Linux.
James
On 06/18/2013 10:48 AM, James Yonan wrote:
[...]
Quoted 3 lines
This is a disaster from a performance perspective because you can't take a UDP server that binds to a single port and efficiently scale it up across multiple threads or processors because you must operate off a single socket.
[...]
Quoted 3 lines
But this would be a huge performance win for UDP servers (I'm thinking about OpenVPN in particular) because making the kernel smarter about dispatching UDP datagrams would make it much easier to develop scalable UDP servers on Linux.
So SO_REUSEPORT that was added in 3.9 by Tom Herbert wouldn't help in your case (+ f.e. steering flows to CPUs locally) ?
Quoted 5 lines · Daniel Borkmann
On 06/18/2013 10:48 AM, James Yonan wrote:
[...]Quoted 3 lines
This is a disaster from a performance perspective because you can't take a UDP server that binds to a single port and efficiently scale it up across multiple threads or processors because you must operate off a single socket.
Well not with current linux ;)
Quoted 9 lines
Quoted 3 lines
But this would be a huge performance win for UDP servers (I'm thinking about OpenVPN in particular) because making the kernel smarter about dispatching UDP datagrams would make it much easier to develop scalable UDP servers on Linux.
So
SO_REUSEPORTthat was added in 3.9 by Tom Herbert wouldn't help in your case (+ f.e. steering flows to CPUs locally) ?https://lwn.net/Articles/542629/
Yes, but no need for particular steering.
Incoming UDP message will match the 'connected socket' and will be delivered to the socket.
RFS will then automatically do the right thing
( Documentation/networking/scaling.txt )
Note that if you have a lot of sockets bound to the same port, this fix is needed :
Quoted 19 lines · Eric Dumazet
Quoted 5 lines · Daniel Borkmann
On 06/18/2013 10:48 AM, James Yonan wrote:
[...]Quoted 3 lines
This is a disaster from a performance perspective because you can't take a UDP server that binds to a single port and efficiently scale it up across multiple threads or processors because you must operate off a single socket.
Well not with current linux ;)
Quoted 9 lines
Quoted 3 lines
But this would be a huge performance win for UDP servers (I'm thinking about OpenVPN in particular) because making the kernel smarter about dispatching UDP datagrams would make it much easier to develop scalable UDP servers on Linux.
So
SO_REUSEPORTthat was added in 3.9 by Tom Herbert wouldn't help in your case (+ f.e. steering flows to CPUs locally) ?https://lwn.net/Articles/542629/
Quoted 7 lines
Yes, but no need for particular steering.
Incoming UDP message will match the 'connected socket' and will be delivered to the socket.
RFS will then automatically do the right thing
(Documentation/networking/scaling.txt)
+1, this was what I meant. I should have been more specific. ;-)
Quoted 4 lines
Note that if you have a lot of sockets bound to the same port, this fix is needed :
Quoted 11 lines
One of the frustrations of creating UDP servers using BSD sockets is that there isn't an easy way for a server to pass off a socket for a particular client instance to a handler thread or process.
By contrast, with TCP you can "accept" an incoming connection, and pass the socket representing that connection off to any arbitrary handler.
But UDP servers that want to play well with stateful firewalls and NAT are forced to aggregate their entire connection pool onto a single socket, since BSD sockets don't have the equivalent of an "accept" mechanism to provide a connection-specific socket.
You should be able to create another UDP socket and use connect().
Quoted 4 lines
This is a disaster from a performance perspective because you can't take a UDP server that binds to a single port and efficiently scale it up across multiple threads or processors because you must operate off a single socket.
Actually, for really large workloads having large number of sockets generates its own problems.
...
Quoted 4 lines
This would require the UDP implementation in the kernel to understand how to dispatch incoming UDP datagrams to sockets based on the tuple of (source addr, local addr) rather than just local addr as is currently the case.
I believe it already does that if you've called connect().
Quoted 4 lines
But this would be a huge performance win for UDP servers (I'm thinking about OpenVPN in particular) because making the kernel smarter about dispatching UDP datagrams would make it much easier to develop scalable UDP servers on Linux.
By the sound of it what you really want is a small number of sockets all bound to the same UDP port, and for the kernel to spread the received traffic between the sockets in a manner that tends to keep traffic from a specific remote host assigned to the same socket.
Then you can have a multi-threaded daemon that will tend to keep the data in the correct cpu cache.
David