[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] r8629: backport: If none of our live entry guards have a high uptim (in tor/branches/tor-0_1_1-patches: . src/or)
- To: or-cvs@xxxxxxxxxxxxx
- Subject: [or-cvs] r8629: backport: If none of our live entry guards have a high uptim (in tor/branches/tor-0_1_1-patches: . src/or)
- From: arma@xxxxxxxx
- Date: Fri, 6 Oct 2006 22:57:20 -0400 (EDT)
- Delivered-to: archiver@seul.org
- Delivered-to: or-cvs-outgoing@seul.org
- Delivered-to: or-cvs@seul.org
- Delivery-date: Fri, 06 Oct 2006 22:57:29 -0400
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-cvs@xxxxxxxxxxxxx
Author: arma
Date: 2006-10-06 22:57:19 -0400 (Fri, 06 Oct 2006)
New Revision: 8629
Modified:
tor/branches/tor-0_1_1-patches/ChangeLog
tor/branches/tor-0_1_1-patches/src/or/circuitbuild.c
Log:
backport: If none of our live entry guards have a high uptime, but we
require a guard with a high uptime, try adding a new guard before
we give up on the requirement. This patch should make long-lived
connections more stable on average.
Modified: tor/branches/tor-0_1_1-patches/ChangeLog
===================================================================
--- tor/branches/tor-0_1_1-patches/ChangeLog 2006-10-07 02:55:44 UTC (rev 8628)
+++ tor/branches/tor-0_1_1-patches/ChangeLog 2006-10-07 02:57:19 UTC (rev 8629)
@@ -3,16 +3,20 @@
- When a client asks us to resolve (not connect to) an address,
and we have a cached answer, give them the cached answer.
Previously, we would give them no answer at all.
+ - We were building exactly the wrong circuits when we predict
+ hidden service requirements, meaning Tor would have to build all
+ its circuits on demand.
+ - If none of our live entry guards have a high uptime, but we
+ require a guard with a high uptime, try adding a new guard before
+ we give up on our requirement. This patch should make long-lived
+ connections more stable on average.
o Minor bugfixes:
- Avoid a memory corruption bug when creating a hash table for
the first time.
- - We were building exactly the wrong circuits when we anticipated
- hidden service requirements, meaning Tor would have to build all
- its circuits on demand.
- - Avoid possibility of controller-triggered crash when misusing certain
- commands from a v0 controller on platforms that do not handle
- printf("%s",NULL) gracefully.
+ - Avoid possibility of controller-triggered crash when misusing
+ certain commands from a v0 controller on platforms that do not
+ handle printf("%s",NULL) gracefully.
Changes in version 0.1.1.24 - 2006-09-29
Modified: tor/branches/tor-0_1_1-patches/src/or/circuitbuild.c
===================================================================
--- tor/branches/tor-0_1_1-patches/src/or/circuitbuild.c 2006-10-07 02:55:44 UTC (rev 8628)
+++ tor/branches/tor-0_1_1-patches/src/or/circuitbuild.c 2006-10-07 02:57:19 UTC (rev 8629)
@@ -2228,10 +2228,6 @@
* using him.
* (We might get 2 live-but-crummy entry guards, but so be it.) */
if (smartlist_len(live_entry_guards) < 2) {
- if (need_uptime) {
- need_uptime = 0; /* try without that requirement */
- goto retry;
- }
if (!options->StrictEntryNodes) {
/* still no? try adding a new entry then */
r = add_an_entry_guard(NULL);
@@ -2240,6 +2236,10 @@
entry_guards_changed();
}
}
+ if (!r && need_uptime) {
+ need_uptime = 0; /* try without that requirement */
+ goto retry;
+ }
if (!r && need_capacity) {
/* still no? last attempt, try without requiring capacity */
need_capacity = 0;