Nick Mathewson [Tue, 26 Apr 2011 19:20:08 +0000 (15:20 -0400)]
Expose a new process_signal(uintptr_t), not signal_callback()
This is a tweak to the bug2917 fix. Basically, if we want to simulate
a signal arriving in the controller, we shouldn't have to pretend that
we're Libevent, or depend on how Tor sets up its Libevent callbacks.
Sebastian Hahn [Tue, 26 Apr 2011 13:33:08 +0000 (15:33 +0200)]
Fix more of bug 2704
The last entry of the *Maxima values in the state file was inflated by a
factor of NUM_SECS_ROLLING_MEASURE (currently 10). This could lead to
a wrong maximum value propagating through the state file history.
Sebastian Hahn [Tue, 19 Apr 2011 14:00:41 +0000 (16:00 +0200)]
Prevent hugely inflated observed bandwidth values
When reading the bw history from the state file, we'd add the 900-second
value as traffic that occured during one second. Fix that by adding the
average value to each second.
This bug was present since 0.2.0.5-alpha, but was hidden until
0.2.23-alpha when we started using the saved values.
Sebastian Hahn [Fri, 15 Apr 2011 03:04:39 +0000 (20:04 -0700)]
Make SIGNAL DUMP work on FreeBSD
While doing so, get rid of the now unnecessary function
control_signal_act().
Fixes bug 2917, reported by Robert Ransom. Bugfix on commit 9b4aa8d2abbce71398e58188209a1b1d04885b96. This patch is loosely based on
a patch by Robert (Changelog entry).
Nick Mathewson [Thu, 7 Apr 2011 18:56:50 +0000 (14:56 -0400)]
Fix up some cell-queue stats issues in rephist.c
- Document the structure and variables.
- Make circuits_for_buffer_stats into a static variable.
- Don't die horribly if interval_length is 0.
- Remove the unused local_circ_id field.
- Reorder the fields of circ_buffer_stats_t for cleaner alignment layout.
Nick Mathewson [Wed, 16 Mar 2011 02:39:22 +0000 (22:39 -0400)]
Allow controllers a more up-to-date view of bridge usage.
Instead of answering GETINFO requests about our geoip usage only after
running for 24 hours, this patch makes us answer GETINFO requests
immediately. We still round and quantize as before.
Implements bug2711.
Also, refactor the heck out of the bridge usage formatting code. No
longer should we need to do a generate-parse-and-regenerate cycle to
get the controller string, and that lets us simplify the code a lot.
Nick Mathewson [Sat, 26 Mar 2011 05:34:42 +0000 (01:34 -0400)]
Use timevals, not time_t, when expiring circuits.
We've got millisecond timers now, we might as well use them.
This change won't actually make circuits get expiered with microsecond
precision, since we only call the expiry functions once per second.
Still, it should avoid the situation where we have a circuit get
expired too early because of rounding.
A couple of the expiry functions now call tor_gettimeofday: this
should be cheap since we're only doing it once per second. If it gets
to be called more often, though, we should onsider having the current
time be an argument again.
Nick Mathewson [Fri, 25 Mar 2011 21:57:15 +0000 (17:57 -0400)]
Fix handling of StreamID exhaustion.
Since svn r1475/git 5b6099e8 in tor-0.0.6, we have responded to an
exhaustion of all 65535 stream IDs on a circuit by marking that
circuit for close. That's not the right response. Instead, we
should mark the circuit as "too dirty for new circuits".
Of course in reality this isn't really right either. If somebody
has managed to cram 65535 streams onto a circuit, the circuit is
probably not going to work well for any of those streams, so maybe
we should be limiting the number of streams on an origin circuit
concurrently.
Also, closing the stream in this case is probably the wrong thing to
do as well, but fixing that can also wait.
Nick Mathewson [Fri, 25 Mar 2011 21:11:04 +0000 (17:11 -0400)]
Remove workaround code for bug539
We fixed bug 539 (where directories would say "503" but send data
anyway) back in 0.2.0.16-alpha/0.1.2.19. Because most directory
versions were affected, we added workaround to make sure that we
examined the contents of 503-replies to make sure there wasn't any
data for them to find. But now that such routers are nonexistent,
we can remove this code. (Even if somebody fired up an 0.1.2.19
directory cache today, it would still be fine to ignore data in its
erroneous 503 replies.)
Nick Mathewson [Fri, 25 Mar 2011 20:45:25 +0000 (16:45 -0400)]
Fix some 'impossible' overflow bugs in byte counting
The first was genuinely impossible, I think: it could only happen
when the amount we read differed from the amount we wanted to read
by more than INT_MAX.
The second is just very unlikely: it would give incorrect results to
the controller if you somehow wrote or read more than 4GB on one
edge conn in one second. That one is a bugfix on 0.1.2.8-beta.
Nick Mathewson [Fri, 25 Mar 2011 20:14:42 +0000 (16:14 -0400)]
Look at the right errno when sending reason for connect() failure
In afe414 (tor-0.1.0.1-rc~173), when we moved to
connection_edge_end_errno(), we used it in handling errors from
connection_connect(). That's not so good, since by the time
connection_connect() returns, the socket is no longer set, and we're
supposed to be looking at the socket_errno return value from
connection_connect() instead. So do what we should've done, and
look at the socket_errno value that we get from connection_connect().
Sebastian Hahn [Fri, 18 Mar 2011 16:04:01 +0000 (17:04 +0100)]
Remove superfluous -g -O2 compiler argument
Autoconf adds -g -O2 by default, so adding it ourselves is not required.
It also caused a warning with clang for every source file, so remove it
here. Fixes last issue of ticket 2696.
Nick Mathewson [Mon, 14 Mar 2011 21:48:45 +0000 (17:48 -0400)]
Consider sending stream-level SENDME cells on partial flushes.
Right now, we only consider sending stream-level SENDME cells when we
have completely flushed a connection_edge's outbuf, or when it sends
us a DATA cell. Neither of these is ideal for throughput.
This patch changes the behavior so we now call
connection_edge_consider_sending_sendme when we flush _some_ data from
an edge outbuf.
Sebastian Hahn [Wed, 9 Mar 2011 10:34:04 +0000 (11:34 +0100)]
Use observed instead of declared uptime for HSDir
It is important to verify the uptime claim of a relay instead of just
trusting it, otherwise it becomes too easy to blackhole a specific
hidden service. rephist already has data available that we can use here.