- Aug 04, 2011
-
-
Karsten Loesing authored
Now that formatting the buffer-stats string is separate from writing it to disk, we can also decouple the logic to extract stats from circuits and finally write some unit tests for the history code.
-
Karsten Loesing authored
The new rep_hist_format_buffer_stats() generates a buffer-stats string that rep_hist_buffer_stats_write() writes to disk. All the state changing (e.g., resetting the buffer-stats history and initializing the next measurement interval) takes place in rep_hist_buffer_stats_write(). That allows us to finally test the buffer-stats code better.
-
Karsten Loesing authored
We later want to split this function into one function that generates the buffer-stats string and one that writes it to disk.
-
Karsten Loesing authored
So far, if we didn't see a single circuit, we refrained from generating a cell-stats string and logged a warning. Nobody will notice the warning, and people will wonder why there's no cell-stats string in the extra-info descriptor. The better behavior is to generate a cell-stats string with all zeros.
-
Karsten Loesing authored
Right now, we append statistics to files in the stats/ directory for half of the statistics, whereas we overwrite these files for the other half. In particular, we append buffer, dirreq, and entry stats and overwrite exit, connection, and bridge stats. Appending to files was useful when we didn't include stats in extra-info descriptors, because otherwise we'd have to copy them away to prevent Tor from overwriting them. But now that we include statistics in extra-info descriptors, it makes no sense to keep the old statistics forever. We should change the behavior to overwriting instead of appending for all statistics. Implements #2930.
-
- Aug 02, 2011
-
-
Nick Mathewson authored
Previously we'd just looked at the connection type, but that's always CONN_TYPE_AP. Instead, we should be looking at the type of the listener that created the connection. Spotted by rransom; fixes bug 3636.
-
- Aug 01, 2011
-
-
Roger Dingledine authored
-
Roger Dingledine authored
-
Nick Mathewson authored
We'll still need to tweak it so that it looks for includes and libraries somewhere more sensible than "where we happened to find them on Erinn's system"; so that tests and tools get built too; so that it's a bit documented; and so that we actually try running the output. Work done with Erinn Clark.
-
Nick Mathewson authored
Patch from "blueness".
-
- Jul 21, 2011
-
-
-
Nick Mathewson authored
-
Roger Dingledine authored
(that is, to change the default for "UseOptimisticData auto" to 1 once we are more convinced that it works correctly.)
-
Nick Mathewson authored
-
- Jul 20, 2011
-
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Sebastian Hahn authored
-
Nick Mathewson authored
Otherwise, we'll fail, since "9050" looks like a perfectly fine address.
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
Previously, if tor_addr_to_str() returned NULL, we would reuse the last value returned by fmt_addr(). (This could happen if we were erroneously asked to format an AF_UNSPEC address.) Now instead we return "???".
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
The conflicts are with the proposal 171 circuit isolation code, and they're all trivial: they're just a matter of both branches adding some unrelated code in the same places. Conflicts: src/or/circuituse.c src/or/connection.c
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
The problem was that we weren't initializing want_length to 0 before calling parse_socks() the first time, so it looked like we were risking an infinite loop when in fact we were safe. Fixes 3615; bugfix on 0.2.3.2-alpha.
-
- Jul 19, 2011
-
-
Nick Mathewson authored
-
Nick Mathewson authored
Back when I added this logic in 20c0581a, the rule was that whenever a circuit finished building, we cleared its isolation info. I did that so that we would still use the circuit even if all the streams that had previously led us to tentatively set its isolation info had closed. But there were problems with that approach: We could pretty easily get into a case where S1 had led us to launch C1 and S2 had led us to launch C2, but when C1 finished, we cleared its isolation and attached S2 first. Since C2 was still marked in a way that made S1 unattachable to it, we'd then launch another circuit needlessly. So instead, we try the following approach now: when a circuit is done building, we try to attach streams to it. If it remains unused after we try attaching streams, then we clear its isolation info, and try again to attach streams. Thanks to Sebastian for helping me figure this out.
-
Nick Mathewson authored
-
Nick Mathewson authored
-
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
One-hop dirconn streams all share a session group, and get the ISO_SESSIONGRP flag: they may share circuits with each other and nothing else. Anonymized dirconn streams get a new internal-use-only ISO_STREAM flag: they may not share circuits with anything, including each other.
-