[tahoe-lafs-trac-stream] [tahoe-lafs] #1765: gossip-introducer should forget about old nodes somehow

[tahoe-lafs]

#1765: gossip-introducer should forget about old nodes somehow
--------------------------------+--------------------
     Reporter:  warner          |      Owner:  warner
         Type:  enhancement     |     Status:  new
     Priority:  normal          |  Milestone:  soon
    Component:  code-nodeadmin  |    Version:  1.9.1
   Resolution:                  |   Keywords:
Launchpad Bug:                  |
--------------------------------+--------------------

Comment (by davidsarah):

 Replying to [comment:3 warner]:
 > Replying to [comment:2 zooko]:
 >
 > > 1. When telling other people gossip about servers, you don't tell them
 > >    about servers that you aren't currently connected to.
 > > 2. Remember the fact that you were unable to connect to a server last
 > >    time you tried. When you start up, don't try reconnecting to that
 > >    guy right away until you've finished trying to reconnect to
 > >    more-likely-to-work ones. (Because of a bug that is really
 > >    important on Windows: #605 (two-hour delay to connect to a grid
 > >    from Win32, if there are many storage servers unreachable))
 > > 3. If it has been more than a month on your local clock since you were
 > >    able to connect to that guy, and you are currently able to connect
 > >    to lots of other guys, then forget about that guy.
 >
 > Hey, that sounds great!
 [...]
 > I like it! I'll update this ticket to reflect the new scheme.

 +1

 > I can imagine arguments against using time.time() instead of an actual
 > counter:
 >
 > * more entropy for a de-anonymizing attacker to correlate
 > * providing a potentially high-resolution timestamp (the current code
 >   uses all significant digits of time.time(), frequently microseconds)
 >   that might reveal time consumed during boot, which might help a timing
 >   attack on e.g. key generation or signature generation.
 > * timequakes causing temporary disbelief of new announcements, requiring
 >   period refresh to make sure the disbelief is eventually overcome
 >   (imagine setting your clock back a day and then rebooting: you need to
 >   have at least one announcement more than one day after reboot to catch
 >   up)

 If you use (time of last restart, # of announcements since restart)
 ordered lexicographically, that would solve the first two problems. It
 wouldn't solve the timequake problem: if you restarted the server at a
 local time earlier than the local time of some previous restart, you
 wouldn't recover until you restarted again.

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