[tahoe-dev] Dual Introducer Scenario 1

[Zooko O'Whielacronx]

Hi Faruq! Thanks for getting started on this. I'm in Kraków right
now—I just gave a talk on Tahoe-LAFS to an appreciative audience of
hackers at CONfidence 2010.

I'm probably too sleepy to understand this right now, but I thought I
would just write this note before going to sleep and probably I can
look at it more clearly tomorrow.

On Wed, May 26, 2010 at 2:43 PM, M O Faruque Sarker
<writefaruq at gmail.com> wrote:
>
> I've drawn a simple scenario of dual introducers. Attached figure
> should be self-explanatory.

I like the idea of starting with the case of just two introducers. I
hadn't thought of that before. Is that your plan?

> Do you recommend me to append it with ticket #68 or create a new page for it ?

Please append it to ticket #68 at least for now.

> This simple scenario/use-case shows what might happen if nodes
> Client1,2, 3 are configured to talk to two introducers: X and Y. If Y
> goes down and in that down period one example new node (client4) joins
> it is obvious that all other nodes will know about newly joining node
> through X.
>
> But what will happen if X goes down and Y becomes up again and client4
> also goes down ? Without the existence of Y it is seen that nodes will
> contain outdated information as seen in Snapshot B. However, Snapshot
> C shows that disappearance of client4 can be updated to Client1,2, 3
> by Y.
>
> Please make your comments/suggestions on this scenario or anything else.

Yep, I'm too tired to understand the scenario. :-)

But I can say that there is a design decision in the Tahoe-LAFS
introducer scheme which is not typical so it is easy for people to
misunderstand it—introducers don't have the ability to *un*-introduce
nodes from one another. There is no message than an introducer can
send to a client to inform it that a server is gone.

Instead the client has to discover that the server is gone when it
tries to use it and can't (for example it attempts to open a TCP
connection and fails).

This is consistent with the "Principle of Least Authority"—introducers
need to have the ability to introduce nodes to one another. They do
not *need* to have the ability to un-introduce nodes from one another,
so therefore we deny them this ability.

You can think of this as separating introduction, or "discovery"—a
previously unknown server has been created, the clients need to learn
about it—from "presence"—a server that you already know has just gone
down, or has just come up, and you might like for someone to tell you
about that, but the introducer (in the current version) will not tell
you that.

So currently discovery is implemented by asynchronous notification—as
soon as the introducer learns about a new server then it informs the
clients, but presence is implemented by polling with backoff—clients
will keep a TCP connection open to each server, and if that connection
fails then the client will retry to open it at a slower and slower
rate. If I recall correctly the rate of retry stops slowing when it
reaches one retry per hour.

Now there might be some performance problems or other problems with
this design. I would be interested in your investigation into that.
But you should appreciate from the beginning that we like the fact
that limiting the introducer's job to just introduction/discovery
limits the amount of damage that the introducer can do (and also makes
the introducer implementation nice and simple).

Regards,

Zooko