Who needs keep alive?

What is TCP keepalive? The keepalive concept is very simple: when you set up a TCP connection, you associate a set of timers. Some of these timers deal with the keepalive procedure. When the keepalive timer reaches zero, you send your peer a keepalive probe packet with no data in it and the ACK flag turned on. You can do this because of the TCP/IP specifications, as a sort of duplicate ACK, and the remote endpoint will have no arguments, as TCP is a stream-oriented protocol. On the other hand, you will receive a reply from the remote host (which doesn't need to support keepalive at all, just TCP/IP), with no data and the ACK set. If you receive a reply to your keepalive probe, you can assert that the connection is still up and running without worrying about the user-level implementation. In fact, TCP permits you to handle a stream, not packets, and so a zero-length data packet is not dangerous for the user program.

Websockets does this for you. Why? Well for two reasons, some html servers shuts idle connections and second.... Dunno. The sender will notice the closed connection, or at least notice the Ack from the server is impossibly late.  ot sure why this is an issue, it is part of Web sockets.

What happens if join bots don't do keep alive? Well either one case, the counterparty has a broken cable or the OS crashed. The client will figure this out upon sending the next message and not getting an ack. So that part is gone, and the only protocol in web sockets that is new is framing, an it replaces http.  So I implement a framing protocol, a simple and small routine.  I have having a hard time understanding why web sockets needs a library, in this use case.  Bots talking peer to peer with simple messages over a simple framing protocol, total 200 lines of code. 

I can see systems with message queue management, and call backs and the rest.  But these joins have natural separation, can hit the pause button on one join and start another, letting the previous wait.  It is all part of how join works, leaving both graphs in a consistent state allowing random swapping between join instances. My session layer is the web sockets framing layer, don't need anything else, it carries standard LazyJ.