You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to implement some form of real-time QoS guarantees in the EventReporter. That is, if enough events are generated within the system, we need to pick only the highest priority ones to send such that we don't create an infinite backlog of unreported events. This is especially important for the Sigfox publisher, whose ultra-low bandwidth capabilities mean that we likely won't be able to report every single event generated but should only report higher-priority events (we should also guarantee that we don't create DUPLICATE EVENTS when they are also reported via MQTT).
We can still store the unreported messages in local storage and send them again later when there are fewer events being generated and/or we have more bandwidth available, but let's save that for a future enhancement and just get the initial real-time system working for now.
The text was updated successfully, but these errors were encountered:
We implemented an initial version of this that basically finds the first EventSink (in the order they were added) that's available and sends it. Could alternatively have a configurable policy such as: all, all-highest, highest, first-available
Where highest/first are some notion of priority.
Furthermore, EventReporter could be cleaned up as it has a bunch of poorly documented hacks in it currently.
We need to implement some form of real-time QoS guarantees in the EventReporter. That is, if enough events are generated within the system, we need to pick only the highest priority ones to send such that we don't create an infinite backlog of unreported events. This is especially important for the Sigfox publisher, whose ultra-low bandwidth capabilities mean that we likely won't be able to report every single event generated but should only report higher-priority events (we should also guarantee that we don't create DUPLICATE EVENTS when they are also reported via MQTT).
We can still store the unreported messages in local storage and send them again later when there are fewer events being generated and/or we have more bandwidth available, but let's save that for a future enhancement and just get the initial real-time system working for now.
The text was updated successfully, but these errors were encountered: