3 ms·
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
by mwcampbell 4y ago
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?
- yencabulator 4y agoWebSockets 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.
- kentonv 4y agoWhile 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.
- yencabulator 4y agoYou 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.