docs/frontends/FTP-and-SFTP.txt: docs/performance.txt, architecture.txt: updates...

diff --git a/docs/architecture.txt b/docs/architecture.txt
index 0451d4e9a0dbe37b75b51ce1ade2d652242b2090..604b5947257d5ee49677355f2c79b4c9198bc5ee 100644 (file)
--- a/docs/architecture.txt
+++ b/docs/architecture.txt
@@ -231,9 +231,12 @@ sense to set servers_of_happiness = N.
 
 When downloading a file, the current version just asks all known servers for
 any shares they might have. Once it has received enough responses that it
-knows where to find the needed k shares, it downloads the shares from those
-servers. (This means that it tends to download shares from the fastest
-servers.)
+knows where to find the needed k shares, it downloads at least the first
+segment from those servers. This means that it tends to download shares from
+the fastest servers. If some servers had more than one share, it will continue
+sending "Do You Have Block" requests to other servers, so that it can download
+subsequent segments from distinct servers (sorted by their DYHB round-trip
+times), if possible.
 
   *future work*
 

diff --git a/docs/performance.txt b/docs/performance.txt
index 45d63cad1622c272ce42630e612435d27c04bcca..83d7a7a73889feadbd02fd3f2b22cc69cbc11ab1 100644 (file)
--- a/docs/performance.txt
+++ b/docs/performance.txt
@@ -40,25 +40,16 @@ notes: Tahoe-LAFS generates a new RSA keypair for each mutable file that
 
 == Downloading B bytes of an A-byte immutable file ==
 
-network: A
+network: B
 memory footprint: 128KiB
 
-notes: When asked to read an arbitrary range of an immutable file,
-       Tahoe-LAFS will download from the beginning of the file up until
-       it has enough of the file to satisfy the requested read.
-       Depending on where in the file the requested range is, this can
-       mean that the entire file is downloaded before the request is
-       satisfied. Tahoe-LAFS will continue to download the rest of the
-       file even after the request is satisfied, so in any case where the
-       file actually has to downloaded from the grid, reading part of an
-       immutable file will result in downloading all of the immutable
-       file. Ticket #798 is a proposal to change this behavior.
-
-       Tahoe-LAFS will cache files that are read in this manner for a
-       short while, so subsequent reads of the same file may be served
-       entirely from cache, depending on what part of the file they need
-       to read, what part of the file was read by previous reads, and
-       how much time has elapsed since the last read.
+notes: When Tahoe-LAFS 1.8.0 or later is asked to read an arbitrary range
+       of an immutable file, only the 128-KiB segments that overlap the
+       requested range will be downloaded.
+
+       (Earlier versions would download from the beginning of the file up
+       until the end of the requested range, and then continue to download
+       the rest of the file even after the request was satisfied.)
 
 == Downloading B bytes of an A-byte mutable file ==