What if vector clock update reaches much before the actual update?

Question

In a normal Vector clock algorithm, the vector clock is piggybacked along with the request itself. What if the vector clock gets updated much before the actual request comes ? As in the vector clock and requests are updated independently and the request gets delayed for some reason.

Answer 1

There is lots of ambiguity in the question, but let me try...

Each node has its own version clock, representing every node in the system. A node can change state (version clock) in two cases:

1. A request from another node arrives. This request has a version clock from the other node. All regular version clock logic is applied here.
2. A request comes from outside, e.g. a user input on a given node. In that case, clearly, the request comes without any vector info. Technically, these are two different types of request and they are processed differently.

You could imagine that every node has two apis: one for external requests and one for requests from other nodes.

For the second (external) request, the node would update its own component of version clock stored on the node itself. That's it. Nothing more, nothing less. As an optimization, it could stop updating the clock until it sends data to any other node - own component needs to be updates AT LEAST once in between inter-node communication.

Now when this node sends updates to other nodes, this is where the version clock info is sent along. And the receiver do proper logic around version clock management.

Answer 2

You need strict ordering, but a request, vector clock or even parts of a request can arrive separately. Just like when you send a message on TCP, it is broken down to many packets and each packet arrives separately. On other end you wait till all parts are there before processing them.

So, in your question, on the receiving side, you have to wait until the request and the associated vector clock has arrived. They must becoming one after other with nothing else in-between on the same channel (connection), so that the receiver knows which request is related to which vector clock. Once all of it is received, it can process the request and the clock in an atomic update.