Hey @john.spurlock, don't know if this is a projected usecase, or if there is even a way to do this

Hey @john.spurlock, 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?

HHello, I’m Allie!Hey @john.spurlock, don't know if this is a projected usecase, or if there is ev...

John Spurlock•8/21/21, 10:01 PM

I believe @kentonv_cf 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.

JJohn Spurlock I believe @kentonv_cf said streaming requests and responses work inside DOs (lik...

Hello, I’m Allie!OP•8/21/21, 10:02 PM

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.

RraRaRa Yeah, I guess it's good enough for a few protoypes 🙂 I've wanted to port my old...

John Spurlock•8/21/21, 10:03 PM

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

HHello, I’m Allie!Or a flat-rated handoff API, where you'd pass the connection into it, and then i...

John Spurlock•8/21/21, 10:04 PM

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

John Spurlock•8/22/21, 3:48 AM

You can certainly use DOs without ever using

state.storage

state.storage

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

SSudonim https://developers.cloudflare.com/workers/learning/using-durable-objects#global-...

Hello, I’m Allie!OP•8/22/21, 4:26 AM

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.

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...

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.

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

Something brand new

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...

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...

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

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...

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.

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

Yes

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

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

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();

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

I'm not sure if

.accept

.accept

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

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:

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,
            });

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?

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

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

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).

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...

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

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

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

If in the same handler you just do

new Response("OK")

new Response("OK")

it works?

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?

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?

const res = await chatroomStub.fetch( `http://chatroom/messageSend`, { method: 'GET', headers: headers, }, ) if (!res.webSocket) { throw new Error('No websockets found.') } res.webSocket.accept();

// 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, });

Hey @john.spurlock, don't know if this is a projected usecase, or if there is even a way to do this

Similar Threads