So far we just had the asciidoc manpage, but didn't build it.

Conflicts:
	src/common/util.c

Jacob Appelbaum authored 14 years ago and Nick Mathewson committed 14 years ago

 * 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

Jacob Appelbaum authored 14 years ago and Nick Mathewson committed 14 years ago

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.