| Age | Commit message (Collapse) | Author |
|---|
|
This eliminates duplicated code, and lets us test a hairy piece of
functionality.
|
|
With this patch, I dump the old kludge of using magic negative
numbers to indicate unknown bandwidths. I also compute each node's
weighted bandwidth exactly once, rather than computing it once in
a loop to compute the total weighted bandwidth and a second time in
a loop to find which one we picked.
|
|
Previously, we had incremented rand_bw so that when we later tested
"tmp >= rand_bw", we wouldn't have an off-by-one error. But instead,
it makes more sense to leave rand_bw alone and test "tmp > rand_bw".
Note that this is still safe. To take the example from the bug1203
writeup: Suppose that we have 3 nodes with bandwidth 1. So the
bandwidth array is { 1, 1, 1 }, and the total bandwidth is 3. We
choose rand_bw == 0, 1, or 2. With the first iteration of the loop,
tmp is now 1; with the second, tmp is 2; with the third, tmp is 3.
Now that our check is tmp > rand_bw, we will set i in the first
iteration of the loop iff rand_bw == 0; in the second iteration of
the loop iff rand_bw == 1, and in the third iff rand_bw == 2.
That's what we want.
Incidentally, this change makes the bug 6538 fix more ironclad: once
rand_bw is set to UINT64_MAX, tmp > rand_bw is obviously false
regardless of the value of tmp.
|
|
The old approach, because of its "tmp >= rand_bw &&
!i_has_been_chosen" check, would run through the second part of the
loop slightly slower than the first part. Now, we remove
i_has_been_chosen, and instead set rand_bw = UINT64_MAX, so that
every instance of the loop will do exactly the same amount of work
regardless of the initial value of rand_bw.
Fix for bug 6538.
|
|
This should make our preferred solution to #6538 easier to
implement, avoid a bunch of potential nastiness with excessive
int-vs-double math, and generally make the code there a little less
scary.
"But wait!" you say. "Is it really safe to do this? Won't the
results come out differently?"
Yes, but not much. We now round every weighted bandwidth to the
nearest byte before computing on it. This will make every node that
had a fractional part of its weighted bandwidth before either
slighty more likely or slightly less likely. Further, the rand_bw
value was only ever set with integer precision, so it can't
accurately sample routers with tiny fractional bandwidth values
anyway. Finally, doing repeated double-vs-uint64 comparisons is
just plain sad; it will involve an implicit cast to double, which is
never a fun thing.
|
|
|
|
Conflicts:
src/or/routerlist.c
|
|
Tor's and OpenSSL's current design guarantee that there are other leaks,
but this one is likely to be more easily exploitable, and is easy to fix.
|
|
|
|
|
|
Fix for 6530; fix on 0.2.2.6-alpha.
|
|
Fixes 6480; fix on 0.2.0.1-alpha; based on pseudonymous patch.
|
|
|
|
Fix for 6490.
|
|
|
|
|
|
|
|
I only check on circuits, not streams, since bloating your stream
window past the initial circuit window can't help you much.
Also, I compare to CIRCWINDOW_START_MAX so we don't have surprising
races if we lower CIRCWINDOW_START for an experiment.
|
|
|
|
|
|
|
|
|
|
The SMARTLIST_FOREACH macro is more convenient than BEGIN/END when
you have a nice short loop body, but using it for long bodies makes
your preprocessor tell the compiler that all the code is on the same
line. That causes grief, since compiler warnings and debugger lines
will all refer to that one line.
So, here's a new style rule: SMARTLIST_FOREACH blocks need to be
short.
|
|
Allow TestingTorNetwork when AlternateDirAuthority and
AlternateBridgeAuthority is set even if DirServer is not.
|
|
Fixes bug 6397 and coverity issue 709599. Bugfix on 0.2.3.17-beta.
|
|
|
|
|
|
The June 2012 db marks too many relays as country "A1".
Addresses bug 6334.
|
|
|
|
|
|
This could result in bizarre window values. Report and patch
contributed pseudymously. Fixes part of bug 6271. This bug was
introduced before the first Tor release, in svn commit r152.
(bug 6271, part a.)
|
|
|
|
This reverts commit c32ec9c425e9539bcc8ede95612e2d331c2cc2dd.
It turns out the two sides of the circuit don't actually stay in sync,
so it is perfectly normal for the circuit window on the exit relay to
grow to 2000+. We should fix that bug and then reconsider this patch.
|
|
I only check on circuits, not streams, since bloating your stream
window past the initial circuit window can't help you much.
Also, I compare to CIRCWINDOW_START_MAX so we don't have surprising
races if we lower CIRCWINDOW_START for an experiment.
|
|
|
|
|
|
|
|
|
|
|
|
warning to info, except when we're a dirauth (fixes bug 5238)
|
|
|
|
|
|
|
|
With glibc 2.15 and clang 3.0, I get warnings from where we use the
strcpsn implementation in the header as strcspn(string, "="). This
is apparently because clang sees that part of the strcspn macro
expands to "="[2], and doesn't realize that that part of the macro
is only evaluated when "="[1] != 0.
|
|
I need this because I'm about to frob that function to stop using
strcspn() in order to get rid of a clang warning.
|
|
In b1ad1a1d0266a20bb we introduced an implicit (but safe)
long-to-int shortening that clang didn't like.
Warning not in any released version of Tor.
|
|
Fix for #6238
|
|
This should make some debian build systems happier.
Also, increase the select() timeout to a more reasonable 100 msec.
|
|
The functions parse_{s,c}method_line() were using
tor_addr_port_lookup() which is capable of doing DNS lookups. DNS
lookups should not be necessary when parsing {C,S}METHOD lines.
|
|
|
