Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reflect – Multiplayer web app framework with game-style synchronization

rocicorp.dev

Post reply on HN
Print view View original

141–150 of 159 posts

Re: Reflect – Multiplayer web app framework with game-style synchronization

#141

Post by aboodman »

asadm wrote: post #92
aboodman wrote: post #87

Earlier quoted context omitted.

It's websockets, and yes we do make use of Durable Objects. But we do extensive batching and buffering on top of the raw platform. You can't literally send 120 messages / second to and from 100 concurrent clients. Actually the math tops out at about 8 :).

Can you explain what are the limitations in Durable Objects?

There are a variety of relevant limitations. Some of them are listed here: developers.cloudflare.com/durable-objects/platform/limits/

For this particular problem, it just comes down to CPU time. At the bottom of the stack ws.send() is a syscall and it takes significant time. You can only do so many of these calls per second. We measured it at about 8k/sec a year ago.

With a conservative limit of 2k calls to ws.send() (so that we can stay about about 50% utilization and only use half of the time for calling send), this implies 6 clients at 60 FPS using a naive approach (6 * 6 * 60 = ~2k).

It's not really a DO problem, it's just that doing n^2 messages can't really work in any platform.

Re: Reflect – Multiplayer web app framework with game-style synchronization

#142

Post by aboodman »

woggy wrote: post #138
aboodman wrote: post #2

Hey hacker news! I'm one of the people behind this, happy to answer any questions.

Curious what your thoughts are on ElectricSQL?

It seems really interesting. The key thing to understand is that there are deep architectural choices made in each of these systems that really influence what you can do. There is "mechanical sympathy" with certain kinds of applications.

ElectricSQL is a distributed database. It's not going to run anywhere near 60fps with tons of users, because it's not running in memory on the server like Reflect/PartyKit/Liveblocks do. OTOH it will allow you to filter/query interact with much more data at the same time than Reflect/PartyKit/Liveblocks do – Reflect has a limit currently of 50MB per room and it's not practical to have dozens of rooms open at one time to get around this.

Systems in the Reflect room/document based model are well suited for applications where you primarily interact with one "document" at a time and you want that to be as realtime as possible. Figma is the canonical example. You want the entire document to move together at 60 FPS, completely fluidly. It's not going to be possible to do this well in the ElectricSQL model IMO. Spreadsheets, presentations and documents are other examples. Systems in the ElectricSQL model are more suited for applications where you are interacting with lots of documents at the same time. Think CRMs, bug trackers, etc.

Of course real applications are messy. Even document editors always have a dashboard where you can at least see all your documents at once. And CRMs of course have a detail view that looks like a document editor. Both types of systems are going to track toward the other to support the needs of real applications.

HTH!

Re: Reflect – Multiplayer web app framework with game-style synchronization

#143

Post by aboodman »

wheybags wrote: post #129
DecoPerson wrote: post #86

Earlier quoted context omitted.

Hey wheybags, this is not deterministic lockstep. That is an algorithm for peer-to-peer games, where each peer waits for the input from all other players before advancing the game simulation. The deterministic part is because players share inputs (not simulation results) AND the simulation is deterministic for the same inputs. The lockstep part is because all clients advance at a coordinated pace. The Age of Empires…

Yes, I know there's some differences in what you're doing here from classic deterministic lockstep, but the fundamental concept of syncing a queue of inputs from which the game state can be derived, instead of syncing the game state itself is the same, which is why I mentioned it. Also, while deterministic lockstep can be used peer to peer, it is not fundamentally a peer to peer model. Factorio for example, uses serv…

FWIW, I don't think this is deterministic lockstep for the key reason that Reflect is not deterministic:

https://i.imgur.com/q9FnN4R.png

The whole idea of DL as I understand it is to take advantage of determinism to reduce bandwidth. But Reflect doesn't do this.

I think this is a feature for developers. It's nice to be able to have the server just do whatever it wants for whatever reason it wants. It also means you can use normal JS, and don't need to try and enforce determinism somehow.

There are a lot of different names for these protocols floating around. Server Reconciliation is the one I found that best describes what Reflect does: https://www.gabrielgambetta.com/client-side-prediction-serve...

But in the end I felt like since we're going to continue to evolve this and have made specific choices, it made sense to give our version its own name so that we can refer to it.

Re: Reflect – Multiplayer web app framework with game-style synchronization

#144

Post by flupke »

aboodman wrote: post #23
joshelgar wrote: post #19

Hey Aaron, cool product! Well done so far. Curious why you think no-one has done TCR before? Also, any insights on why you're bullish on the "multiplayer web"? Will be cool to see example docs / repos as they come out!

The examples and docs are live here: https://hello.reflect.net/ TCR is just a small generalization of what the game industry has been doing for awhile. So in that sense, we are not at all the first. But I'm honestly not sure why it's not been done on the web yet. To me, it's a really elegant approach. It is harder to implement in a general way (like as a library) because you need to run code on the server. And as oth…

What does TCR mean please?

Re: Reflect – Multiplayer web app framework with game-style synchronization

#145

Post by moralestapia »

gnat wrote: post #106
chrisco255 wrote: post #100

Earlier quoted context omitted.

I don't know what LLW means, but you seem fixated on the acronym. It's just first come, first serve transaction ordering from the world I come from.

Perhaps it's a typo/braino for LWW, Last Write Wins.

It is! Thanks!

Re: Reflect – Multiplayer web app framework with game-style synchronization

#146

Post by holoduke »

hnav wrote: post #130
holoduke wrote: post #124

When will it finally be possible to use UDP protocol within browsers? TCP got way too big overhead. A multiplayer engine in which you send 30 messages per second for 128 users is what i need. Not possible with websockets withput having super computers.

Why does TCP have so much overhead? 30 messages that you don't batch is 30 packets either with TCP or UDP.

TCP got a much higher ping delay. For real fps like multiplayer experience you definitely need UDP. Packet loss should be ignored, not retried.

Re: Reflect – Multiplayer web app framework with game-style synchronization

#148

Post by alpyne »

aboodman wrote: post #89
lgessler wrote: post #57

As someone who's casually been eyeing up CRDTs for two years I've wondered continually what the story for authorization is, and this article seems to suggest (in line with my own understanding) that a CRDT library on its own like Y.js can't really handle applications where mutations need to be checked for authorization because it lacks a central authority (i.e., the server) while Reflect assumes that a server will be…

"Can't" is a strong word. You can get auth with a CRDT with effort, for example you can put a server in the middle of everything and have the server reverse any changes it sees which are unauthorized. This ends up being a lot of work to maintain and easy to break as the application gets bigger, and it also defeats some of the benefits of the CRDT in the first place (now the server has to mediate everything and you ca…

Any thoughts on this approach? (From the Local-First Berlin meetup in June) https://m.youtube.com/watch?v=pBvGeU7bL5A

Re: Reflect – Multiplayer web app framework with game-style synchronization

#149

Post by Slartie »

nwenzel wrote: post #59
hgs3 wrote: post #56

This is a pedantic comment, but the terminology is confusing. Games have "players" so their sync systems are called "multiplayer," but regular software has "users" so their sync systems should be called "multiuser." The page reads strangely mixing the terms "user" with "multiplayer."

Maybe. But user is like a consumer. So HN is multiuser, but seems weird to call HN multi-player. Live concurrent interactions feels like something more than multiuser. Just my 2-cents, but multiplayer as in multiple users acting and interacting is a good use of the term multiplayer.

Let me guess: you are not regularly playing multiplayer computer games?

I totally feel hgs3's confusion when reading the discussion here or that website. I always confuse the use cases - "are they now talking about computer games, or are they talking about the broader scope of any kind of software in which multiple users can act concurrently within a shared environment?".

I think this confusion would be much less severe if I hadn't been an avid gamer for decades and thus had a very specific idea of the meaning of the term "multiplayer".

Re: Reflect – Multiplayer web app framework with game-style synchronization

#150

Post by meheleventyone »

holoduke wrote: post #146
hnav wrote: post #130

Earlier quoted context omitted.

Why does TCP have so much overhead? 30 messages that you don't batch is 30 packets either with TCP or UDP.

TCP got a much higher ping delay. For real fps like multiplayer experience you definitely need UDP. Packet loss should be ignored, not retried.

This isn’t as true anymore but it’s definitely best practice to build on UDP. Games built on UDP normally have several different policies including the ability to send messages that guarantee delivery even if packets get lost.
Post reply on HN