[tahoe-lafs-trac-stream] [tahoe-lafs] #1765: gossip-introducer should include timeouts

[tahoe-lafs]

#1765: gossip-introducer should include timeouts
----------------------------+------------------------
 Reporter:  warner          |          Owner:  warner
     Type:  enhancement     |         Status:  new
 Priority:  normal          |      Milestone:  soon
Component:  code-nodeadmin  |        Version:  1.9.1
 Keywords:                  |  Launchpad Bug:
----------------------------+------------------------
 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.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1765>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage