[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