mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-10 21:23:58 +01:00
explain a bit about router descriptor purposes
svn:r13154
This commit is contained in:
parent
55e052b0a5
commit
8e601e0ae5
@ -654,8 +654,8 @@ $Id$
|
|||||||
CRLF Descriptor CRLF "." CRLF
|
CRLF Descriptor CRLF "." CRLF
|
||||||
|
|
||||||
This message informs the server about a new descriptor. If Purpose is
|
This message informs the server about a new descriptor. If Purpose is
|
||||||
specified, it must be either "general" or "controller", else we
|
specified, it must be either "general", "controller", or "bridge",
|
||||||
return a 552 error.
|
else we return a 552 error.
|
||||||
|
|
||||||
If Cache is specified, it must be either "no" or "yes", else we
|
If Cache is specified, it must be either "no" or "yes", else we
|
||||||
return a 552 error. If Cache is not specified, Tor will decide for
|
return a 552 error. If Cache is not specified, Tor will decide for
|
||||||
|
@ -182,7 +182,7 @@ of their choices.
|
|||||||
proportional to its advertised bandwidth [the smaller of the 'rate' and
|
proportional to its advertised bandwidth [the smaller of the 'rate' and
|
||||||
'observed' arguments to the "bandwidth" element in its descriptor]. If a
|
'observed' arguments to the "bandwidth" element in its descriptor]. If a
|
||||||
router's advertised bandwidth is greater than MAX_BELIEVABLE_BANDWIDTH
|
router's advertised bandwidth is greater than MAX_BELIEVABLE_BANDWIDTH
|
||||||
(10 MB/s), we clip to that value.
|
(currently 10 MB/s), we clip to that value.
|
||||||
|
|
||||||
For non-exit positions on "fast" circuits, we pick routers as above, but
|
For non-exit positions on "fast" circuits, we pick routers as above, but
|
||||||
we weight the clipped advertised bandwidth of Exit-flagged nodes depending
|
we weight the clipped advertised bandwidth of Exit-flagged nodes depending
|
||||||
@ -351,8 +351,23 @@ of their choices.
|
|||||||
Tor does not add a guard persistently to the list until the first time we
|
Tor does not add a guard persistently to the list until the first time we
|
||||||
have connected to it successfully.
|
have connected to it successfully.
|
||||||
|
|
||||||
|
6. Router descriptor purposes
|
||||||
|
|
||||||
|
There are currently three "purposes" supported for router descriptors:
|
||||||
|
general, controller, and bridge. Most descriptors are of type general
|
||||||
|
-- these are the ones listed in the consensus, and the ones fetched
|
||||||
|
and used in normal cases.
|
||||||
|
|
||||||
|
Controller-purpose descriptors are those delivered by the controller
|
||||||
|
and labelled as such: they will be kept around (and expire like
|
||||||
|
normal descriptors), and they can be used by the controller in its
|
||||||
|
CIRCUITEXTEND commands. Otherwise they are ignored by Tor when it
|
||||||
|
chooses paths.
|
||||||
|
|
||||||
|
Bridge-purpose descriptors are for routers that are used as bridges. See
|
||||||
|
doc/design-paper/blocking.pdf for more design explanation, or proposal
|
||||||
|
125 for specific details. Currently bridge descriptors are used in place
|
||||||
|
of normal entry guards, for Tor clients that have UseBridges enabled.
|
||||||
|
|
||||||
|
|
||||||
X. Old notes
|
X. Old notes
|
||||||
|
Loading…
Reference in New Issue
Block a user