The complexity depends on what constraints you put on yourself. Here's an example, suppose you have a UI panel with a number of checkboxes, radiobuttons, and sliders, and you want to synchronize the state across several users, without blocking (i.e. if a user changes state, he doesn't need to wait for server response to change change state again). Global state exists on a single server. Let's say your users start changing state furiously, what happens? ...well, the object state will live in several places (and slightly different for every client):
1) Local: In the view but before event dispatched to the model.
2) Local: In model but before it was synced to the server.
2a) Local: After model sync and in queue waiting to be sent to the server.
3) Remote: In transit to the server.
4) Remote: On the server (i.e. the one true state).
5) Remote: In transit to the clients.
6) Local: Received but before it was synced to the model.
7) Local: In model but before synced to the view.
8) In the initial state sync (e.g. when a new client joins)
So at any given point, every client state is inconsistent with every other client (maybe even significantly if the latency for one or more of the clients is bad) since pieces of the eventual state are spread across all these locations. If now every user stops changing state furiously, every client should eventually be consistent. It's not a hard problem but not completely trivial. For example, you will need conflict resolution rules on the server and in your client and traditional distributed issues like (temporary) network partitioning and latency need to be taken into account. Message ordering will probably matter.
>It sounds like the client is just trying to receive a stream of updates, which could have been made by a single writer
Not necessarily. You have the same synchronization issues whether the updates are coming from a single source, or from multiple sources.