[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