[tahoe-lafs-trac-stream] [tahoe-lafs] #1767: update Announcement "timestamp": sequence number?

[tahoe-lafs]

#1767: update Announcement "timestamp": sequence number?
-------------------------+-------------------------------------------------
     Reporter:  warner   |      Owner:  warner
         Type:           |     Status:  assigned
  enhancement            |  Milestone:  1.10.0
     Priority:  major    |    Version:  1.9.1
    Component:  code-    |   Keywords:  forward-compatibility introduction
  network                |  time blocker
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by warner):

 Hm. If we increment the counter with each announcement, we could still get
 into the same trap:

 * announce (0,storage,X)
 * announce (1,grid-control,Y)
 * rewind to a backup
 * restart
 * announce (0,storage,Z) [ignored by others: seqnum not newer]
 * announce (1,grid-control,Y) [ignored by others]
 * hear back the earlier (1,grid-control,Y)
 * looks just like our recent announcement, so don't provoke a retransmit

 Also I think we'd need to store (at least in RAM) a separate counter for
 each service, so we could recognize when announcements are newer than
 anything we've ever created. Ideally we want the very first message from
 our previous life to trigger re-encodings of everything we might publish.

 I'm +1 on one-counter-per-node. I think I'm +1 on using the same counter
 value for all announcements (i.e. every time we update any service, we
 increment the counter, write it to disk, then publish a full set of
 announcements for all services, all using the same counter value). Then if
 we hear back any announcement with a higher counter value, or an equal
 counter but different contents, we trigger new announcements with the next
 higher counter. I *think* that will let any single message-from-the-future
 trigger an update, and will also correctly ignore echoes of any current
 message. I'm also +1 on adding a nonce to each announcement (created when
 we encode the message, stored in RAM only, not persistent), so we can
 distinguish messages from two different reboots that happen to otherwise
 contain the same contents.

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