🙂

Are there any limitations or anything one should be aware of before using WebSockets with Durable Objects? I really want to try to make a few prototypes such as online jigsaw or pictionary game.

Hmm there was a nice limitations page that pretty much answered that question for me! One last question, can Durable Objects have timers in them, e.g. to control a game session that should only last a minute. So I could for example set up a timer that will broadcast that the round has ended after one minute?

you can do

setTimeout

and they pretty much always fire, but not if the object needs to be destroyed (colo goes down, or service upgrade) or runs out of runtime. For the latter, I believe the cloudflare team said that they are working on an update to ensure they will fire more consistently in the future (search the scrollback), but no public docs for that yet.

Ok great! This is really powerful way to make "serverless" multiplayer games. Just a few additional questions on your reply, what does service upgrade mean and running out of runtimes? Just curious if this is production ready

Like all serverless platforms, you have to architect around possible downtime for any reason like network outage, or rolling service upgrades. For something like a timer, you might want to use

setTimeout

for the 99% case, but also store the timer in state and have a cron that runs every minute as a fallback, the cron is guaranteed to run even if the DO is recreated

Yeah gotcha! If DO is re-created for some reason, I assume it's like any new DO, where the state of it has disappeared, e.g. list of connected sessions.

And every client would need to re-connect

the in-memory state will be cleared - yes like websockets, but you can access the same persistent storage using

state.storage

Yep gotcha, thanks for the clarification

which won't help you for websockets : )

> Just curious if this is production ready Depends on your production needs. For a game, maybe. Officially, it's not even GA yet, so not production-ready from an official point of view. Not even billed yet!

Hey @User, don't know if this is a projected usecase, or if there is even a way to do this with DO, but would it be possible for a DO to receive a stream, and then pass it on to many clients? So, for example, a music streaming platform, that received one input, and streamed it to all of the connected clients?

Yeah, I guess it's good enough for a few protoypes 🙂 I've wanted to port my old online pictionary game server to serverless for quite some time, but there hasn't been anything out there to make it happen, well without having to go into some really complex infrastructure within AWS. I think this will be a huge game changer for writing online services and games. Just trying to grasp the concept of Durable Objects and what they can really do, e.g. using setTimeout for various events, but I guess a cron will also work just fine.

I believe @User said streaming requests and responses work inside DOs (like between the entry-point worker and the DO), but I've not tried it myself. Would be a cool proof of concept, would need to be unbound though, or you'd run out of cpu quickly.

Or a flat-rated handoff API, where you'd pass the connection into it, and then it would handle splitting and transmitting it, without it counting as CPU time.

> I think this will be a huge game changer for writing online services and games. I agree, as long as you're fine with tying your architecture to cloudflare

You could possibly send the chunks over ws too, instead of trying to stream everything through - anyway cool idea

https://developers.cloudflare.com/workers/learning/using-durable-objects#global-uniqueness Dose this mean i cant use durable object for a task that never touches storage. I want to use durable objects so ~15m after the last request the durable object deletes its self

You can certainly use DOs without ever using

state.storage

, it is there if you need it, but you can have your object live only in memory if you want.

Note though that there is no guarentee that the DO Instance will persist for that long. In fact, I believe that DOs are automatically purged 30 seconds after the last request.

Hmm 30 seconds is awfully short time! Shouldn't it stay alive while there are active websockets?

Are there any reports on avg latencies between different edges / colos from DO to DO? And latencies between same colo DO to same colo DO?

It was exactly 120 seconds after last request last time I checked. That was a little over a week ago.

Hmm.. the Transactional Storage API in DO, is it based on KV, or is it something brand new that doesn't utilize KV at all?

Something brand new 🙂

I'm wondering what the best way would be to create a lobby that shows list of all rooms, which also keeps track of how many users are in each room. One way would be to store all rooms in a KV, but then whenever a user joins or leaves a room, I would need to keep track of how many users are in the room, and broadcast it somehow to users in the lobby. Wouldn't it make sense to have the lobby as its own DO, so if user leaves a game, he connects to the lobby DO.

Hmm, I could also just store the room ids in KV, and then in the lobby worker, it would fetch DO for every room and get the session count. I guess that would be kinda expensive

Yeah both have benefits / trade-offs. KV store is better if you have super high reads, but the lobby won't be as accurate since it might take longer to update globally and it isn't transactional. A lobby DO would allow you for a transactional storage API but might have limits on throughput, since your DO might run out of memory if you get too many incoming requests, and your lobby would be 'stuck' on one edge having high latency for some, while others have low latency depending on where the lobby is.

Instead of streaming the audio directly, you can also use MPEG-Dash or HLS to output the stream into chunks then update the manifest each time. Could even cache the chunks.