It’s still tricky to handle more than, say, a million or so TCP connections per box, but moving the connections to UDP with TCP-like state machine in user-space solves none of the issues.
It depends on how TCP like you end up being. In TCP, all outgoing data is stored for retransmit if not acked; in this application, a server wouldn't need its responses acked or stored (if the client doesn't get the response, it will resend the request), and push messages could be regenerated if not acked, rather than stored and retransmitted as-is.
That reduction in required storage could be significant. User space connection tracking might also use less memory than kernel connection tracking, depending on how many non-essential things each implementation tracks. Colocation of the connection tracking data and the application level data might be beneficial as well.
I didn't read the prior RFCs to see what kind of hoops they jumped to make the connections long lived though, my guess is TCP session timeouts for NAT boxes are longer than UDP, and there are more networks that disallow UDP than TCP, so TCP is probably a good idea from that standpoint.
yeah really, aren't you just moving the buffers that track the TCP connection states from the kernel to some program in user space? how does that solve anything
