| Commit message (Collapse) | Author | Age |
... | |
|/ /
| |
| |
| |
| |
| |
| | |
These seem to have gotten conflicted out of existence while mike was
working on path bias stuff.
Thanks to sysrqb for collecting these in a handy patch.
|
| | |
|
| |
| |
| |
| |
| | |
This informational counter is probably now redundant, but might as well keep
it consistent I guess.
|
| | |
|
| |
| |
| |
| |
| |
| | |
Also document it better.
Mention this refactoring in the comments for the path state machine.
|
| | |
|
| |
| |
| |
| |
| | |
Also, deprecate the torrc options for the scaling values. It's unlikely anyone
but developers will ever tweak them, even if we provided a single ratio value.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Improve debug logs and fix a state fencepost error.
|
| |
| |
| |
| | |
Make a debug log more informative.
|
| |
| |
| |
| | |
Move a log message about scaling to after we scale
|
| |
| |
| |
| |
| |
| |
| |
| | |
If any circuits were opened during a scaling event, we were scaling attempts
and successes by different amounts. This leads to rounding error.
The fix is to record how many circuits are in a state that hasn't been fully
counted yet, and subtract that before scaling, and add it back afterwords.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since they use RELAY_EARLY (which can be seen by all hops on the path),
it's not safe to say they actually count as a successful use.
There are also problems with trying to allow them to finish extending due to
the circuit purpose state machine logic. It is way less complicated (and
possibly more semantically coherent) to simply wait until we actually try to
do something with them before claiming we 'used' them.
Also, we shouldn't call timed out circuits 'used' either, for semantic
consistency.
|
| |
| |
| |
| |
| |
| |
| | |
Path use bias measures how often we can actually succeed using the circuits we
actually try to use. It is a subset of path bias accounting, but it is
computed as a separate statistic because the rate of client circuit use may
vary depending on use case.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is an automatically generated commit, from the following perl script,
run with the options "-w -i -p".
s/smartlist_string_num_isin/smartlist_contains_int_as_string/g;
s/smartlist_string_isin((?:_case)?)/smartlist_contains_string$1/g;
s/smartlist_digest_isin/smartlist_contains_digest/g;
s/smartlist_isin/smartlist_contains/g;
s/digestset_isin/digestset_contains/g;
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Also add in the random nonce generation.
|
| |
| |
| |
| |
| |
| |
| |
| | |
In general, if we tried to use a circ for a stream, but then decided to place
that stream on a different circuit, we need to probe the original circuit
before deciding it was a "success".
We also need to do the same for cannibalized circuits that go unused.
|
| |
| |
| |
| | |
Fix cannibalize, rend circ and intro circ timeout handling.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/or/cpuworker.c
src/or/or.h
src/test/bench.c
|
| | | |
|
| | |
| | |
| | |
| | | |
"works for me"
|
| | |
| | |
| | |
| | |
| | | |
We want to sanity-check our own create cells carefully, and other
people's loosely.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The unit of work sent to a cpuworker is now a create_cell_t; its
response is now a created_cell_t. Several of the things that call or
get called by this chain of logic now take create_cell_t or
created_cell_t too.
Since all cpuworkers are forked or spawned by Tor, they don't need a
stable wire protocol, so we can just send structs. This saves us some
insanity, and helps p
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The handshake_digest field was never meaningfully a digest *of* the
handshake, but rather is a digest *from* the handshake that we exapted
to prevent replays of ESTABLISH_INTRO cells. The ntor handshake will
generate it as more key material rather than taking it from any part
of the circuit handshake reply..
|
| | |
| | |
| | |
| | |
| | | |
The three handshake types are now accessed from a unified interface;
their state is abstracted from the rest of the cpath state, and so on.
|
| | | |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I'm going to want a generic "onionskin" type and set of wrappers, and
for that, it will be helpful to isolate the different circuit creation
handshakes. Now the original handshake is in onion_tap.[ch], the
CREATE_FAST handshake is in onion_fast.[ch], and onion.[ch] now
handles the onion queue.
This commit does nothing but move code and adjust header files.
|
| | |
|
| | |
|
| |
| |
| |
| | |
I think this is actually his third code review of this branch so far.
|
| |
| |
| |
| |
| | |
Close the circuit (it's probably junk anyways), and make sure we don't probe
it/count it as a success.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
We need to use the success count or the use count depending on the consensus
parameter.
|
| |
| |
| |
| | |
Let's hope this solves the rounding error issue..
|
| |
| |
| |
| |
| |
| | |
For consistency and great justice.
Ok, mostly consistency.
|
| |
| |
| |
| |
| | |
Since we've generalized what we can count from (first or second hop), we
should generalize the variable and constant naming too.
|
| |
| |
| |
| |
| |
| |
| | |
This has several advantages, including more resilience to ambient failure.
I still need to rename all the first_hop vars tho.. Saving that for a separate
commit.
|
| |
| |
| |
| | |
Also add some comments.
|