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

tahoe-lafs trac at tahoe-lafs.org
Thu Mar 7 16:34:25 UTC 2013


#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 davidsarah):

 Brian wrote:
 > It might be easier if we only had one counter for the whole node,
 instead of separate counters for each service-name. Then receipt of *any*
 message with a higher counter would trigger the updates. (when gossip-
 introduction happens, all nodes will subscribe to "grid-control", so we
 don't need to require specific loopback rules). My concern is that we
 might announce (counter=0, service-name=storage, data=X) and (counter=0,
 service-name=grid-control, data=Y), then have a quake, then some small
 thing changes about the storage server but not about grid-control. When
 the node comes back, it will announce (counter=0, storage, data=Z) but
 still (counter=0, grid-control, data=Y).

 Ah, for "one-counter-per-node", I was thinking that the counter would be
 incremented whenever we encode a service announcement. So we would
 announce (counter=0, service-name=storage, data=X) then (counter=1,
 service-name=grid-control, data=Y), and the above situation couldn't
 occur.

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


More information about the tahoe-lafs-trac-stream mailing list