Runner bring answer before runner bring question — BAD

Ugg tell tribe about talking-between-caves. Caves far apart, so a cave send message by runner. Runners take different paths through the forest, some slow, some fast. Sometimes the runner with the ANSWER beat the runner with the QUESTION. Tribe hear "noon!" before anyone ask "what time?" Ugg fix this today.

Three way to line up the runners

FIFO (first-in, first-out) — message from the SAME cave come out in the same order that cave sent them. Ugg shout "one" then "two"; you hear "one" then "two". A little tally-number on each rock do this. But FIFO watch only ONE cave at a time — it no care about other caves.

Causal order — the big rock today. If MAKING one message caused the MAKING of another message, and both go to the same cave, the cause-message must arrive-and-be-read FIRST — even when TWO DIFFERENT caves send them. Ugg carve the fire-formula:

That little arrow $\to$ is happened-before, the footprint-rule of Ugg-ancestor Lamport. It follow the cause down ANY path, even through a middle-cave. Read it: if the sending of first-rock happened-before the sending of second-rock, then read first-rock before second-rock at the shared cave.

Total order — the strongest. ALL caves read EVERY message in the SAME single line, top to bottom, same for everybody. Even two messages that did NOT cause each other (Ugg call these concurrent — happen side-by-side, neither one cause the other) still get shoved into one agreed line. Ugg carve strength on the wall:

Bigger animal eat smaller.

Why FIFO not enough (the trap)

Cave-1 send rock $m_1$ to Cave-3. Then Cave-1 send word to Cave-2. Then Cave-2 — now knowing — send rock $m_2$ to Cave-3. So the making of $m_1$ happened-before the making of $m_2$; the cause walked through Cave-2. Cave-3 SHOULD read $m_1$ first.

But FIFO shrug. $m_1$ and $m_2$ come from DIFFERENT caves, and FIFO line up only same-cave rocks. So $m_2$ can jump ahead and Cave-3 read the answer before the question. Ugg warn: no trust FIFO for cause that cross between caves!

BSS — the notch-stick trick

Birman-Schiper-Stephenson (BSS) is the clever fix. Every cave $P_i$ keep a vector clock $V_i$ — a row of notches, one count for each cave in the tribe. Count how many rocks each cave has sent.

**When cave $P_i$ send a rock to $P_j$:** add one to its own notch, $V_i[i]:=V_i[i]+1$. Then tie a COPY of the whole notch-row onto the rock — Ugg call this piggyback — and carry it along as $V_m$.

**When a rock $m$ from cave $P_j$ arrive at cave $P_i$:** do NOT read it yet. First check TWO things.

Check (a): $V_m[j]=V_i[j]+1$ — this rock is the very NEXT rock Ugg expect from cave $P_j$, no skip, no gap. (This part IS just FIFO from $P_j$.)

Check (b): $\forall k\ne j:V_m[k]\le V_i[k]$ — for every OTHER cave $k$, the sender saw no MORE of $k$'s rocks than Ugg already saw. If the sender saw more, some earlier cause-rock is still out in the forest — WAIT for it.

If BOTH true — read the rock. This reading is called deliver. Then bump the notch: $V_i[j]:=V_i[j]+1$. If either check fail — drop the rock on the wait-pile by the cave door (buffer it) and re-check the whole pile every time a new rock arrive.

Ugg say LOUD: receive is a rock touching the cave door. Deliver is Ugg actually READING it and acting. NOT the same thing! The wait-pile hold rocks received-but-not-yet-read. Mix them up and you fail.

Why the two check

Check (a) stop skipping. Ugg read cave $P_j$'s rocks one, two, three — never jump to three before two. And when both rocks come from the SAME cave, causal order shrink down to plain FIFO — check (a) alone do the whole job.

Check (b) is the cause-magic. The sender's notch-row shows which OTHER caves' rocks the sender had seen. If $V_m[k]>V_i[k]$, the sender saw a rock from $P_k$ that Ugg has NOT seen yet — read now and you read the effect before its cause. So wait. Ugg warn LOUDEST: FORGET check (b) and BSS shrink back to plain FIFO — the whole causal trick die! No do this!

Where the tribe use this

Replicated databases — many caves keep a copy of the same berry-count. An update that leans on an earlier update MUST be applied in cause-order, or the count go wrong.

Group communication — the chat! Bob ask "what time?" (rock from Bob to Charlie). Alice hear it and reply "noon" (rock from Alice to Charlie). Different senders, so FIFO no help. BSS causal order guarantee Charlie see the question before the answer.

Distributed debugging — follow footprints cause-then-effect, never effect-then-cause.

For state-machine replication (many caves run the same rule-machine in lockstep, like Raft or Paxos), causal is NOT enough — you need Total order, and Total need the WHOLE tribe to agree (consensus).

Ugg warn — traps by the fire

Causal is NOT the same as FIFO. FIFO order only same-cave rocks; Causal order ANY cause-linked pair.

Total is NOT just "causal on all rocks." Total also line up the concurrent rocks that no cause each other; Causal leave those two free to arrive either way.

The wait-pile can grow HUGE if one cave is slow — real tribes cap the pile size. And strict cause-order cost you late rocks when many rocks fly at once. Trade cause-safety against speed.

Ugg remember

• Causal order: cause-rock read before effect-rock at the shared cave — $\text{send}(m_1)\to \text{send}(m_2)\Rightarrow \text{deliver}(m_1)\to \text{deliver}(m_2)$. Beat FIFO because it work ACROSS different senders.
• BSS two check: (a) $V_m[j]=V_i[j]+1$ = no skip / FIFO-from-sender; (b) $\forall k\ne j:V_m[k]\le V_i[k]$ = all earlier cause-rocks already arrived. Fail either → buffer, re-check later.
• Strength wall: $\text{Total}\succ \text{Causal}\succ \text{FIFO}$. Total need consensus and order even concurrent rocks; use it for state-machine replication.
• Receive is NOT deliver. Rock at the door is not a rock read. The wait-pile (buffer) hold the in-between rocks.
• Drop check (b) and BSS collapse back to plain FIFO. That is the classic blunder — no do this!