-
Notifications
You must be signed in to change notification settings - Fork 4
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
[WIP] Re-Implement Monitors #64
base: develop
Are you sure you want to change the base?
Conversation
Can you describe briefly the mechanism by which this is supposed to work? it looks to me as though the uptime tracker is used in some way to remove dead entries for dmsg discovery. I believe in the previous implementation, you were attempting to make transports to each of those keys in dmsg discovery with the dmsg monitor. Both of those methods are incorrect for dmsg-discovery. The only option for dmsg may be to implement a heartbeat for dmsg discovery. In that way, the client re-registers itself and any keys may just be expired once a certain time has passed without re-registration. One can run a dmsg client for any purpose - separately from the visor ; or even for no purpose. In that instance, there is no endpoint that can be checked externally to ensure that it is actually online, and our only concern is to have a feedback mechanism which will prevent the database of entries from expanding endlessly. This is also the case for any long-lived dmsghttp client such as Unless my analysis is flawed, I suggest we drop the dmsg monitor altogether at this point. |
Fixes: #63
Changes:
How to test: