8. Timestamps are claims
Timestamps are what the author claims and no one can verify; if only you write in your subspace no other clock can touch it; the dangerous case is future-dating your own writes.

8. Timestamps are claims

Timestamps are what the author claims and no one can verify; if only you write in your subspace no other clock can touch it; the dangerous case is future-dating your own writes.

"Wall clocks in a distributed system" is the first objection every engineer raises.

The timestamp on an entry is what the author stamps on it. No one can verify it.

So what can a wrong clock do? If only you write in your room, no one else's clock can touch it.

The real danger is your own clock running fast. A far future entry blocks your later writes under that path, until time catches up.

So peers may refuse entries too far ahead of their own time. And a write ticket, which comes later, can bound the timestamps a writer may claim.

Why not track causality with a vector clock instead? That needs a slot for every concurrent writer, with no bound in a peer to peer system.

Check yourself. Whose data can a wrong clock damage?

Do you like what you are reading? Subscribe to receive updates.

Unsubscribe anytime

Connections0

Connections show where other documents or comments link to this document.

Related documents

Loading connections…