[tahoe-dev] switching from introducers to gossip?

[darrob]

On Sun, Jul 01, 2012 at 07:45:00PM -0700, Brian wrote:
> 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.

We've been using the multi-introducer patch on I2P since Tahoe-LAFS
1.8.3 and it has indeed proven to be more robust.  The single-introducer
grid we started out with simply fell apart when the introducer
disappeared.  It then took a long time before everybody learned the new
introducer's address and adjusted their configurations.  Time and files
were lost.  This hasn't happened again since we've started using the
patched version.

The administrative burden is definitely there.  However, I'd argue
against it being worse.  At least nodes that only know about a subset of
introducers (e.g. only I2 in your example below) are in no rush of
adding the rest (I3) because the grid is still functional.

> 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.

We currently have 6 reliable introducers.  Before we got to that number
we had this exact situation.  Introducers were coming, going and
changing addresses.

We remedied this by writing grid-updates [1].  Using this tool users
have successfully updated their introducer lists many times without
having to think (much) about it.  (Unfortunately a restart is required
for Tahoe to pick up on new introducers in the list).

Obviously you're looking for a much more elegant and automatic solution
than some 3rd party utility, but I thought it's worth mentioning our
experiences with the existing system anyway.  It's not all that bad.

> 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.

This sounds perfect.  I wonder if this system is susceptible to
introducer spam attacks of some sort, though.  I image those would be an
annoyance at best.

[1]: https://tahoe-lafs.org/pipermail/tahoe-dev/2012-June/007505.html

darrob