Improve node resolving for nodes offline at startup #357
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When one or more nodes are offline/unavailable (e.g. powered off, out of range, out of battery) at server startup, no automatic subscription is set-up for that device. Because the SDK does not expose a way to add a callback when a known node is discovered on mDNS, we do a regular poll to see if the device is back alive. This is now fixed and the poll interval is a little bit increased. It will start with a 30 second interval, slowly increasing that with 10 seconds to a maximum of 10 minutes, meaning that if one of those devices comes back online, it will take max 10 minutes for the server to pick the device back up again.
Once a device subscription has been set-up, a resubscription is done within a few seconds by the SDK.
It will however take 3 minutes before we detect that a device is offline which seems like a fair tradeoff between traffic vs comfort.
If we want to improve this even further, we may consider implementing zeroconf discovery within the server to actively listen for mDNS broadcasts for nodes we're watching but as this is a bit of an edge case (the device offline just while restarting the server) it may not be the highest priority.