[tahoe-dev] switching from introducers to gossip?
Brian
warner at lothar.com
Mon Jul 2 02:45:00 UTC 2012
On 7/1/12 5:56 PM, Tony Arcieri wrote:
> Is there any reason why you can't simply have multiple introducers,
> which may have inconsistent views of the world, but which otherwise
> function identically? Clients can use information gathered from all
> introducers they're connected to in order to make connections to other
> storage nodes. It seems like all that's really missing is a system to
> construct the union of the available storage nodes as enumerated by
> multiple introducers.
That's doable (it's basically what the #68 Google Summer of Code project
produced), and it would be more robust than the current
one-lone-Introducer (and we need the "union of announcements" feature in
any case). But it wouldn't decrease the administrative burden.. in fact
it would be worse than a single introducer.
Imagine a grid that has two Introducers and everybody knows about both
of them (I1 and I2). Now the operator of one (I1) of them announces that
they're going to retire it, so somebody (I3) else volunteers to add a
replacement. We'll start with I1+I2, then have I1+I2+I3, then finish
with I2+I3.
With the #68-GSoC -style "introducer.furls", after the volunteer spins
up I3, everybody in the entire grid has to edit their configs to add
I3's new FURL.
With gossip, the volunteer adds I3 and then they're done. Everyone else
learns about I3 from I1/I2, then remembers I3, and connects to it even
though I1 is gone.
If you generalize this, then all nodes can function as introducers, and
there's no need for dedicated Introducer nodes. As long as at least one
node with a public IP is up at any given time, everybody else can learn
the current state of the world.
cheers,
-Brian
More information about the tahoe-dev
mailing list