search

balena-os / balena-supervisor

Balena Supervisor: balena's agent on devices.
https://balena.io
Other
150 stars 63 forks source link

Prevent sending current state on boot if cloud already has that state #1669

Open 20k-ultra opened 3 years ago

20k-ultra commented 3 years ago

When the device is sending the current state we can prevent the additional bandwidth by hashing the current state that is about to be sent to the cloud in an e-tag which will allow the server to return a 304 which indicates the values are the same. If that happens we know not to report anything which saves bandwidth.

This is additionally beneficial if the Supervisor is rebooting consistently for some reason and sending patches. This would increase bandwidth as well as load on the server for processing the patch.

cywang117 commented 3 years ago

This is a good idea - I took a look at (open)-balena-api repos and couldn't see any existing implementation for Etags + 304, except for this unrelated code block for denying deleted devices. Meaning both API and Supervisor would need to make changes. Arch call material?

20k-ultra commented 3 years ago

Reading this again it doesn't make sense but I understood what I was saying after reading the previous titled that I changed.

Writes cost more then reads as a read can be cached. So the idea is to leverage reads to save writes. We can do this by asking the API on before sending the current state what the current state is. If the device sees the API has the same state then there's no need to send another update just to populate our local value lastReportedLocal.

The etag component therefore isn't necessary as you'd only use that when requesting the get current state again but we only do that when we don't have a value for lastReportedLocal. Btw, the etag functionality would be automatically given by express and the Supervisor would have to do the hash which isn't usually how that flow goes (only one end, the server, computes the hash and the client just passes it back).