Distributed Objects
A major change compared to the previous version of the PLANET application is the introduction of distributed object concept. This concept was defined to address the problem of data synchronisation between instances. This concept goes hand in hand with another one, named distributed action. The messages exchanged between instances are not directly the objects, but the actions that are applied to the objects (creation, update, deletion). For the sake of simplicity, we will limit ourselves to talking about distributed objects in the rest of this section.
By relying on those concepts, several aspects are taken care of:
Automatic data synchronization through customizable re-emission/cancelling policies, especially for objects missed while offline.
Support of efficient codecs to optimize bandwidth usage.
Resolution of simultaneous modifications from several instances.
The following data classes are currently implemented as distributed objects in the system:
Chat messages
Chat channels
Geomarkers
Telemetries
File Transfers
Customs
Caution
Users are not implemented as distributed objects, which means that users’ lists are not shared between instances. Each instance has its own users’ list. A login/password created on a specific instance (for instance the ground) won’t work on another one (for instance an aircraft), unless the same login/password has been created on this instance as well.
Default sync policies
Synchronisation is performed when an aircraft connects to the system, i.e. when the air-to-ground connection is up.
Each object class has a default synchronisation policy. There are three possible synchronisation policies:
Never: objects are never re-synchronized between instances. If an instance missed an object, it will never be re-synced.
Always: objects are always re-synchronized between instances. If an instance missed an object (even created a while ago), the system ensures the re-sync as soon as the aircraft connects.
Hours (N): objects are re-synchronized if the last action (creation, update, deletion) performed on this object is less than N hours old when the aircraft connects.
The following table summarises the default synchronisation policy per object class.
Object Class |
Default Sync Policy |
|---|---|
Chat Message |
Hours (24) |
Chat Channel |
Always |
Geomarker |
Always |
Telemetry |
Hours (1) |
File Transfer |
Never |
Customs |
Not sent between instances yet (only local to the instance which created it) |
Note
For each object class, the default policy can be modified in the mission configuration. See Mission Configuration appendix for details.
In practice…
Here are some concrete cases resulting from the implementation of distributed objects:
for geomarkers, there is no need to wait for the aircraft to be connected to create them. When the aircraft gets connected, they will be automatically synchronised.
for chat messages, all messages sent during the last 24 hours will be re-synced when the aircraft gets connected.
for telemetry, data sent during satcom outages is automatically re-sent after reconnection (if the outage is less than 1 hour, with the default policy).