Data flow
Establishing the correct data flow between various applications and servers is essential to proper design of the delta set and the subsequent communication protocol.
This page describes the AECDeltas implementation of the data transfer protocol.
A simple protocol for the data transfer would look like this:
- The status of the latest revision is checked;
- Revision ID is obtained:
- ID is recognised, or
- ID is not recognised, a list of all revision IDs is requested:
- Overlap is found with some earlier revision, or
- Overlap is not found, all object IDs of the latest revision are requested;
- Diff is calculated;
- Delta updated is sent across.
AECDeltas expanded over this simple implementation and further defined the data sequence for different scenarios.
A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner. -Wikipedia
Our proposed protocol can be translated into five different sequence flow scenarios as follows:
- Push of a new model. The base case is to send a new model/project to the server and/or client application for the very first time.
- Server is behind. When the server is behind the latest revision, the client calculates the differences and sends a delta upstream.
-
Conflict:
- Client is behind. Client is working on a revision which becomes out of date. It then calculates the differences and sends the delta upstream.
- Two clients are pushing the same revision. Two clients update the same revision simultaneously which leads to one of them being out of sync. The affected client then calculates the differences and sends a delta upstream.
-
Client is pushing an existing revision. Client pushing an existing revision to the server results in a
nulldelta.
In Scenario 1, a new project with its first revision gets established on the server. This is the base case whereby the user creates a new project and "pushes" it to the server. Since the server does not recognise this project in its database (because it is new), it obtains the revision data and stores it accordingly. The return message then indicates the transaction completed successfully. In this case, the delta is the entire model.
In Scenario 2, the client performs changes locally and thus advances the revision forward meaning the server is left behind. Thus, the client retrieves the latest revision, enacts changes locally and pushes a new advanced revision back to the server. Since the server is behind, it responds with its latest revision number which is used by the client to calculate the delta in order to send it upstream to the server. The return message then indicates the transaction completed successfully.
In Scenario 3a, two different clients, say A and B, retrieve the same revision from the server and perform their respective changes locally independently of each other. Then, client B pushes their changes to the server by enacting Scenario 2. Client A attempts to achieve the same, however is in conflict since their revision is now behind the server. Thus, client A calculates the differences and pushes the delta to the server or decides to postpone the action to a later date. The return message then indicates the transaction completed successfully.
This scenario might be updated and expanded upon in the future.
In Scenario 3b, two different clients, say A and B, retrieve the same revision potentially from different sources and then attempt to push their respective changes enacting Scenario 2 and 3a. However, instead of concluding with sending a delta back to the server, client A performs local updates and then enacts Scenario 1 in order to advance the revision further. The return message then indicates the transaction completed successfully.
In Scenario 4, a client is passing a revision from server 01 to server 02. However, 02 is already at the latest revision, thus the delta calculated by the client is null and no further data needs to be exchanged. The return message then indicates the transaction completed successfully.