[tor-bugs] #6752 [Tor]: TestingTorNetwork doesn't lower the dir fetch retry schedules
Tor Bug Tracker & Wiki
blackhole at torproject.org
Fri Feb 22 12:39:19 UTC 2013
#6752: TestingTorNetwork doesn't lower the dir fetch retry schedules
--------------------------------------+-------------------------------------
Reporter: arma | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Tor: 0.2.4.x-final
Component: Tor | Version:
Keywords: tor-client small-feature | Parent: #7172
Points: | Actualpoints:
--------------------------------------+-------------------------------------
Comment(by karsten):
I tried a Shadow network with 5 authorities and with clients starting at
the same time as authorities, but I can't reproduce this situation. I
applied this patch with a crazy retry schedule and with log messages to
notice when clients switched to a different retry interval:
{{{
diff --git a/src/or/directory.c b/src/or/directory.c
index f235bf3..b654a85 100644
--- a/src/or/directory.c
+++ b/src/or/directory.c
@@ -3625,7 +3625,8 @@ static const int server_dl_schedule[] = {
};
/** Schedule for when clients should download things in general. */
static const int client_dl_schedule[] = {
- 0, 0, 60, 60*5, 60*10, INT_MAX
+ //0, 0, 60, 60*5, 60*10, INT_MAX
+ 15, INT_MAX
};
/** Schedule for when servers should download consensuses. */
static const int server_consensus_dl_schedule[] = {
@@ -3633,7 +3634,8 @@ static const int server_consensus_dl_schedule[] = {
};
/** Schedule for when clients should download consensuses. */
static const int client_consensus_dl_schedule[] = {
- 0, 0, 60, 60*5, 60*10, 60*30, 60*60, 60*60, 60*60, 60*60*3, 60*60*6,
60*60*12
+ //0, 0, 60, 60*5, 60*10, 60*30, 60*60, 60*60, 60*60, 60*60*3, 60*60*6,
60*60*12
+ 15, INT_MAX
};
/** Schedule for when clients should download bridge descriptors. */
static const int bridge_dl_schedule[] = {
@@ -3708,14 +3710,14 @@
download_status_increment_failure(download_status_t *dls, int status_code,
if (item) {
if (increment == 0)
- log_debug(LD_DIR, "%s failed %d time(s); I'll try again
immediately.",
+ log_info(LD_DIR, "XXX6752 %s failed %d time(s); I'll try again
immediately.",
item, (int)dls->n_download_failures);
else if (dls->next_attempt_at < TIME_MAX)
- log_debug(LD_DIR, "%s failed %d time(s); I'll try again in %d
seconds.",
+ log_info(LD_DIR, "XXX6752 %s failed %d time(s); I'll try again in
%d seconds.",
item, (int)dls->n_download_failures,
(int)(dls->next_attempt_at-now));
else
- log_debug(LD_DIR, "%s failed %d time(s); Giving up for a while.",
+ log_info(LD_DIR, "XXX6752 %s failed %d time(s); Giving up for a
while.",
item, (int)dls->n_download_failures);
}
return dls->next_attempt_at;
@@ -3738,6 +3740,8 @@ download_status_reset(download_status_t *dls)
find_dl_schedule_and_len(dls, get_options()->DirPort_set,
&schedule, &schedule_len);
+ if (dls->n_download_failures)
+ log_info(LD_DIR, "XXX6752 Resetting download status.");
dls->n_download_failures = 0;
dls->next_attempt_at = time(NULL) + schedule[0];
}
}}}
Here's the result:
{{{
$ grep webclient1 data/scallion.log | grep XXX6752
0:0:10:543339 [thread-0] 0:3:2:000000010 [scallion-info]
[webclient1-82.1.0.0] [intercept_logv] [info] void
download_status_reset(download_status_t *)() XXX6752 Resetting download
status.
0:0:13:251122 [thread-0] 0:6:2:000000011 [scallion-info]
[webclient1-82.1.0.0] [intercept_logv] [info] void
download_status_reset(download_status_t *)() XXX6752 Resetting download
status.
}}}
Note that there are no failures in those logs. Also, clients bootstrap
just fine, though it takes 10 simulated minutes to do so:
{{{
$ grep webclient1 data/scallion.log | grep Bootstrap
0:0:2:638041 [thread-0] 0:0:2:000000000 [scallion-info]
[webclient1-82.1.0.0] [intercept_logv] [info] Bootstrapped 0%: Starting.
0:0:9:968690 [thread-0] 0:1:3:000000000 [scallion-message]
[webclient1-82.1.0.0] [intercept_logv] [notice] Bootstrapped 5%:
Connecting to directory server.
0:0:9:974529 [thread-0] 0:1:3:061000001 [scallion-message]
[webclient1-82.1.0.0] [intercept_logv] [notice] Bootstrapped 10%:
Finishing handshake with directory server.
0:0:9:990886 [thread-0] 0:1:3:247299267 [scallion-message]
[webclient1-82.1.0.0] [intercept_logv] [notice] Bootstrapped 15%:
Establishing an encrypted directory connection.
0:0:9:995853 [thread-0] 0:1:3:325961616 [scallion-message]
[webclient1-82.1.0.0] [intercept_logv] [notice] Bootstrapped 20%: Asking
for networkstatus consensus.
0:0:10:001487 [thread-0] 0:1:3:397083916 [scallion-message]
[webclient1-82.1.0.0] [intercept_logv] [notice] Bootstrapped 25%: Loading
networkstatus consensus.
0:0:15:171272 [thread-0] 0:7:9:696519922 [scallion-message]
[webclient1-82.1.0.0] [intercept_logv] [notice] Bootstrapped 40%: Loading
authority key certs.
0:0:15:193358 [thread-0] 0:7:9:822844471 [scallion-message]
[webclient1-82.1.0.0] [intercept_logv] [notice] Bootstrapped 45%: Asking
for relay descriptors.
0:0:17:437195 [thread-0] 0:10:8:851821396 [scallion-message]
[webclient1-82.1.0.0] [intercept_logv] [notice] Bootstrapped 80%:
Connecting to the Tor network.
0:0:17:437503 [thread-0] 0:10:8:851821396 [scallion-message]
[webclient1-82.1.0.0] [intercept_logv] [notice] Bootstrapped 90%:
Establishing a Tor circuit.
0:0:17:487530 [thread-0] 0:10:9:651673193 [scallion-message]
[webclient1-82.1.0.0] [intercept_logv] [notice] Bootstrapped 100%: Done.
}}}
How would I force clients to make just two attempts, with the second
attempt happening 15 seconds after the first, and then wait forever?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6752#comment:18>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list