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 _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE