mirrors/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2025-02-24 06:48:05 +01:00
Code Issues Projects Releases Wiki Activity

We put bw info directory into the consensus, also versions are already there and protocol versions are not currently required

Browse source 
svn:r16423
This commit is contained in:
Peter Palfrader 2008-08-05 16:29:20 +00:00
parent bd1c8f526e
commit 59439c9d5b
1 changed files with 19 additions and 27 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

46
doc/spec/proposals/141-jit-sd-downloads.txt
View file

@ -119,28 +119,19 @@ Status: Draft
to the "r", "s", and "v" lines that already exist. This line to the "r", "s", and "v" lines that already exist. This line
will convey weight information to clients. will convey weight information to clients.
"w Exit=41 Guard=94 Middle=543 ..." "w Bandwidth=193671"
It starts with the letter w and then contains any number of Key=Value The bandwidth number is the lesser of observed bandwidth and bandwidth
pairs. Values will be non-negative integers. Clients will pick rate limit from the server descriptor that the "r" line referenced by
routers with a propability proportional to the number for the intended digest (1st and 3rd field of the bandwidth line in the descriptor).
purpose.
Clients MUST accept sums of all weights for a given purpose over all The bandwidth item is added as another item in the router tuple
routers in a consensus up to UINT64_max. described in dir-spec section 3.4:
| * Two router entries are "the same" if they have the same
[XXX how do we arrive at a consensus weight? | <descriptor digest, published time, nickname, IP, ports> tuple.
option a) Perhaps the vote could contain the node's bandwidth, and | We choose the tuple for a given router as whichever tuple appears
this could be used to calculate the weights? It's | for that router in the most votes. We break ties in favor of
necessary that the consensus remain a deterministic | the more recently published.
function of the votes.
option b) Every voter assigns weights for each of the purposes
(Exit, Guard, ..) so that their total sum is some constant
X. When building a consensus we take the median for each
purpose for each router.
Option a has the disadvantage that if we want to tweak the weighting
we have to make a new consensus-method]
3.2 Fetching descriptors on demand 3.2 Fetching descriptors on demand
@ -198,14 +189,15 @@ Status: Draft
3.3 Protocol versions 3.3 Protocol versions
[XXX: find out where we need "opt protocols Link 1 2 Circuit 1" Server descriptors contain optional information of supported
information described in 2.3 above. If we need it, it might have link-level and circuit-level protocols in the form of
to go into the consensus document.] "opt protocols Link 1 2 Circuit 1". These are not currently needed
and will probably eventually move into the "v" (version) line in
the consensus. This proposal does not deal with them.
[XXX: Similarly find out where we need the version number of a Similarly a server descriptor contains the version number of
remote tor server. This information is in the consensus, but a Tor node. This information is already present in the consensus
maybe we use it in some place where having it signed by the and is thus available to all clients immediately.
server in question is really important?]
3.4 Exit selection 3.4 Exit selection