[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
-----BEGIN PGP SIGNED MESSAGE-----
I just initially commited the second part of my project, which is a controller for ORs
that is listening to bw and orconn-bw events (needs orconn-bw.patch). While doing this
it counts and adds up all the bytes read and written for each single TLS-connection, as
well as for the complete node. From these an average throughput value for each link and
the whole node gets computed every n seconds (my currently used value is 30 sec).
Additionally a maximum reached value gets stored that can be used to compute an 'estimated
available bandwidth' for each link as well as for the whole node. As a first step this will
be done simply by computing the difference of max and the avg of the last interval:
available = max-avg
Clients (op-addon.py) can connect to a specified port and request a bandwidth document.
This document should better be served by Tor itself via http on some URL as soon as I
know exactly how to do this technically. The current format of the document is:
AVAILABLE MAX AVG
x available max avg
y available max avg
z available max avg
The values in the first line (AVAILABLE, MAX, AVG) are total node's stats computed
from bw-events. After that there is a separator and then a list of stats about the
single TLS-connections is following: In each line the x/y/z is the nickname or idhex
of the endpoint while the values are those computed from orconn-bw events. This list
is sorted by 'available' and it also could be cut off to include only links with at
least n measured bytes/sec available (configurable). A client (op-addon.py), while
searching for links to build up high bandwidth circuits, can read this list and then
compute 'currently estimated available bandwidths' for each link with
available_x = min(MAX-AVG, max_x-avg_x)
Note that the available-value actually is computed using the other two values, so
clients could also get delivered max and avg only to compute the difference on their
own. But since I plan to use mainly (max_x-avg_x) and (MAX-AVG) I rather think about
_only_ delivering AVAILABLE plus an available for each link.
Clients (op-addon.py) could do route selection based on this in at least three ways:
- Search in descriptors for supporting routers (X-tra info) --> n routers
- Choose one of them randomly (to use as middle node in a circuit)
- Get its bandwidth-document via Tor
- Use the chosen node as middle node and select 2 'high-bandwidth-available'
links from its list, which then define entry and exit (one endpoint must
support exit). This selection can be done randomly considering a subset of
the links from the list, having available > x bytes/sec.
- Get bandwidth documents from all n supporting routers via Tor
- Save and merge all of the received information
- Find 3 adjacent links with available bandwidths in the same class
- Put them together to a circuit
- Just consider (global) MAX and AVG to gain information about the
current load on the queried router
- Any suggestions/ideas?
Further, if we had an alternate directory, it could gather and merge bw-information from
every supporting router while trying to prove for correctness and even functionality to
report lyers could be integrated. Another possibility to detect lyers would be to use a
newly created circuit, measure bandwidth and see if the expected results are reached.
What do you think?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----