Opened at 2012-06-12T23:09:21Z
Last modified at 2016-03-31T14:34:28Z
#1765 new enhancement
gossip-introducer should include timeouts — at Initial Version
Reported by: | warner | Owned by: | warner |
---|---|---|---|
Priority: | normal | Milestone: | soon |
Component: | code-nodeadmin | Version: | 1.9.1 |
Keywords: | gossip introduction | Cc: | |
Launchpad Bug: |
Description
Just a note-to-self: when #68 gets working, and decentralized gossip-based introduction is implemented, we should make sure the announcements are:
- 1: refreshed periodically
- 2: are dropped by clients when they're stale
The idea is that a server who has left the grid permanently should eventually be forgotten by everyone else. Gossip never forgets (even if you forget it locally, you'll be reminded by your cohorts, and if you don't remember what you forgot, you'll fail to forget it again).
The simplest way to accomplish this is with a timestamp in the announcement, and to prune entries more than maybe a month old. (but wait a few minutes after startup to do that, so if you leave your node offline for several months, it still has a chance to connect to somebody and fetch fresh announcements).
We aren't usually keen on timestamps, in particular comparing time from different nodes (in this case, the announcement's timestamp plus one month versus the client's clock). But I think this would be a reasonable use of clocks. As of yesterday, the announcement record includes a timestamp, named "seqnum" (so named because I didn't want to make any claims about it's use as a timestamp, but merely as a mostly-monotonically increasing number, used to decide when one announcement may replace another).
Maybe I should rename that to "when" or "announcement-time"?
The Introducer Client still needs code to refresh its announcements periodically (once a week would be fine). Currently it only refreshes them at node boot, and we don't want live-and-connected nodes with good uptime to start being ignored merely because they weren't rebooted frequently enough.