From darrob@i2pmail.org Fri Jul 6 02:36:36 2018 From: darrob To: cypherpunks-legacy@lists.cpunks.org Subject: Re: [tahoe-dev] switching from introducers to gossip? Date: Fri, 06 Jul 2018 02:36:36 +0000 Message-ID: <172289101885.3849117.4678545880667286404.generated@mail.pglaf.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5168719560477878281==" --===============5168719560477878281== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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(a)tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl leitl 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 --===============5168719560477878281==--