The current method of updating schedule mirrors assumes that communication is one-to-one and that all updates are successfully communicated. Attempts to make this more scalable by sharing an update topic amongst multiple mirrors are incompatible with attempts to make it robust to restarts, because existing mirrors end up receiving updates that they already have and get confused.
While this is solvable in the current synchronisation scheme, a cleaner solution can be achieved by reworking the synchronisation scheme. This includes
splitting participant updates from itinerary updates,
making participant information a persistent topic rather than a stream of patches, and
adding the database version a change comes from to itinerary updates.
Implementation considerations
The implementation needs to provide effective synchronisation of a database and its mirrors, but without increasing bandwidth too much. This means that, for example, just sending the whole database each time is not a feasible solution.
If itineraries are sent separately from participant information, it is feasible that a new mirror that joins may be sent the itinerary for a participant that it doesn't yet know about. Some way of storing these without knowing the participant is required. Options include:
a cache of received-but-unassigned itineraries, which would be periodically checked to see if the matching participant has been received, and
storing a new participant with most of its information empty, allowing the itinerary to be stored but not used until the corresponding participant information is received.
Probably the best way forward is to have a set of add, delete and update messages for itineraries and another for participants, and to use option 2 from above to give more flexibility to mirrors in how they use the received information.
Feature request
Description
The current method of updating schedule mirrors assumes that communication is one-to-one and that all updates are successfully communicated. Attempts to make this more scalable by sharing an update topic amongst multiple mirrors are incompatible with attempts to make it robust to restarts, because existing mirrors end up receiving updates that they already have and get confused.
While this is solvable in the current synchronisation scheme, a cleaner solution can be achieved by reworking the synchronisation scheme. This includes
Implementation considerations
The implementation needs to provide effective synchronisation of a database and its mirrors, but without increasing bandwidth too much. This means that, for example, just sending the whole database each time is not a feasible solution.
If itineraries are sent separately from participant information, it is feasible that a new mirror that joins may be sent the itinerary for a participant that it doesn't yet know about. Some way of storing these without knowing the participant is required. Options include:
Probably the best way forward is to have a set of add, delete and update messages for itineraries and another for participants, and to use option 2 from above to give more flexibility to mirrors in how they use the received information.