From c83d8b7a6ddf4f8e7f882d71b57376904f935fbc Mon Sep 17 00:00:00 2001 From: Brian Warner Date: Thu, 29 May 2008 18:51:11 -0700 Subject: [PATCH] architecture.txt: explain the introducer SPOF and why it really isn't that bad. Closes #323. --- docs/architecture.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/docs/architecture.txt b/docs/architecture.txt index dac1e212..5da4e250 100644 --- a/docs/architecture.txt +++ b/docs/architecture.txt @@ -51,6 +51,18 @@ connections to, but they cannot open connections to other nodes behind NAT boxes. Therefore, the more nodes behind NAT boxes, the less the topology resembles the intended fully-connected topology. +The introducer in nominally a single point of failure, in that clients who +never see the introducer will be unable to connect to any storage servers. +But once a client has been introduced to everybody, they do not need the +introducer again until they are restarted. The danger of a SPOF is further +reduced in other ways. First, the introducer is defined by a hostname and a +private key, which are easy to move to a new host in case the original one +suffers an unrecoverable hardware problem. Second, even if the private key is +lost, clients can be reconfigured with a new introducer.furl that points to a +new one. Finally, we have plans to decentralize introduction, allowing any +node to tell a new client about all the others. With decentralized +"gossip-based" introduction, simply knowing how to contact any one node will +be enough to contact all of them. FILE ENCODING -- 2.45.2