> The DNS Long-Lived Queries (LLQ) mechanism [RFC8764] is an existing deployed solution to provide asynchronous change notifications; it was used by Apple's Back to My Mac [RFC6281] service introduced in Mac OS X 10.5 Leopard in 2007. Back to My Mac was designed in an era when the data center operations staff asserted that it was impossible for a server to handle large numbers of TCP connections, even if those connections carried very little traffic and spent most of their time idle. Consequently, LLQ was defined as a UDP-based protocol, effectively replicating much of TCP's connection state management logic in user space and creating its own imitation of existing TCP features like flow control, reliability, and the three-way handshake.
I can't help but hear the skepticism in "asserted"!
Also, fun that Apple want to move a service from UDP to TCP at a time when Google are trying to move another service from TCP to UDP.
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
I can't help but hear the skepticism in "asserted"!
Also, fun that Apple want to move a service from UDP to TCP at a time when Google are trying to move another service from TCP to UDP.