... | ... | @@ -27,5 +27,11 @@ Hence the following is true: |
|
|
* Received changes are applied as patches or changes to sending state when new frame is constructed.
|
|
|
* Flushing a frame applies the changes to sending state in addition to transmitting
|
|
|
|
|
|
Are states or change lists timestamped? Seems unreliable as a way to stay synced.
|
|
|
Are states or change lists timestamped? Seems unreliable as a way to stay synced. Another option is to flag changes as being forwarded already and therefore not subject to a secondary transmission. The cycle being: 1) flush change to local send state and transmit. 2) Receive change and mark as *foreign* into received state. 3) Take these *foreign* changes into a new frame. 4) Transmit new frame including local and *foreign* changes. 5) Receive *foreign* changes but now unmark as changed and don't includes as changes in new frames.
|
|
|
|
|
|
Hence the following is true:
|
|
|
* Need a flags property to mark changes as *foreign* upon receipt (if not already foreign).
|
|
|
* Changes received already marked as *foreign* are fixed as non-changes (not to be forwarded)
|
|
|
* Receive state must maintain list of *foreign* changes, moved to new frames.
|
|
|
* Received *foreign* changes become fixed once new frame constructed that takes those changes
|
|
|
|