Thanks for the article! I love lamport clocks, and the lightweight methods are cool.
I read through the article a couple of times, and was unsure about something:
When the browser resets, it does not appear to copy down the current state and clock value from the server, right? I'm basing that on this from the article:
The browser resets, all the state is dropped.
browser: settings: none, clock: 0
backend: settings: foo, clock: 2
I don't think that lamport clocks can be compared if they are not representing any concept of causality or knowledge, right? This implementation appears to be two separate integers (one for the client and one for the server), with no guarantee as to their ability to communicate with each other. One bug you discovered was that the server might have a value 2, and the client might have a value 2, but they would disagree on the state that value "2" referred to. A bug indeed!
Your fix was to handle the case where the client and server tied. However, I was left wondering: What about the case where the knowledge of the client is higher than the server, but the server still should not trust it? What if, in your example step 4, the client had made 3 changes without the ability to sync with the server?
It would be this:
The user changes the settings three times, but this time the state is not propagated to the backend (e.g. due to network hiccups).
browser: settings: none, clock: 3
backend: settings: foo, clock: 2
In that case, by the time the client talks to the server, the server would think that the client had "won", but the fact that the client had a clock value of "3" would be meaningless, right? Wouldn't you still want the server to win in this case?
Yes, you are right. To rephrase, you say that a browser could first increment its clock to the value larger that the backends, and then synchronize and "win" with the backend, setting the backend value to some bogus "none".
I'd say that it's "fine" in a way that the browser and the backend agree to "something" and are in sync. The case we wanted to prevent was that the browser and the backed hold different values and cannot agree which value to converge to.
I read through the article a couple of times, and was unsure about something: When the browser resets, it does not appear to copy down the current state and clock value from the server, right? I'm basing that on this from the article:
I don't think that lamport clocks can be compared if they are not representing any concept of causality or knowledge, right? This implementation appears to be two separate integers (one for the client and one for the server), with no guarantee as to their ability to communicate with each other. One bug you discovered was that the server might have a value 2, and the client might have a value 2, but they would disagree on the state that value "2" referred to. A bug indeed! Your fix was to handle the case where the client and server tied. However, I was left wondering: What about the case where the knowledge of the client is higher than the server, but the server still should not trust it? What if, in your example step 4, the client had made 3 changes without the ability to sync with the server? It would be this: In that case, by the time the client talks to the server, the server would think that the client had "won", but the fact that the client had a clock value of "3" would be meaningless, right? Wouldn't you still want the server to win in this case?