** Notice: all internal pipelines have been restricted to 30 minute timeouts, if your CI/CD runs take longer, either use your own runners or read below **
We would remind everyone that the CI/CD services provided by the university Gitlab servers are intended for CI/CD use only (ie. delivering new versions of your software to your production servers, etc).They are not intended for data analysis or -production use, or creating, building and running servers to do heavy data calculation or visualization.
As a general guideline; if your jobs take more than 15 minutes, you might be running something that is better suited for a dedicated system or a virtual server - in this case, please contact the helpdesk for a solution to your needs.
* Received changes are applied as patches or changes to sending state when new frame is constructed.
* 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
* 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
