Vector clock and Lamport timestamps

[acailly]

Hi, I just watched the talk at React London and I wondered if the part of time could have been handled with vector clock and lamport timestamps like realm database seems to do for its conflict free sync?

Vector clock: https://en.wikipedia.org/wiki/Vector_clock
Lamport timestamp: https://en.wikipedia.org/wiki/Lamport_timestamps
Post in HackerNews thread about the implementation: https://news.ycombinator.com/item?id=12590753

Just asking for curiosity 😉

[ai]

Hi. Good question :).

First, what clock is better for distributed system is still an open question. Different implementation has many different types of clocks with own benefits and disadvantages. Maybe we don’t ideal clock for every case.

Logux requirements:

1. It should guarantee unique ID on every machine. To have the consistent order of actions.
2. ID generated later should be bigger. So reason will be before the result.
3. Because I plan to migrate many normal web developers, time should tell when an exact action has happened — Wednesday or Thursday? During working time or now?
4. An application could work without internet connection for days. And if we create some action on the server and on the client without connection, we should tell what action was earlier.
5. Client machine time could be wrong.

Vector and Lamport clock solves only 2 and 5 requirements. And doesn’t solve 1, 3 and 4.

Swarm.js combine unique node ID with Lamport clock to solve, 1, 2, 5 requirements. But 3 and 4 is still open.

To solve all these requirements Logux uses own clock [timestamp, uniqueNodeID, actionNumberInCurrentMillisecond].

But clock doesn’t really hard-coded in Logux components. If your tasks need Lamport clock, you still can do it:

log.generateId = function () {
  return [nextTick(), this.nodeId, 0]
}