HN Reader

Thanks for sharing. I liked the short video.

These have been around for a few years. Wonder what people built with them since. Anyone know of any popular distributed systems using them nowadays? (I noticed the company the author mentioned shut down https://medium.com/@MeetLima/this-time-its-goodbye-5573a97be...)

As an additional resource I liked the description of ITC by Fred Hebert: https://ferd.ca/interval-tree-clocks.html. He is the author of the wonderful Learn You Some Erlang book. There is an ITC library he maintains as well: https://github.com/ferd/interval-tree-clocks, started by Paulo Sergio Almeida.

I used these in a distributed sync in about 2013-2014. When Postgres got JSON support we ended up going centralized for that product and a simple logic clock was all we needed. Nevertheless, I still think they’re very cool.

the link in the paper referenced goes to some auto-scrolling page with all kinds of content. I found a direct link here:

http://hydra.azilian.net/Papers/Interval%20Tree%20Clocks.pdf

Interval tree clocks seem really cool, and I’d love to use them for something. But unfortunately I can’t think of a way to reliably have a system automatically subdivide an interval to bring new servers up without getting pathological behaviour sometimes. Or, if an identifier (interval) goes offline indefinitely, I can’t think of any good way to clear it.

In practice, vector clocks / version vectors built using uuid identifiers for machines seem easier to work with, and they’re very predictable. Slightly less efficient - but versions take up a tiny percentage of network traffic and disk space that I don’t think it matters.

I really want to use interval tree clocks for something. It’s such a cool algorithm. But I don’t know what I’d use them for - beyond maybe a set of manually provisioned servers syncing data or something.

The blog article didn't mention what to do when a node fails, and therefore is unable to hand over its section of the curve to another node.

Several things remain unclear:

"The beauty of this scheme is that a node only has to know about its share of the interval"

The article doesn't explain curve changes in much detail, but I assume it increases the portion of the curve "owned" by the node.

With unique identifiers all a node needs to know its identifier. So that can't be what's interesting about these interval portions.

Also:

- How that curve is initially drawn isn't clear at all. Is it flat and becomes complex over time by forking (+ data modification)?

- Why are interval boundaries real-value in a system that cannot actually express real numbers?

- How are the intervals / portions decided? Is that simpler than generating UUIDs?

- How does comparison work?

"Comparison works similarly to Version Vectors: if the curve of a stamp is above the other one, it descends it, otherwise the curves intersect and the stamps are concurrent."

But now you have events with curves and intervals where one event might miss a portion. It's not immediately clear what happens in that comparison. It's maybe obvious to some readers but clearly not an audience that needed introduction for the other things initially explained by the article.

In terms of conclusions:

My understanding is that the main benefit is that the overall complexity of the "vector" becomes simpler in light of actor explosion due to the merging mechanism. Whereas UUIDs (or even monotonous index indexed vectors) would grow indefinitely, making tracking them on events a challenge.

This intro article fails to make this stuff clear.