From: Brian Warner <warner@allmydata.com>
Date: Fri, 30 May 2008 01:51:11 +0000 (-0700)
Subject: architecture.txt: explain the introducer SPOF and why it really isn't that bad. Close... 
X-Git-Tag: allmydata-tahoe-1.1.0~76
X-Git-Url: https://git.rkrishnan.org/components/index.php?a=commitdiff_plain;h=c83d8b7a6ddf4f8e7f882d71b57376904f935fbc;p=tahoe-lafs%2Ftahoe-lafs.git

architecture.txt: explain the introducer SPOF and why it really isn't that bad. Closes #323.
---

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