[tahoe-lafs-trac-stream] [tahoe-lafs] #1765: gossip-introducer should forget about old nodes somehow

tahoe-lafs trac at tahoe-lafs.org
Thu Jun 14 22:49:21 UTC 2012


#1765: gossip-introducer should forget about old nodes somehow
--------------------------------+--------------------
     Reporter:  warner          |      Owner:  warner
         Type:  enhancement     |     Status:  new
     Priority:  normal          |  Milestone:  soon
    Component:  code-nodeadmin  |    Version:  1.9.1
   Resolution:                  |   Keywords:
Launchpad Bug:                  |
--------------------------------+--------------------

Comment (by warner):

 Replying to [comment:5 zooko]:
 >
 > Hrm. This idea of gossip conflicts with my idea that each server
 > should attempt to connect to all clients -- and only to clients
 > -- and that each client should attempt to connect to all servers
 > -- and only to servers (#344, #1086).

 > It would also interact somewhat poorly with #444

 Hm. We could set it up so that grid-control announcements flow
 along all sorts of connections (instead of having nodes subscribe
 to a specific "grid-control" servicename). Then servers would learn
 about other servers even though they don't connect to each other,
 and new clients could learn about all servers from any one server.
 That might make it hard to prune uninteresting/bogus data, though
 (i.e. throw out records for things you don't care about, and rely
 on that mechanism to keep the overall dataset smaller).

 Remember that "learning about node X" doesn't mean "connecting to
 node X". The Announcements are just data, they can be transported
 by anything (including some designated node that just gathers and
 serves up the current announcement list on demand). No long-term
 connections necessary.

 > Could we finish the rest of the #466 new-introduction-protocol
 > and related accounting infrastructure while leaving the current
 > centralized introducer (or the #68 multiple introducers) alone?

 Yeah, sure, that's the plan. I'm just anticipating the future.

 > In fact, why do we need to switch from introducers to gossip at
 > all?

 Well, I think it'd be more robust, and would make grid setup
 easier. If we can embed a default relay (hosted on tahoe-lafs.org
 somewhere), then joining an existing grid could be as easy as:

 * install tahoe
 * run "tahoe [create+run+accept] INVITECODE"

 And that gets you all of the following:

 * your new nodes learns all the servers it needs, no large
   introducer.furl to manage
 * learnine about new servers that are added in the future
 * acquiring storage rights on those servers (traceable to you and
   to the person who invited you, which I think is Ostrom-ideal)
 * granting storage rights on your server to others

 and nobody else ever had to set up an Introducer either.

 I'm not in favor of multiple-introducers (specifically the
 {{{introducer.furls}}} GSoC design) because I think introducers are
 a nuisance to set up, FURLs are a nuisance to transfer, and
 multiple introducers would still be
 multiple-points-of-centralization (instead of being properly
 '''decentralized''' like the title of #68 suggests).
 Multiple-introducers are an easier short-term target, but we've
 done without them for years now, so I'd rather push forwards on a
 better solution than add complication and maintenance burden for a
 partial solution.

 > I think this discussion needs to move to the mailing list...

 Yeah, good idea. I'll try to write up more about the
 gossip/invitation scheme tonight.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1765#comment:8>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage


More information about the tahoe-lafs-trac-stream mailing list