Note though that there is no guarentee that the DO Instance will persist for that long. In fact, I b

I

ItsWendell•8/22/21, 9:54 AM

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?

HHello, I’m Allie!Note though that there is no guarentee that the DO Instance will persist for tha...

A

asp•8/22/21, 10:34 AM

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

M

MrBBot•8/22/21, 11:50 AM

Something brand new

I

ItsWendell•8/22/21, 3:40 PM

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.

MMallissin Instead of streaming the audio directly, you can also use MPEG-Dash or HLS to ou...

H

Hello, I’m Allie!OP•8/22/21, 7:38 PM

That's a good idea. How would it handle getting prematurely shut down, though? Would there be a way to store a reference to a connection in Storage?

RraRaRa I'm wondering what the best way would be to create a lobby that shows list of al...

E

Erwin•8/23/21, 5:09 AM

My first instinct would be for the rooms to be their own DO and the Lobby to be another. And the room DOs can update the Lobby DO as needed. Then depending on how many people would be in a lobby I would connect them straight to the DO, or go via something like KV

E

Erwin•8/23/21, 10:31 AM

It is scaling (per DO) issues. They are very horizontally scalable. At 10/20 rooms you’ll be fine!

Mmz Hi, we are stuck at the same problem (Workers as a websocket client to DurableOb...

I

ItsWendell•8/23/21, 11:19 AM

I think in the end it was a stupid mistake, I did a POST request with a body holding some information hoping that I'd get a websocket back but this shouldn't work and doesn't work according to the websocket standards. It should always be a GET request.

I

ItsWendell•8/23/21, 11:22 AM

Yes

I

ItsWendell•8/23/21, 11:22 AM

I passed data through Headers instead of doing a POST request, you could also use URL params.

I

ItsWendell•8/23/21, 11:24 AM

        const res = await chatroomStub.fetch(
          `http://chatroom/messageSend`,
          {
            method: 'GET',
            headers: headers,
          },
        )

        if (!res.webSocket) {
          throw new Error('No websockets found.')
        }

        res.webSocket.accept();

        const res = await chatroomStub.fetch(
          `http://chatroom/messageSend`,
          {
            method: 'GET',
            headers: headers,
          },
        )

        if (!res.webSocket) {
          throw new Error('No websockets found.')
        }

        res.webSocket.accept();

        const res = await chatroomStub.fetch(
          `http://chatroom/messageSend`,
          {
            method: 'GET',
            headers: headers,
          },
        )

        if (!res.webSocket) {
          throw new Error('No websockets found.')
        }

        res.webSocket.accept();

        const res = await chatroomStub.fetch(
          `http://chatroom/messageSend`,
          {
            method: 'GET',
            headers: headers,
          },
        )

        if (!res.webSocket) {
          throw new Error('No websockets found.')
        }

        res.webSocket.accept();

I

ItsWendell•8/23/21, 11:25 AM

I'm not sure if

.accept

.accept

.accept

.accept is necessary here, but this works now (this is script from the Worker)

I

ItsWendell•8/23/21, 11:27 AM

Make sure you send the WebSocket back to the Worker with statusCode 101. Here's the minimized version from the DO:

I

ItsWendell•8/23/21, 11:27 AM

            // Start websocket server, send client back.
            const [client, server]: WebSocket[] = Object.values(
              new WebSocketPair(),
            )
            server.accept()

            // Do events on server here.

            return new Response(null, {
              webSocket: client,
              status: 101,
            });

            // Start websocket server, send client back.
            const [client, server]: WebSocket[] = Object.values(
              new WebSocketPair(),
            )
            server.accept()

            // Do events on server here.

            return new Response(null, {
              webSocket: client,
              status: 101,
            });

            // Start websocket server, send client back.
            const [client, server]: WebSocket[] = Object.values(
              new WebSocketPair(),
            )
            server.accept()

            // Do events on server here.

            return new Response(null, {
              webSocket: client,
              status: 101,
            });

            // Start websocket server, send client back.
            const [client, server]: WebSocket[] = Object.values(
              new WebSocketPair(),
            )
            server.accept()

            // Do events on server here.

            return new Response(null, {
              webSocket: client,
              status: 101,
            });

I

ItsWendell•8/23/21, 11:37 AM

I'm not sure if I understand what you're trying to do. In Scenario #2, what is triggering your worker?

I

ItsWendell•8/23/21, 11:39 AM

Browser <--Websocket--> Worker <--Websocket--> Durable Object is how I got it working

I

ItsWendell•8/23/21, 11:40 AM

So there are actually 2 websocket connections, one from Browser to Worker, and one from Worker to Durable Object, and they are completely seperate, in my case the worker just proxies them though (and it could be multiple at the same time).

I

ItsWendell•8/23/21, 11:42 AM

Yes so like this right: Browser / Client <--Websocket 1--> Worker <--Websocket 2--> Durable Object

Mmz ``` {"webSocket":null,"url":"wss://abcdefghi.lmnopqrst.workers.dev/webSocket/cre...

I

ItsWendell•8/23/21, 11:43 AM

You are getting a 404 here so there is something wrong in your routing there.

I

ItsWendell•8/23/21, 11:44 AM

If in the same handler you just do

new Response("OK")

new Response("OK")

new Response("OK")

new Response("OK") it works?

I

ItsWendell•8/23/21, 11:46 AM

Are you requesting the Websocket with the right headers from your other origins? Edit: Wrong question, what is the endpoint supposed to return?

I

ItsWendell•8/23/21, 11:47 AM

It shouldn't return a websocket then right? Since that's only from the Worker to the DO?

I

ItsWendell•8/23/21, 11:49 AM

I think the worker will die as soon as you give it a response though, unless you give it a waitUntil and wait for something

I

ItsWendell•8/23/21, 11:50 AM

Are you expecting the worker to continue running after a response have been given to the request?

I

ItsWendell•8/23/21, 11:51 AM

Okay, so where are you getting the 404, when you do the request to the worker or to the DO?

Mmz checking...

I

ItsWendell•8/23/21, 1:01 PM

Hmhmh, so what is it supposed to response on the request to the worker?

Note though that there is no guarentee that the DO Instance will persist for that long. In fact, I b

Similar Threads

Similar Threads

Similar Threads