Implement WebRTC communication & DMX data dump in a separate thread

[timekadel]

[ClosetGeek-Git]

Food for thought - Game servers often face the same issues I've been seeing ASLS have. One approach they use is to only send state changes and then patch the state on the server (or other nodes if peer to peer), that way they're only having to send and process the small changes that happen on the ms level in small bits rather than resending and reprocessing full state dumps 60+ times a second. This isn't a matter of sending things like button press events. The button press occurs on one client where it is processed and somehow changes a shared state, and the change within the shared state is encoded as a patch that is sent to other devices which then uses the patch to update the nodes state.

Here's a specification
https://www.cs.cmu.edu/~ashu/papers/cmu-cs-05-112.pdf

A unrelated gentleman created a JavaScript implementation by the same name (colyseus) which did well, however they changed the way they serialize data pretty significantly about 5 years ago which made it different than the document above. Their new 'schema' is still interesting though and very relevant .

Here is how they were doing it before the schema change, pretty much just msgpack and json-patch
https://github.com/colyseus/colyseus/blob/0.4.5/src/Server.ts

https://github.com/colyseus/colyseus/blob/0.4.5/src/State/Observer.js

[ClosetGeek-Git]

To clarify what I'm thinking, on the client (ASLS studio) only changes need to be sent into WebRTC in the form of a patch. These changes will be received as a patch on the WebRTC server which will patch the DMX state in order to update changes to the DMX state. Server sends in a fixed time loop, indifferent to DMX state or if it changes. To be honest, a lot of this can and likely should be done on the server rather than in a web worker.

I'm struggling to see the client server model that ASLS uses. There's no shared state if more than one ASLS client connects to the server, which would suggest unrelated clients? If there not related are they not for the same show? However, if this all revolves around one show, even if the clients don't share state, all the DMX processing could still be done on a dedicated node so that clients aren't processing graphics and DMX at once. I'm sure you've envisioned cueOS nodes somewhere in this mix. They could be doing a fair amount of processing themselves.