Stuttering prevention in Apollon itself #343
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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