diff --git a/FAQ.md b/FAQ.md index 4a352dc..8279acc 100644 --- a/FAQ.md +++ b/FAQ.md @@ -142,4 +142,13 @@ Please see these mailing list threads: A: Ideally, all clients attempt to open connections to all servers, and all servers attempt to open connections to all clients. So, if the client is not behind NAT, then even if the server is behind NAT. However, this is not currently the case. -**Currently** what it does is that all clients attempt to open connections to all servers, but if there is a connection between two Tahoe-LAFS processes (== Tahoe-LAFS nodes) it can re-use that connection for any client or server in either node. So, when you enable a storage server on the public facing server, that causes the node behind NAT to initiate a TCP connection to the node on the public facing server. Once that connection is established, that enables the node there to *use* the server behind NAT. Related issue: \ No newline at end of file +**Currently** what it does is that all clients attempt to open connections to all servers, but if there is a connection between two Tahoe-LAFS processes (== Tahoe-LAFS nodes) it can re-use that connection for any client or server in either node. So, when you enable a storage server on the public facing server, that causes the node behind NAT to initiate a TCP connection to the node on the public facing server. Once that connection is established, that enables the node there to *use* the server behind NAT. Related issue: + +**Q22: What are literal caps?** + +A: +Literal caps (or LIT caps) are simply the base32 encoding of the file data, and are used for very small files. The threshold is 55 bytes (source: [immutable/upload.py](https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/immutable/upload.py?rev=fd676a5846fce5da#L1410)), which is +the break-even point at which the LIT filecap is the same length as a typical CHK filecap. They are sufficient (you don't even need network access to turn the LIT filecap into the data), and necessary (if you don't know the filecap for my data, you can't figure out the data). See this mailing list thread: +* [Storing a small file leads to a weird read capability](https://tahoe-lafs.org/pipermail/tahoe-dev/2010-April/004235.html) (especially [this message by Brian Warner](https://tahoe-lafs.org/pipermail/tahoe-dev/2010-April/004237.html)) + +Literal caps are supported for immutable files and immutable directories (see [the Capabilities wiki page](https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Capabilities)). Whenever the contents of the file or directory are small enough that it would be more efficient to fit the contents into the cap itself than the store the contents remotely and use the cap to fetch it, then it becomes a literal cap.