The WebSocket would still be connected to the Workers Runtime. The isolate just wouldn't be running.

we can shut down an isolate without disconnecting sockets

I can see that working well, is there anyway to know if a keepalive was received on the browser end? zombie sockets become a common thing once you get to 10,000s of sessions. (where send doesnt fail but the other end gets nothing). A socket connected for a long period of time could get into this state. Usually outside of browsers we just use the websockets native ping/pong frames, but im not sure if browsers handle this thing properly. If they do, seems like there is no need to do ping/pong on the text/binary frame level of websockets.

Yeah keep-alives are tricky. The WebSocket protocol has built-in keep-alives, but usually they aren't very useful, because they are hidden from the application. Many apps really want to do their own keep-alives at a higher level. Our hibernation API may need to come with some way to instruct the runtime itself how to handle keep-alives...

Speed of devil, https://tools.ietf.org/html/rfc8441 http2 getting websocket support in chrome 91

like if the app could say "expect messages of the form

{ping: true}

and respond to them with `{pong: true}`"? But I don't know if that's going to be sufficiently general...

heh, glad they finally admitted that HTTP/2 bidirectional streaming is not a suitable replacement for WebSocket

I think this could suffice, some kind of hardcoded magic msg that gets handled not inside the DO but the outer routing node holding the TCP websocket. like "ping3a5a53afg3a" will be detected as magic and replied with "pong${epoch}" without waking the DO.

we'll have to do some sort of survey of common application-level keep-alive protocols

cloudflare on their side could enforce the ping/pong frames and drop the socket from the DO if there is no reply from the client. but the client could be stuck in zombieland thinking its connected (not getting important msgs from the DO), and it cant send anything because it does not want to wake the DO

the question is if browsers initiate the ping to the server (and show error if there is no reply in x seconds), or only respond to it

based on the text it seems browsers only ack the ping if it comes

hum.. cloudflare sending a generic msg down the websocket every 30-60 seconds as well as using ping frames to the client i think solves this. If the client does not get the generic ping msg (text/binary frame) in 30-60, it can assume its disconnected. if cloudflare does not get a reply from the client/browser to a ping frame, it can assume the client disconnected.

all without waking the DO

But then thats 2 ws frames (could be combined into 1 tcppacket). If the client acks the generic ping from cloudflare, 1 ws frame

it would be great if the solution here weren’t specific to websockets, and worked with something like EventSource too. 🤔

is there a way to fix this while trying to delete a DO worker?

ah, had a search and found https://canary.discord.com/channels/595317990191398933/773219443911819284/827070646966157382. Will give that a shot 👍

and that worked, perfect 🙂

has anyone got a good example of durable objects? something abit more advanced like a nested objects?

Do you mean like just a more complex object? I did one with object = { uniqueKey: counter } , and don’t see why it would be any different with a more complex object. I used itty-durable and just wrote functions to manipulate it.

I'm working on adding support to itty-durable for DOs within DOs (currently the stub proxy was only accessible through router middleware), then an example for nested DO usage (and finally describing all the functionality/overrides in the docs).

have all the basics in place and published, just need to verify (not sure how to add test coverage... if there are DO mocks or something) in an example and document the hell out of it

The problem is, I don't think in-browser JavaScript has any way to ask the browser whether it has seen ping frames. So the browser-side app has no way to know if the server is still there except by sending application-level ping messages.

It needs cloudflare to send/reply an applicationlevel ping. No cloudflare applicationlevel ping in x seconds (60) means we are disconnected.

ahh i think i see something not sure if this is a bug. If you crash inside a async function in a DO without awaiting it. the DO itself does not go down (i think)

Seems like wrangler still doesn't play nice with ARM chips, eh?

Could you elaborate a little?