- tor-commits - lists.torproject.org

[tordnsel/master] date the 0.1.0 release.
by andrew＠torproject.org 28 Jun '11

28 Jun '11

commit 8839661e15fb14cecf2e7e064ad742743bc6d3e9 Author: Andrew Lewman <andrew(a)torproject.org> Date: Tue Jun 28 09:49:51 2011 -0400 date the 0.1.0 release. --- ChangeLog | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index b26fee7..54df4d8 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,4 +1,4 @@ -0.1.0 - 201?-??-?? +0.1.0 - 2011-06-28 o Deployment: - Add support for logging messages to stdout, stderr, syslog, or to a file. Syslog logging should be useful for running in a chroot.

1 0

[tordnsel/master] change timeouts from 48 to 24 hours so exit relays aren't listed for 2
by andrew＠torproject.org 28 Jun '11

28 Jun '11

commit 203590063b3877c73e876a94aa93c847976d2116 Author: Andrew Lewman <andrew(a)torproject.org> Date: Sat Jun 18 23:09:15 2011 -0400 change timeouts from 48 to 24 hours so exit relays aren't listed for 2 days beyond their disappearing from consensus. --- src/TorDNSEL/NetworkState/Internals.hs | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/TorDNSEL/NetworkState/Internals.hs b/src/TorDNSEL/NetworkState/Internals.hs index 484537e..933b7eb 100644 --- a/src/TorDNSEL/NetworkState/Internals.hs +++ b/src/TorDNSEL/NetworkState/Internals.hs @@ -668,8 +668,8 @@ expireOldInfo now s = s { nsAddrs = addrs'', nsRouters = routers'' } deleteExitAddresses rid test addrs = foldl' (\as addr -> deleteAddress addr rid as) addrs (M.keys $ tstAddresses test) - maxRouterAge = 48 * 60 * 60 - maxExitTestAge = 48 * 60 * 60 + maxRouterAge = 24 * 60 * 60 + maxExitTestAge = 24 * 60 * 60 -- | Add a new router associated with an address to the address map. insertAddress :: HostAddress -> RouterID -> Map HostAddress (Set RouterID)

1 0

[tordnsel/master] update the Changelog to reflect the max router age.
by andrew＠torproject.org 28 Jun '11

28 Jun '11

commit 8d2c12619dcf6014a68a7f55a849e415ec864480 Author: Andrew Lewman <andrew(a)torproject.org> Date: Sun Jun 19 22:05:16 2011 -0400 update the Changelog to reflect the max router age. --- ChangeLog | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index f09c3fa..b26fee7 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,4 +1,4 @@ -0.1.0 - 2008-0?-?? +0.1.0 - 201?-??-?? o Deployment: - Add support for logging messages to stdout, stderr, syslog, or to a file. Syslog logging should be useful for running in a chroot. @@ -58,6 +58,9 @@ earlier attempted test. - Regenerate the exit-addresses store every time a new network status consensus is received instead of every 15 minutes. + - Reduce the maximum relay age from 48 hours to 24 hours. This should + cut down the length of time a relay is listed in the exitlist after + it has been disabled or changed to a non-exit relay. o Controller: - Close controller connections cleanly with the QUIT command.

1 0

[tordnsel/master] add tordnsel init script.
by andrew＠torproject.org 28 Jun '11

28 Jun '11

commit cb19f6a87f1b238703fafcf2397d59edf504ebb5 Author: Andrew Lewman <andrew(a)torproject.org> Date: Wed Jun 22 21:28:34 2011 -0400 add tordnsel init script. --- config/tordnsel-init.d-script.sample | 169 ++++++++++++++++++++++++++++++++++ 1 files changed, 169 insertions(+), 0 deletions(-) diff --git a/config/tordnsel-init.d-script.sample b/config/tordnsel-init.d-script.sample new file mode 100755 index 0000000..f7a7fd2 --- /dev/null +++ b/config/tordnsel-init.d-script.sample @@ -0,0 +1,169 @@ +#! /bin/sh +### BEGIN INIT INFO +# Provides: TorDNSEL +# Required-Start: $local_fs $remote_fs $syslog $network $time +# Required-Stop: $local_fs $remote_fs $syslog $network $time +# Default-Start: 2 3 4 5 +# Default-Stop: 0 1 6 +# Short-Description: Starts the TorDNSEL daemon process +# Description: Starts TorDNSEL, a name server that provides a +# DNSBL-style interface for detecting connections +# exiting the Tor network. +# +### END INIT INFO + +# Author: Jacob Appelbaum <jacob(a)appelbaum.net> +# Author: tup <tup.tuple(a)googlemail.com> +# +# Please remove the "Author" lines above and replace them +# with your own name if you copy and modify this script. + +# Do NOT "set -e" + +# PATH should only include /usr/* if it runs after the mountnfs.sh script +PATH=/sbin:/usr/sbin:/bin:/usr/bin +DESC="TorDNSEL daemon" +NAME=tordnsel +DAEMON=/usr/local/bin/$NAME +PIDFILE=/var/run/$NAME.pid +SCRIPTNAME=/etc/init.d/$NAME +CONFIGFILE="/etc/tordnsel.conf" +RUNTIMEDIR="/var/run/tordnsel" +USER=tordnsel +ARGS="-f $CONFIGFILE " + +# Exit if the package is not installed +[ -x "$DAEMON" ] || exit 0 + +# Read configuration variable file if it is present +[ -r /etc/default/$NAME ] && . /etc/default/$NAME + +# +# Function that starts the daemon/service +# +do_start() +{ + # Return + # 0 if daemon has been started + # 1 if daemon was already running + # 2 if daemon could not be started + start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \ + || return 1 + start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- $ARGS \ + || return 2 + # Add code here, if necessary, that waits for the process to be ready + # to handle requests from services started subsequently which depend + # on this one. As a last resort, sleep for some time. +} + +# +# Function that stops the daemon/service +# +do_stop() +{ + # Return + # 0 if daemon has been stopped + # 1 if daemon was already stopped + # 2 if daemon could not be stopped + # other if a failure occurred + start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME + RETVAL="$?" + [ "$RETVAL" = 2 ] && return 2 + # Wait for children to finish too if this is a daemon that forks + # and if the daemon is only ever run from this initscript. + # If the above conditions are not satisfied then add some other code + # that waits for the process to drop all resources that could be + # needed by services started subsequently. A last resort is to + # sleep for some time. + start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON + [ "$?" = 2 ] && return 2 + # Many daemons don't delete their pidfiles when they exit. + rm -f $PIDFILE + return "$RETVAL" +} + +case "$1" in + start) + echo "Starting $DESC: $NAME..." + + if ! su -s /bin/sh -c "$DAEMON --verify-config $ARGS" $USER 2> /dev/null; then + echo "ABORTED: TorDNSEL configuration invalid:" >&2 + su -s /bin/sh -c "$DAEMON --verify-config $ARGS" $USER + exit 1 + fi + + do_start + case "$?" in + 0|1) echo "done." ;; + 2) + echo "FAILED." + exit 1 + ;; + esac + ;; + stop) + echo -n "Stopping $DESC: " + do_stop + case "$?" in + 0|1) echo "$NAME." ;; + 2) + echo "FAILED." + exit 1 + ;; + esac + ;; + reload|force-reload) + echo -n "Reloading $DESC configuration: " + + if ! su -s /bin/sh -c "$DAEMON --verify-config $ARGS" $USER 2> /dev/null; then + echo "ABORTED: TorDNSEL configuration invalid:" >&2 + su -s /bin/sh -c "$DAEMON --verify-config $ARGS" $USER + exit 1 + fi + + # Don't send the process a SIGHUP because it won't be able to read its own + # config file when it's chrooted. Instead, use the --reconfigure option to + # dump the contents of the config file to a Unix domain socket on which it's + # listening for this purpose. + ERRMSG=`su -s /bin/sh -c "$DAEMON --reconfigure $RUNTIMEDIR < $CONFIGFILE" $USER 2>&1` + case "$?" in + 0) echo "$NAME." ;; + *) + echo "FAILED." + echo "$ERRMSG" >&2 + exit 1 + ;; + esac + ;; + restart) + if ! su -s /bin/sh -c "$DAEMON --verify-config $ARGS" $USER 2> /dev/null; then + echo "Restarting TorDNSEL ABORTED: TorDNSEL configuration invalid:" >&2 + su -s /bin/sh -c "$DAEMON --verify-config $ARGS" $USER + exit 1 + fi + + echo "Restarting $DESC: $NAME..." + do_stop + case "$?" in + 0|1) + do_start + case "$?" in + 0) echo "done." ;; + 1) echo "FAILED ($DAEMON is still running)." ;; + *) echo "FAILED." ;; # Failed to start + esac + ;; + *) + # Failed to stop + echo "FAILED ($DAEMON won't die)." + exit 1 + ;; + esac + ;; + *) + echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2 + exit 3 + ;; +esac + +:

1 0

[torspec/master] Add proposal 182 ("Credit Bucket") by Tschorsch and Scheuermann
by nickm＠torproject.org 27 Jun '11

27 Jun '11

commit 1413093be9d575a4b0805e0328e2867319a543ae Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Jun 27 15:58:45 2011 -0400 Add proposal 182 ("Credit Bucket") by Tschorsch and Scheuermann --- proposals/000-index.txt | 2 + proposals/182-creditbucket.txt | 181 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 183 insertions(+), 0 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 06e97b5..43502ec 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -102,6 +102,7 @@ Proposals by number: 179 TLS certificate and parameter normalization [DRAFT] 180 Pluggable transports for circumvention [OPEN] 181 Optimistic Data for Tor: Client Side [OPEN] +182 Credit Bucket [DRAFT] Proposals by status: @@ -114,6 +115,7 @@ Proposals by status: 144 Increase the diversity of circuits by detecting nodes belonging the same provider 175 Automatically promoting Tor clients to nodes 179 TLS certificate and parameter normalization [for 0.2.3.x] + 182 Credit Bucket NEEDS-REVISION: 118 Advertising multiple ORPorts at once 131 Help users to verify they are using Tor diff --git a/proposals/182-creditbucket.txt b/proposals/182-creditbucket.txt new file mode 100644 index 0000000..8796bd1 --- /dev/null +++ b/proposals/182-creditbucket.txt @@ -0,0 +1,181 @@ +Filename: 182-creditbucket.txt +Title: Credit Bucket +Author: Florian Tschorsch and Björn Scheuermann +Created: 22 Jun 2011 +Status: Draft + +Overview: + + The following proposal targets the reduction of queuing times in onion + routers. In particular, we focus on the token bucket algorithm in Tor and + point out that current usage unnecessarily locks cells for long time spans. + We propose a non-intrusive change in Tor's design which overcomes the + deficiencies. + +Motivation and Background: + + Cell statistics from the Tor network [1] reveal that cells reside in + individual onion routers' cell queues for up to several seconds. These + queuing times increase the end-to-end delay very significantly and are + apparently the largest contributor to overall cell latency in Tor. + + In Tor there exist multiple token buckets on different logical levels. They + all work independently. They are used to limit the up- and downstream of an + onion router. All token buckets are refilled every second with a constant + amount of tokens that depends on the configured bandwidth limits. For + example, the so-called RelayedTokenBucket limits relay traffic only. All + read data of incoming connections are bound to a dedicated read token + bucket. An analogous mechanism exists for written data leaving the onion + router. We were able to identify the specific usage and implementation of + the token bucket algorithm as one cause for very high (and unnecessary) + queuing times in an onion router. + + We observe that the token buckets in Tor are (surprisingly at a first + glance) allowed to take on negative fill levels. This is justified by the + TLS connections between onion routers where whole TLS records need to be + processed. The token bucket on the incoming side (i.e., the one which + determines at which rate it is allowed to read from incoming TCP + connections) in particular often runs into non-negligible negative fill + levels. As a consequence of this behavior, sometimes slightly more data is + read than it would be admissible upon strict interpretation of the token + bucket concept. + + However, the token bucket for limiting the outgoing rate does not take on + negative fill levels equally often. Consequently, it regularly happens + that somewhat more data are read on the incoming side than the outgoing + token bucket allows to be written during the same cycle, even if their + configured data rates are the same. The respective cells will thus not be + allowed to leave the onion router immediately. They will thus necessarily + be queued for at least as long as it takes until the token bucket on the + outgoing side is refilled again. The refill interval currently is, as + mentioned before, one second -- so, these cells are delayed for a very + substantial time. In summary, one could say that the two buckets, on the + incoming and outgoing side, work like a double door system and frequently + lock cells for a full token bucket refill interval length. + +General Design: + + In order to overcome the described problem, we propose the following + changes related to the token bucket algorithm. + + We observe that the token bucket on the outgoing connections with its + current design is contra productive in the sense of queuing times. We + therefore propose modifications to the token bucket algorithm that will + eliminate the "double door effect" discussed above. + + Let us start from Tor's current approach: Thus, we have a regular token + bucket on the reading side with a certain rate and a certain burst size. + Let x denote the current amount of tokens in the bucket. On the outgoing + side we need something appropriate that monitors and constrains the + outgoing rate, but at the same time avoids holding back cells (cf. double + door effects) whenever possible. + + Here we propose something that adopts the role of a token bucket, but + realizes this functionality in a slightly different way. We call it a + "credit bucket". Like a token bucket, the credit bucket also has a current + fill level, denoted by y. However, the credit bucket is refilled in a + different way. + + To understand how it works, let us look at the possible operations: + + As said, x is the fill level of a regular token bucket on the incoming + side and thus gets incremented periodically according to the configured + rate. No changes here. + + If x<=0, we are obviously not allowed to read. If x>0, we are allowed to + read up to x bytes of incoming data. If k bytes are read (k<=x), then we + update x and y as follows: + + x = x - k (1) + y = y + k (2) + + (1) is the standard token bucket operation on the incoming side. Whenever + data is admitted in, though, an additional operation is performed: (2) + allocates the same number of bytes on the outgoing side, which will later + on allow the same number of bytes to leave the onion router without any + delays. + + If y + x > -M, we are allowed to write up to y + x + M bytes on the + outgoing side, where M is a positive constant. M specifies a burst size for + the outgoing side. M should be higher than the number of tokens that get + refilled during a refill interval, we would suggest to have M in the order + of a few seconds "worth" of data. Now if k bytes are written on the + outgoing side, we proceed as follows: + + If k <= y then y = y - k + + In this case we use "saved" credits, previously allocated on the incoming + side when incoming data has been processed. + + If k > y then y = 0 and x = x - (k-y) + + We generated additional traffic in the onion router, so that more data is + to be sent than has been read (the credit is not sufficient). We therefore + "steal" tokens from the token buffer on the incoming side to compensate for + the additionally generated data. This will result in correspondingly less + data being read on the incoming side subsequently. As a result of such an + operation, the token bucket fill level x on the incoming side may become + negative (but it can never fall below -M). + + If y + x <= -M then outgoing data will be held back. This may lead to + double-door effects, but only in extreme cases where the outgoing traffic + largely exceeds the incoming traffic, so that the outgoing bursts size M is + exceeded. + + Aside from short-term bursts of configurable size (as with every token + bucket), this procedure guarantees that the configured rate may never be + exceeded (on the application layer, that is; as with the current + implementation, an attacker may easily cause the onion router to + arbitrarily exceed the limits on the lower layers). Over time, we never + send more data than the configured rate: every sent byte needs a + corresponding token on the incoming side; this token must either have been + consumed by an incoming byte before (it then became a "credit"), or it is + "stolen" from the incoming bucket to compensate for data generated within + the onion router. + +Specific Design Changes: + + In the following we briefly point out the specific changes that need to be + done in Tor's source code. By doing so one can see how non intrusive our + modifications are. + + First we need to address the bucket increment and decrement operations. + According to the described logic above, this should be done in the methods + connection_bucket_refill and connection_buckets_decrement respectively. In + particular allocating, saving and "stealing" of tokens need to be + considered here. + + Second the rate limiting, i.e. the amount we are allowed to write + (connection_bucket_write_limit) needs to be adapted in lines of the credit + bucket logic. Meaning in order to avoid the here identified unnecessary + queuing of cells, we need to consider the new burst parameter M. Here we + also need to take non rate limited connections such as from the localhost + into account. The rate limiting on the reading side remains the same. + + At last we need to find good values/ ratios for the parameter M such that + the trade off between avoiding "double door effects" and maintaining + strict rate limits work as expected. As future work and after insights + about the performance gain of the here described proposal we need to find a + way to implement this both using bufferevent rate limiting with libevent + 2.3.x and Tor's rate limiting code. + +Conclusion: + + This proposal can be implemented with moderate effort and requires changes + only at the points where currently the token bucket operations are + performed. + + We feel that this is not the be-all and end-all solution, because it again + introduces a feedback loop between the incoming and the outgoing side. We + therefore still hope that we will be able to come to a both simpler and + more effective design in the future. However, we believe that what we + proposed here is a good compromise between avoiding double-door effects to + the furthest possible extent, strictly enforcing an application-layer data + rate, and keeping the extent of changes to the code small. + + Feedback is highly appreciated. + +References: + + [1] Karsten Loesing. Analysis of Circuit Queues in Tor. August 25, 2009. + [2] https://trac.torproject.org/projects/tor/wiki/sponsors/SponsorD/June2011

1 0

[torflow/master] Merge branch 'ratio-restrictions'
by mikeperry＠torproject.org 27 Jun '11

27 Jun '11

commit 039d5300c6d1bb9adfa7a21af0560620d620978f Merge: 07cbb7c a3fdd01 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Mon Jun 27 11:22:47 2011 -0700 Merge branch 'ratio-restrictions' NetworkScanners/BwAuthority/bwauthority_child.py | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)

1 0

[torflow/master] Update bwauth child to use new ratio slicing.
by mikeperry＠torproject.org 27 Jun '11

27 Jun '11

commit a3fdd013eedb3c8beb6bfb4dbffc09b80fb68c43 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Fri Jun 24 13:30:44 2011 -0700 Update bwauth child to use new ratio slicing. --- NetworkScanners/BwAuthority/bwauthority_child.py | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/NetworkScanners/BwAuthority/bwauthority_child.py b/NetworkScanners/BwAuthority/bwauthority_child.py index c342f2e..f842843 100755 --- a/NetworkScanners/BwAuthority/bwauthority_child.py +++ b/NetworkScanners/BwAuthority/bwauthority_child.py @@ -73,7 +73,8 @@ __selmgr = PathSupport.SelectionManager( uniform=True, use_exit=None, use_guards=False, - exit_ports=[443]) + exit_ports=[443], + order_by_ratio=True) # exit code to indicate scan completion # make sure to update this in bwauthority.py as well

1 0

[torflow/master] Submodule.
by mikeperry＠torproject.org 27 Jun '11

27 Jun '11

commit a28419da99ef8bb5ec2f51ad7109784d93530721 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Mon Jun 27 11:26:18 2011 -0700 Submodule. --- TorCtl | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/TorCtl b/TorCtl index 962d30c..25cb2bf 160000 --- a/TorCtl +++ b/TorCtl @@ -1 +1 @@ -Subproject commit 962d30c72ffc85c1df79270d6ac5b25f0336d2d2 +Subproject commit 25cb2bf77b1a98f2273b0f90c99b57e3d6e21a41

1 0

[pytorctl/master] Implement ratio ranking support.
by mikeperry＠torproject.org 27 Jun '11

27 Jun '11

commit e538547dfc2973d7bd99e2d927a1d87be5230704 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Fri Jun 24 13:32:37 2011 -0700 Implement ratio ranking support. --- PathSupport.py | 36 ++++++++++++++++++++++++++++++++---- TorCtl.py | 16 ++++++++++++++++ 2 files changed, 48 insertions(+), 4 deletions(-) diff --git a/PathSupport.py b/PathSupport.py index 4e9ad6d..d4ffbdd 100644 --- a/PathSupport.py +++ b/PathSupport.py @@ -229,6 +229,27 @@ class PercentileRestriction(NodeRestriction): def __str__(self): return self.__class__.__name__+"("+str(self.pct_skip)+","+str(self.pct_fast)+")" +class RatioPercentileRestriction(NodeRestriction): + """Restriction to cut out a percentile slice of the network by ratio of + consensus bw to descriptor bw.""" + def __init__(self, pct_skip, pct_fast, r_list): + """Constructor. Sets up the restriction such that routers in the + 'pct_skip' to 'pct_fast' percentile of bandwidth rankings are + returned from the sorted list 'r_list'""" + self.pct_fast = pct_fast + self.pct_skip = pct_skip + self.sorted_r = r_list + + def r_is_ok(self, r): + "Returns true if r is in the percentile boundaries (by rank)" + if r.ratio_rank < len(self.sorted_r)*self.pct_skip/100: return False + elif r.ratio_rank > len(self.sorted_r)*self.pct_fast/100: return False + + return True + + def __str__(self): + return self.__class__.__name__+"("+str(self.pct_skip)+","+str(self.pct_fast)+")" + class UptimeRestriction(NodeRestriction): """Restriction to filter out routers with uptimes < min_uptime or > max_uptime""" @@ -1008,7 +1029,8 @@ class SelectionManager(BaseSelectionManager): def __init__(self, pathlen, order_exits, percent_fast, percent_skip, min_bw, use_all_exits, uniform, use_exit, use_guards,geoip_config=None, - restrict_guards=False, extra_node_rstr=None, exit_ports=None): + restrict_guards=False, extra_node_rstr=None, exit_ports=None, + order_by_ratio=False): BaseSelectionManager.__init__(self) self.__ordered_exit_gen = None self.pathlen = pathlen @@ -1026,6 +1048,7 @@ class SelectionManager(BaseSelectionManager): self.consensus = None self.exit_ports = exit_ports self.extra_node_rstr=extra_node_rstr + self.order_by_ratio = order_by_ratio def reconfigure(self, consensus=None): try: @@ -1063,17 +1086,22 @@ class SelectionManager(BaseSelectionManager): nonentry_skip = self.percent_skip nonentry_fast = self.percent_fast + if self.order_by_ratio: + PctRstr = RatioPercentileRestriction + else: + PctRstr = PercentileRestriction + # XXX: sometimes we want the ability to do uniform scans # without the conserve exit restrictions.. entry_rstr = NodeRestrictionList( - [PercentileRestriction(self.percent_skip, self.percent_fast, sorted_r), + [PctRstr(self.percent_skip, self.percent_fast, sorted_r), OrNodeRestriction( [FlagsRestriction(["BadExit"]), ConserveExitsRestriction(self.exit_ports)]), FlagsRestriction(entry_flags, [])] ) mid_rstr = NodeRestrictionList( - [PercentileRestriction(nonentry_skip, nonentry_fast, sorted_r), + [PctRstr(nonentry_skip, nonentry_fast, sorted_r), OrNodeRestriction( [FlagsRestriction(["BadExit"]), ConserveExitsRestriction(self.exit_ports)]), @@ -1090,7 +1118,7 @@ class SelectionManager(BaseSelectionManager): [FlagsRestriction(["Running","Fast"], ["BadExit"])]) else: self.exit_rstr = NodeRestrictionList( - [PercentileRestriction(nonentry_skip, nonentry_fast, sorted_r), + [PctRstr(nonentry_skip, nonentry_fast, sorted_r), FlagsRestriction(["Running","Fast"], ["BadExit"])]) if self.extra_node_rstr: diff --git a/TorCtl.py b/TorCtl.py index ac49574..f0cf5c5 100755 --- a/TorCtl.py +++ b/TorCtl.py @@ -460,6 +460,7 @@ class Router: self.version = RouterVersion(version) self.os = os self.list_rank = 0 # position in a sorted list of routers. + self.ratio_rank = 0 # position in a ratio-sorted list of routers self.uptime = uptime self.published = published self.refcount = 0 # How many open circs are we currently in? @@ -1709,6 +1710,11 @@ class ConsensusTracker(EventHandler): self.sorted_r.sort(lambda x, y: cmp(y.bw, x.bw)) for i in xrange(len(self.sorted_r)): self.sorted_r[i].list_rank = i + ratio_r = copy.copy(self.sorted_r) + ratio_r.sort(lambda x, y: cmp(float(y.bw)/y.desc_bw, + float(x.bw)/x.desc_bw)) + for i in xrange(len(ratio_r)): ratio_r[i].ratio_rank = i + # XXX: Verification only. Can be removed. self._sanity_check(self.sorted_r) @@ -1792,6 +1798,11 @@ class ConsensusTracker(EventHandler): self.sorted_r = filter(lambda r: not r.down, self.routers.itervalues()) self.sorted_r.sort(lambda x, y: cmp(y.bw, x.bw)) for i in xrange(len(self.sorted_r)): self.sorted_r[i].list_rank = i + + ratio_r = copy.copy(self.sorted_r) + ratio_r.sort(lambda x, y: cmp(float(y.bw)/y.desc_bw, + float(x.bw)/x.desc_bw)) + for i in xrange(len(ratio_r)): ratio_r[i].ratio_rank = i plog("DEBUG", str(time.time()-d.arrived_at)+ " Read " + str(len(d.idlist)) +" ND => "+str(len(self.sorted_r))+" routers. Update: "+str(update)) # XXX: Verification only. Can be removed. @@ -1821,6 +1832,11 @@ class ConsensusTracker(EventHandler): self.sorted_r = filter(lambda r: not r.down, self.routers.itervalues()) self.sorted_r.sort(lambda x, y: cmp(y.bw, x.bw)) for i in xrange(len(self.sorted_r)): self.sorted_r[i].list_rank = i + + ratio_r = copy.copy(self.sorted_r) + ratio_r.sort(lambda x, y: cmp(float(y.bw)/y.desc_bw, + float(x.bw)/x.desc_bw)) + for i in xrange(len(ratio_r)): ratio_r[i].ratio_rank = i self._sanity_check(self.sorted_r) def current_consensus(self):

1 0

[pytorctl/master] Merge branch 'ratio-restrictions'
by mikeperry＠torproject.org 27 Jun '11

27 Jun '11

commit 25cb2bf77b1a98f2273b0f90c99b57e3d6e21a41 Merge: 962d30c e538547 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Mon Jun 27 11:23:39 2011 -0700 Merge branch 'ratio-restrictions' PathSupport.py | 36 ++++++++++++++++++++++++++++++++---- TorCtl.py | 16 ++++++++++++++++ 2 files changed, 48 insertions(+), 4 deletions(-)

1 0