nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-30 15:43:32 +01:00
Code Issues Packages Projects Releases Wiki Activity

New consensus params "bwconnrate" and "bwconnburst"

Browse Source 
...to let us
rate-limit client connections as they enter the network. It's
controlled in the consensus so we can turn it on and off for
experiments. It's starting out off. Based on proposal 163.
This commit is contained in:
Roger Dingledine 2009-12-23 04:56:24 -05:00
parent 7d832cc988
commit 2ef988c065
2 changed files with 36 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
ChangeLog
View File

@ -1,4 +1,4 @@
Changes in version 0.2.2.7-alpha - 2009-??-??
Changes in version 0.2.2.7-alpha - 2009-12-??
o Major features (performance):
- When choosing which cells to relay first, we can now favor circuits
that have been quiet recently, so as to get lower latency for
@ -8,10 +8,15 @@ Changes in version 0.2.2.7-alpha - 2009-??-??
use it. You can override this default by using the new
"CircuitPriorityHalflife" config option. Design and code by Ian
Goldberg, Can Tang, and Chris Alexander.
- New consensus params "bwconnrate" and "bwconnburst" to let us
rate-limit client connections as they enter the network. It's
controlled in the consensus so we can turn it on and off for
experiments. It's starting out off. Based on proposal 163.
o Major features (relay selection):
- Switch to a StrictNodes config option, rather than the previous
"StrictEntryNodes" / "StrictExitNodes" separation.
"StrictEntryNodes" / "StrictExitNodes" separation that was missing a
"StrictExcludeNodes" option.
- If EntryNodes, ExitNodes, ExcludeNodes, or ExcludeExitNodes
change during a config reload, mark and discard all our origin
circuits. This fix should address edge cases where we change the

29
src/or/connection_or.c
View File

@ -320,6 +320,19 @@ connection_or_finished_connecting(or_connection_t *or_conn)
return 0;
}
/** Return 1 if identity digest <b>id_digest</b> is known to be a
* currently or recently running relay. Otherwise return 0. */
static int
connection_or_digest_is_known_relay(const char *id_digest)
{
if (router_get_consensus_status_by_id(id_digest))
return 1; /* It's in the consensus: "yes" */
if (router_get_by_digest(id_digest))
return 1; /* Not in the consensus, but we have a descriptor for
* it. Probably it was in a recent consensus. "Yes". */
return 0;
}
/** If we don't necessarily know the router we're connecting to, but we
* have an addr/port/id_digest, then fill in as much as we can. Start
* by checking to see if this describes a router we know. */
@ -331,9 +344,23 @@ connection_or_init_conn_from_address(or_connection_t *conn,
{
or_options_t *options = get_options();
routerinfo_t *r = router_get_by_digest(id_digest);
connection_or_set_identity_digest(conn, id_digest);
if (connection_or_digest_is_known_relay(id_digest)) {
/* It's in the consensus, or we have a descriptor for it meaning it
* was probably in a recent consensus. It's a recognized relay:
* give it full bandwidth. */
conn->bandwidthrate = (int)options->BandwidthRate;
conn->read_bucket = conn->bandwidthburst = (int)options->BandwidthBurst;
connection_or_set_identity_digest(conn, id_digest);
} else { /* Not a recognized relay. Squeeze it down based on the
* suggested bandwidth parameters in the consensus. */
conn->bandwidthrate =
(int)networkstatus_get_param(NULL, "bwconnrate",
(int)options->BandwidthRate);
conn->read_bucket = conn->bandwidthburst =
(int)networkstatus_get_param(NULL, "bwconnburst",
(int)options->BandwidthBurst);
}
conn->_base.port = port;
tor_addr_copy(&conn->_base.addr, addr);