Vector clocks: build causal histories

Compare causal knowledge

Construct a causal history

Three processes maintain vectors with one counter for each process. A local event increments only its own component. Sending a message also increments the sender component and captures a copy of the resulting vector inside that message. Delivery is a separate action: the receiver takes the component-wise maximum of its vector and the message vector, then increments its own component. The diagram draws actual recorded events and message arrows. It does not infer communication from the order in which you clicked buttons. Two events on different processes can remain concurrent even though you created one before the other in the browser.

Choose actions and deliver messages

Acting process selects A, B or C for Local event and Send message. Destination selects the receiver for a send; choosing the acting process itself disables sending. Pending message lists only messages not yet delivered, including their sender, receiver and captured vector. Deliver selected message uses the destination stored in that message, independently of Acting process. This lets you leave a message in flight while either process continues computing. The event table repeats every action, its timestamp and its immediate causal parents, providing a readable alternative to the diagram. Start empty clears events and messages so you can construct your own experiment. History is capped at forty events; reset before making more.

Try delayed and reordered delivery

Start empty. Select A, choose B as Destination, and send twice. Message one carries [1,0,0]; message two carries [2,0,0]. Deliver message two first: B becomes [2,1,0]. Then deliver message one: B becomes [2,2,0], not [1,2,0]. The maximum operation prevents knowledge of A from moving backward. Notice that the receive counter still advances for the older message. A delivered message cannot be delivered again in this fixture. That rule models a chosen application-level deduplication boundary; vector clocks alone do not implement reliable transport or duplicate suppression.

Compare events rather than wall-clock time

First event and Second event choose timestamps to compare. Before means every component of the first is less than or equal to the second, with at least one strictly smaller. After reverses that relation. Concurrent means each timestamp has at least one component larger than the other. Equal is possible when selecting the same event twice. Start empty, create a local event on A and one on B, and compare them: neither has learned about the other, so they are concurrent. Send from A to B and deliver it. Compare the earlier A event with that receive event: the recorded communication creates a causal path and the first is now before the second.

Inspect the demonstration or build your own

Load demonstration loads a fixed ten-event trace, including independent work, two sends from A, reversed delivery and onward communication to C. Play reveals that history over sixty inspection seconds. Pause holds the current prefix. Next event advances one action; Restart rewinds without deleting the loaded history. Speed changes playback between half, normal and double speed. Inspect time scrubs the history. Show all displays the final state immediately. Creating a new action while inspecting an earlier prefix deliberately branches from that prefix and discards its unseen future; the status message reports that change. The compact diagram places event number vertically, so longer histories never wrap over older events.

Understand the boundaries

These clocks model causal knowledge for fixed membership of three processes. There are no physical timestamps, synchronized clocks, process crashes, counter resets, membership changes or finite-width overflow. Messages remain pending until you explicitly deliver them; there is no simulated network latency or automatic timeout. The vertical ordering is an inspection sequence, not a claim that unrelated events share a global clock. Concurrent does not necessarily mean a business conflict, and causally ordered does not mean an operation succeeded. Applications still need domain-specific conflict resolution, storage guarantees and transport behavior. The experiment is a direct executable model of counter propagation, not a consensus algorithm or a performance benchmark.