[x] I documented the TypeScript code using JSDoc style.
[x] I added multiple screenshots/screencasts of my UI changes (NA)
[x] I translated all the newly inserted strings into German and English (NA)
Motivation and Context
With current implementation of realtime collaboration, there is potential for stuttering: the client updating to a state that is quickly overwritten by another state. The phenomena is explained in detail here. This PR refactors the solution to provide it out-of-the-box on Apollon itself.
Stuttering targeted by this PR can happen in the following scenario:
Client A issues change X. Client A is on state X.
Client B issues change Y. Client B is on state Y.
Server sends X to both clients. Both clients go to state X.
Server sends Y to both clients. Both clients go to state Y.
Client A has an expected behaviour in this scenario, with the client observing state sequence I -> X -> Y. Client B however observes the sequence I -> Y -> X -> Y, which when happening in quick succession, results in "stuttering" (the state quickly changing and then reverting back). A client can also self-stutter:
Client issues change X.
Client issues change Y.
Server sends X to clients. Client goes to X.
Server sends Y to clients. Client goes to Y.
The state sequence observed by the client will be I -> X -> Y -> X -> Y, which is the same stuttering.
Description
This PR brings over the fix from this PR into Apollon itself. With this mechanism, a client stores a hash for each change it issues on a particular address in the state object, and optimistically ignores all other incoming changes on that particular address until the server recognises its own issued change, as it predicts the server will eventually affirm said change and all prior changes to that address will be overwritten by that local change nevertheless. This increases stability of the state sequence and prevents the aforementioned stuttering.
Checklist
I added multiple screenshots/screencasts of my UI changes(NA)I translated all the newly inserted strings into German and English(NA)Motivation and Context
With current implementation of realtime collaboration, there is potential for stuttering: the client updating to a state that is quickly overwritten by another state. The phenomena is explained in detail here. This PR refactors the solution to provide it out-of-the-box on Apollon itself.
Stuttering targeted by this PR can happen in the following scenario:
Client A has an expected behaviour in this scenario, with the client observing state sequence I -> X -> Y. Client B however observes the sequence I -> Y -> X -> Y, which when happening in quick succession, results in "stuttering" (the state quickly changing and then reverting back). A client can also self-stutter:
The state sequence observed by the client will be I -> X -> Y -> X -> Y, which is the same stuttering.
Description
This PR brings over the fix from this PR into Apollon itself. With this mechanism, a client stores a hash for each change it issues on a particular address in the state object, and optimistically ignores all other incoming changes on that particular address until the server recognises its own issued change, as it predicts the server will eventually affirm said change and all prior changes to that address will be overwritten by that local change nevertheless. This increases stability of the state sequence and prevents the aforementioned stuttering.
Steps for Testing
See this
Test Coverage