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 <FILENAME>.tar.gz</pre> |
|
1117 |
- or |
|
1118 |
- <pre>tar xJf <FILENAME>.tar.xz</pre> |
|
1116 |
+ <pre>tar xzf <FILENAME>.tar.gz</pre> or <pre>tar xJf <FILENAME>.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 |