| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The node_t type is meant to serve two key functions:
1) Abstracting difference between routerinfo_t and microdesc_t
so that clients can use microdesc_t instead of routerinfo_t.
2) Being a central place to hold mutable state about nodes
formerly held in routerstatus_t and routerinfo_t.
This patch implements a nodelist type that holds a node for every
router that we would consider using.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
src/common/util.c
|
|
|
|
|
|
|
|
|
|
|
|
* MINIUPNPC rather than the generic UPNP
* Nick suggested a better abstraction model for tor-fw-helper
* Fix autoconf to build with either natpmp or miniupnpc
* Add AM_PROG_CC_C_O to fix automake complaint
* update spec to address nickm's concern
* refactor nat-pmp to match upnp state
* we prefer tor_snprintf to snprintf
* link properlty for tor_snprintf
* rename test_commandline_options to log_commandline_options
* cast this uint as an int
* detect possible FD_SETSIZE errors
* make note about future enhancements for natpmp
* add upnp enhancement note
* ChangeLog entry
* doxygen and check-spaces cleanup
* create tor-fw-helper.1.txt
|
|
tor-fw-helper is a command-line tool to wrap and abstract various
firewall port-forwarding tools.
This commit matches the state of Jacob's tor-fw-helper branch as of
23 September 2010.
(commit msg by Nick)
|
|
|
|
|
|
When picking bridges (or other nodes without a consensus entry (and
thus no bandwidth weights)) we shouldn't just trust the node's
descriptor. So far we believed anything between 0 and 10MB/s, where 0
would mean that a node doesn't get any use from use unless it is our
only one, and 10MB/s would be a quite siginficant weight. To make this
situation better, we now believe weights in the range from 20kB/s to
100kB/s. This should allow new bridges to get use more quickly, and
means that it will be harder for bridges to see almost all our traffic.
|
|
|
|
|
|
|
|
This won't change any behavior, since it will still be rounded back
up to 2seconds, but should reduce the chances of some extra warns.
|
|
|
|
|
|
|
|
In the first 100 circuits, our timeout_ms and close_ms
are the same. So we shouldn't transition circuits to purpose
CIRCUIT_PURPOSE_C_MEASURE_TIMEOUT, since they will just timeout again
next time we check.
|
|
|
|
|
|
|
|
|
|
Also, cap the measurement timeout to 2X the max we've seen.
|
|
We really should ignore any timeouts that have *no* network activity for their
entire measured lifetime, now that we have the 95th percentile measurement
changes. Usually this is up to a minute, even on fast connections.
|
|
If we really want all this complexity for these stages here, we need to handle
it better for people with large timeouts. It should probably go away, though.
|
|
Rechecking the timeout condition was foolish, because it is checked on the
same codepath. It was also wrong, because we didn't round.
Also, the liveness check itself should be <, and not <=, because we only have
1 second resolution.
|
|
We now differentiate between timeouts and cutoffs by the REASON string and
the PURPOSE string.
|
|
Use 4/3 of this timeout value for 4 hop circuits, and use half of it for
canabalized circuits.
|
|
|
|
|
|
|
|
|
|
|
|
Specifically, a circ attempt that we'd launched while the network was
down could timeout after we've marked our entrynodes up, marking them
back down again. The fix is to annotate as bad the OR conns that were
around before we did the retry, so if a circuit that's attached to them
times out we don't do anything about it.
|
|
Otherwise we'd never set have_minimum_dir_info to false, so the
"optimistic retry" would never trigger.
|
|
We used to mark all our known bridges up when they're all down and we
get a new socks request. Now do that when we've set EntryNodes too.
|
|
|
|
|
|
|
|
|
|
|
