Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accept, and use, a time-offset from SD for data which SD sends to MS (posts, feedback, SD stats, etc.) #879

Open
makyen opened this issue Sep 15, 2021 · 1 comment
Labels
area: SD integration This involves coordination with changes in SD. status: planned We like the idea and might get around to it at some point. type: feature request Requests for a new feature.

Comments

@makyen
Copy link
Contributor

makyen commented Sep 15, 2021

General problem: MS is not up 100% of the time, so isn't available to accept reports or feedback from SD during some periods.

While MS is down, I'd like to have SD cache the data which it's expecting to send to MS and (re)send the data when MS is back up. In order to have the creation dates for any such records (at least posts, feedback and SD stats) reflect when they actually happened, rather than when MS is back up and SD has successfully send them, the time at which they should be recorded needs to be transmitted from SD to MS and MS needs to account for the time SD says for the original transmit time when MS assigns created_at timestamps.

In order to also account for inevitable lack of clock synchronization, I'm assuming that SD would transmit an offset value from when SD felt the data should have first been transmitted and when the data was actually transmitted (e.g. creation_offset = epoch now - epoch at time first attempted to send the report to MS).

From SD's POV, the easy way to implement caching would be to just keep a queue of HTTPS requests which SD would have sent if MS was available along with the epoch time when the request was, or wold have been, originally attempted. Once MS is back up, SD could just transmit everything that's in the queue with an additional time offset value.

@makyen
Copy link
Contributor Author

makyen commented Sep 16, 2021

@makyen makyen added type: feature request Requests for a new feature. status: planned We like the idea and might get around to it at some point. area: SD integration This involves coordination with changes in SD. labels Jul 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: SD integration This involves coordination with changes in SD. status: planned We like the idea and might get around to it at some point. type: feature request Requests for a new feature.
Development

No branches or pull requests

1 participant