Network code is hard. Events come all the time and it's really difficult to account for all orderings and uncanny timings. Have you got any advice, book or paper about it that I should read?
I'm using node and websockets btw.

That's a very vague description.

Care to elaborate?.

If you can find a course on distributed systems on YouTube or something (say MIT OCW or whatever), I'd highly recommend that. This is bread and butter stuff for them.

If not, a textbook on distributed systems, like Tannenbaum's, might help out. Networking books don't cover this kind of stuff all that much, you'll find what you're looking for in distributed systems literature.

Regarding timings I'd strongly recommend looking at logical time such as Lamport clocks or vector clocks. Like @RememberMe said distributed systems is the way to go

@IntrusionCM I have a game, a varying number of components with different lifespans communicate over their own channels that are muxed through the same websocket. I know they'll block each other, but I need guaranteed message order for some of them. The channel setup has to be persisted even if the connection breaks, and in case of a broken connection some channels have to be buffered for guaranteed delivery.

This is what the protocol needs so far, I've initially divided it into persistence and guaranteed delivery and separated multiplexing, but the former seems too big and I'm getting arcane timing-related bugs.

As I've gone into embedded systems I've started to understand how hard to catch race conditions like these can be

It gets worse when I have to consider that at any point in time any of my components may crash, go offline and reboot

And exactly at that point have I realized why Rust Devs seem to be so keen on getting rid of race conditions at compile time

@LotsOfCaffeine once you have learned rust it's actually really nice but it's a real pain before that point

@matt-jd I've only dipped my toes into Rust, though I do wanna work more with it in the future