if this is true i probably need to redesign

the entire stack i am using

its much simpler to interact with DOs as well by sending them a websocket msg instead of doing a full fetch

It's not really difficult from what you've said. Take a look at below:

nono

thats wrong

there should be a square after the first

so

User1 Connects -> user1 DO connects to wallet DO (if no conn exists) -> User1 socket added to user1.sockets User2 Connects -> user2 DO connects to wallet DO (if no conn exists) -> User2 socket added to user2.sockets User1 or User2 changes balance in wallet DO -> wallet DO sends msg to User1 AND User2 DO -> User1 DO sends msg to user1 | User2 DO sends msg to User2

i'm planning on upgrading to paid to build a DO with a 24/7 WebSocket client (specifically to discord), and im trying to work out the pricing (I know it'll change later but just for now) Are DOs just billed like unbound workers for now? Also, what is a gigabyte second? How many should I expect to pay in a month? I don't expect to be doing much CPU work with it, mostly it'll just be waiting until it recieves a message on the socket, do I only get billed when the message event listener is called? Am I even doing the right thing here, is that how websockets should be handled?

Really I should probably just build it and see what happens though especially when the billing will change anyway

for websockets i believe you are billed for all the time it is active

DO would only be charged when you interact with it, i think not so sure

You can think of a GB/sec as a way to bill for provisioned memory at the edge. The smallest worker provisioned today (and the default) is 128MB. Don't quote me on this, this is a object held in memory for 30 days (in $USD)... someone check my math... 🙂

seconds_in_30_days = 30 * 24 * 60 * 60
million_seconds_in_30_days = seconds_in_30_days / 1_000_000
gigabytes_per_object = 0.128
cost_per_million_seconds_per_gb = 12.50
cost_per_30_days = cost_per_million_seconds_per_gb * gigabytes_per_object * million_seconds_in_30_days
> $4.1472

Oh it's memory, I was thinking bandwidth or something but that makes more sense 🙂 seems pretty affordable aswell, thanks

So your plan is for the DO itself to connect out to Discord, and then do other clients connect to the DO, or?

No I'm fairly sure I should be able to handle everything I need to do within the DO without needing other clients to connect to it, since all the important settings are going to be stored in KV as they don't need to apply instantly

That might change though? the other part of my backend is a workers site, which works okay but the discord rest API is somewhat heavily rate limited and obviously I can't really count the rate limits on a non-persistent worker For now I think that it isn't reading enough to be a problem

Should probably think about my architecture more 😄

FYI @User and @User, this is incorrect. We do not currently have the ability to shut down a DO while a WebSocket is open, and start it back up when messages arrive. Doing that would lose state, such as the message event handler registered on the WebSocket. We might create an API to do something like this later, but it doesn't work that way today.

If you open a WebSocket from one DO to another, the second ("server") DO will be held open until the WebSocket is closed. But, the connection does not hold open the "client" DO. So if the client isn't getting any other requests, it will eventually shut down, and this will cause the WebSocket to disconnect.

With some tcp stack kungfu and hibernating/freezing the ram of the nodejs/whateverrunetime runs the js it should be possible?

Snapshotting the runtime state probably isn't realistic. More likely we'll have an explicit API where you can attach some tag to a WebSocket, and then if your DO shuts down and starts back up, the system will give you the WebSocket again along with the tag you attached earlier.

though I think the really tricky part is that every application does some sort of periodic keep-alive ping... we need to figure out how we can handle those without starting up the object, otherwise it'll always be running due to keep-alives.

yea its very tricky, i think the task will be MUCH simpler if only QUIC protocol was supported (over UDP) then a udp packet can enter cloudflare at any POP, and you just need to teleport the state of the QUIC session over (not sure if this helps with anything, but it makes proxing to the DO easier as you dont need to rely on the TCP (kernel/ or user if using DPDK/etc) stack probably if a pingframe comes over this thing https://web.dev/webtransport/ (so using this new ish), dont forward anything to the DO, reply it at the edge.

Oh I see.. it seemed the way I said from my experience. Do the limitations last for the life of the websocket connection or per message? For example if I make a websocket that fetch's a URL on every message, after 50 requests will it die?

Each time the DO receives a WebSocket message, we reset the limits (for CPU time and subrequests) to full.

so yeah it should work fine

Theres any plan to backup/export the data on DO storage at once (all objects derived from some script) or the plan is to us do that by ourselves?

right now, the answer is to do that manually.