Does the WebSockets protocol now have some kind of built-in keepalive/ping functionality? Something like that is practically necessary for any long-running idle connection on top of TCP. Without built-in keepalive, the application would have to stay running just to handle pings, right?
WebSockets has a protocol-level ping/pong interaction. If one wrote a WebSocket proxy, one could respond to pings on that level, without proxying them to a backend.
While the WebSocket protocol indeed has built-in ping/pong, it's somewhat difficult to rely upon. Web browsers do not provide any API to send pings from the client side. As a result a lot of applications end up implementing application-level pings.
In order to support efficient WebSocket idling, we probably need to have some ability to respond to application-level pings without actually executing JavaScript. TBH I'm not exactly sure how this will work yet.
You could make an incoming WebSocket message behave much like an incoming HTTP request: The DO worker starts running, reads the message, runs any `event.waitUntil` work to completion, and goes to sleep. Let your runtime unload DO workers while holding on to their WebSocket connections.
That would mean maintaining "chatroom" state in memory wouldn't be enough, the DO worker would have to always write it to the durable store, to be safe to unload.
You'd have some sort of a "WebSocket connection ID" that could be used as key for storing state, and when the next message comes in, the worker would use that key to fetch state.
EDIT: And the ability to "rejuvenate" other WebSocket connections from their IDs, so you can e.g. resend a chat room message to all subscribers.
