Optimal communication pattern to update subscribers

Question

What is the optimal way to update the subscriber's local model on changes C on a central model M? ( M + C -> M_c)

The update can be done by the following methods:

1. Publish the updated model M_c to all subscribers. Drawback: if the model is big in contrast to the change it results in much more data to be communicated.

2. Publish change C to all subscribes. The subscribers will then update their local model in the same way as the server does. Drawback: The client needs to know the business logic to update the model in the same way as the server. It must be assured that the subscribed model stays equal to the central model.

3. Calculate the delta (or patch) of the change (M_c - M = D_c) and transfer the delta. Drawback: This requires that calculating and applying the delta (M + D_c = M_c) is an cheap/easy operation.

If a client newly subscribes it must be initialized. This involves sending the current model M. So method 1 is always required.

Think of playing chess as a concrete example: Subscribers send moves and want to see the latest chess board state. The server checks validity of the move and applies it to the chess board. The server can then send the updated chessboard (method 1) or just send the move (method 2) or send the delta (method 3): remove piece on field D4, put tower on field D8.

Answer 1

Consider following scenarios: 1) client subscribes to changes and needs initial snapshot, 2) client subscribes to changes and does not need initial snapshot and 3) client needs only initial snapshot and not interested in changes.

For initial subscription, you can send a model snapshot (M) or its schema if snapshot is not required.

For updates, you need to calculate the delta to send to client. If the M is small, then D_c will be calculated easily. You could send the whole model to client, but what will happen when the model will grow? And you don't want to client to be aware of the business logic to send only C

Answer 2

You've forgotten about conflict handling. Is there only one place where the model is changed? What if two subjects are trying to change the model at the same time? What if one of the subscribers did not get one message because of an error?

For method 2 and 3 you'll need some kind of versioning and resync mechaism in case of errors or missed messages. In method 1 you're just overwriting local model with incoming one.

What is more, when new client subsribes it has no model. It'll need to ask for a full model in approach 2 and 3. That will fore you to have two-way communication.

What I'am saying is that approach 2 and 3 are way more complicated than 1. On the other hand this is a common pattern: colaborative document editing, version control systems (I mean Git, SVN), multiplayer online games. Look for standard solutions of such problems.