because the export is a named function, any attempts to use

fetch

inside of that function will actually recursively call the function itself, and not the global

self.fetch

. (this was incorrect, see https://discord.com/channels/595317990191398933/773219443911819284/811043933663920158)

Any idea about how DO would perform latency-wise for a real-time multiplayer .IO game? We already have a single server in Germany with players connecting from distant geographical areas (the Americas, Europe and a bit Asia). I'm curious if porting the game server to DO would help reducing the ping overall.

I'm pretty much inclined to think like moving data back and forth over Cloudflare's private backbone would be better than relying on customer ISPs to do it all.

It depends, how are these clients connecting to the one server atm? Is it routed through Cloudflare network already?

Direct connection over WebSockets. No Cloudflare atm.

Then I believe you would see performance improvements even if you would just put it behind Cloudflare. In terms of using DO instead, I guess it depends on the workload.. but it would definitely offload the server management 🙂

Right now, we need to store the list of Durable Object instance IDs somewhere (e.g. KV) to keep track of which instances exist. Is a

MyDurableObjectNamespace.list()

method planned for any point in the future?

Would it not be possible to have a separate named DO that acts as an index for other DOs (with generated IDs)?

It would, but I would still want to have the native list operation (which I think someone confirmed is coming, but cannot find it in history), it could also return some metadata about DOs 🙂

Ah, that isn't implemented yet i gather?

Are you refering to the

list(options Object)

on the storage object in DO or am I just confused? 🙂

I was referring to the

MyDurableObjectNamespace.list()

question, it might be me being confused 🤔 😄

Ah, got it.

The metadata would be nice. Like number of objects and disk used etc.

Treating the namespace almost like a bucket with metadata on itself, but I don't know how hard that would be to implement...

Hmm I don't think that's correct?

export default { fetch () {} }

exports an object that has a method called

fetch()

. It doesn't define

fetch()

at the global scope. To call it recursively you'd have to write

this.fetch()

.

We might introduce a way to list objects through the API, but it's likely to be pretty inefficient and not something you'd want to call at runtime, because the operation will basically have to call out to every datacenter individually and ask for a list of objects in that datacenter. If you need a list of your objects available at runtime, you need to maintain an index in another object or in KV.

yes, you're right. not sure how i confused that, i think i had confused this with

async function fetch(){}; export {fetch};

.

ah yes, that would do it

is this something that you'd offer in the GUI? ie, a way to cull unused DOs without writing code.

Dunno about UI, given the inefficiency. Eventually we'd like to have a way to "run this function in every object"

like a MapReduce sort of thing

which probably covers your use case

even deleting + recreating a DO would probably be enough, once the dashboard catches up.

going out on a limb here 😜 , and assuming I received an

Error 1006

for my "voice chat" worker + DO, which capture microphone audio, and sends ~3kb binary blobs over a websocket every 500ms (i'm throttling to 500ms while testing. would ideally like to send smaller blobs more frequently...)

Hmm I wouldn't expect that.

interesting! i'll admit, I don't get the 1006 error very consistently

but the websocket connection does seem to close pretty consistently after 10-15 sec. I have no reconnect logic yet. but I assumed I was being closed due to that 1006, and only seeing the error every once in a while

Likely unrelated. I'm not entirely sure what a 1006 error is, but I'm pretty sure it's not something Workers does, and once the WebSocket is connected, the Workers system owns it and will decide when to disconnect.