Added two new FAQ entries.
Matt Pagan

Matt Pagan commited on 2014-01-31 00:54:26
Zeige 1 geänderte Dateien mit 59 Einfügungen und 10 Löschungen.

... ...
@@ -1113,11 +1113,9 @@ better vendor.
1113 1113
     Tar is a common archive utility for Unix and Linux systems. If your
1114 1114
     system has a mouse, you can usually open them by double clicking. 
1115 1115
     Otherwise open a command prompt and execute 
1116
-    <pre>tar xzf &lt;FILENAME&gt;.tar.gz</pre>
1117
-    or
1118
-    <pre>tar xJf &lt;FILENAME&gt;.tar.xz</pre>
1116
+    <pre>tar xzf &lt;FILENAME&gt;.tar.gz</pre> or <pre>tar xJf &lt;FILENAME&gt;.tar.xz</pre>
1119 1117
     <p>
1120
-    as documented in tar's man page. 
1118
+    as documented on tar's man page. 
1121 1119
     </p>
1122 1120
 
1123 1121
     <hr>
... ...
@@ -2678,6 +2676,57 @@ too.
2678 2676
     200 KB: this way your relay will always be useful for at least half of 
2679 2677
     each day. 
2680 2678
     </p>
2679
+
2680
+    <hr>
2681
+
2682
+    <a id="RelayWritesMoreThanItReads"></a>
2683
+    <h3>< class="anchor" href="#RelayWritesMoreThanItReads">Why does my relay 
2684
+    write more bytes onto the network than it reads?</h3>
2685
+
2686
+    <p>You're right, for the most part a byte into your Tor relay means a 
2687
+    byte out, and vice versa. But there are a few exceptions:</p>
2688
+
2689
+    <p>If you open your DirPort, then Tor clients will ask you for a copy of 
2690
+    the directory. The request they make (an HTTP GET) is quite small, and the 
2691
+    response is sometimes quite large. This probably accounts for most of the 
2692
+    difference between your "write" byte count and your "read" byte count.</p>
2693
+
2694
+    <p>Another minor exception shows up when you operate as an exit node, and 
2695
+    you read a few bytes from an exit connection (for example, an instant 
2696
+    messaging or ssh connection) and wrap it up into an entire 512 byte cell 
2697
+    for transport through the Tor network.</p>
2698
+
2699
+    <hr>
2700
+
2701
+    <a id="Hibernation"></a>
2702
+    <h3><a class="anchor" href="#Hibernation">Why can I not browse anymore 
2703
+    after limiting bandwidth on my Tor relay?</a>
2704
+
2705
+    <p>The parameters assigned in the <a 
2706
+    href="#LimitTotalBandwidth">AccountingMax</a> and <a 
2707
+    href="#BandwidthShaping">BandwidthRate</a> apply to both client and 
2708
+    relay functions of the Tor process. Thus you may find that you are unable 
2709
+    to browse as soon as your Tor goes into hibernation, signaled by this 
2710
+    entry in the log:</p>
2711
+
2712
+    <pre>Bandwidth soft limit reached; commencing hibernation. No new 
2713
+    connections will be accepted</pre>
2714
+
2715
+    <p>The solution is to run two Tor processes - one relay and one client, 
2716
+    each with its own config. One way to do this (if you are starting from a 
2717
+    working relay setup) is as follows:</p>
2718
+
2719
+    <ul>
2720
+        <li>In the relay Tor torrc file, simply set the SocksPort to 0.</li>
2721
+        <li>Create a new client torrc file from the torrc.sample and ensure 
2722
+        it uses a different log file from the relay. One naming convention 
2723
+        may be torrc.client and torrc.relay.</li>
2724
+        <li>Modify the Tor client and relay startup scripts to include 
2725
+        '-f /path/to/correct/torrc'.</li>
2726
+        <li>In Linux/BSD/OSX, changing the startup scripts to Tor.client 
2727
+        and Tor.relay may make separation of configs easier.</li>
2728
+    </ul>
2729
+
2681 2730
     <hr>
2682 2731
 
2683 2732
     <a id="ExitPolicies"></a>
... ...
@@ -4506,12 +4555,12 @@ could possibly see.
4506 4555
     reliability of streams. The main approach we have now is to specify 
4507 4556
     that streams using certain application ports prefer circuits to be 
4508 4557
     made up of stable nodes. These ports are specified in the "LongLivedPorts" 
4509
-    <a href="#torrc">torrc</a> option, and they default to
4510
-    <pre>21,22,706,1863,5050,5190,5222,5223,6667,6697,8300</pre>. The 
4511
-    definition of "stable" is an open research question, since we can only 
4512
-    guess future stability based on past performance. Right now we judge 
4513
-    that a node is stable if it advertises that it has been up for more 
4514
-    than a day. Down the road we plan to refine this so it takes into 
4558
+    <a href="#torrc">torrc</a> option, and they default to</p>
4559
+    <pre>21,22,706,1863,5050,5190,5222,5223,6667,6697,8300</pre>
4560
+    <p>The definition of "stable" is an open research question, since we 
4561
+    can only guess future stability based on past performance. Right now 
4562
+    we judge that a node is stable if it advertises that it has been up 
4563
+    for more than a day. Down the road we plan to refine this so it takes into 
4515 4564
     account the average stability of the other nodes in the Tor network.</p>
4516 4565
 
4517 4566
     <hr>
4518 4567