[tor-bugs] #6752 [Tor]: TestingTorNetwork doesn't lower the dir fetch retry schedules
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed Jan 9 14:15:04 UTC 2013
#6752: TestingTorNetwork doesn't lower the dir fetch retry schedules
------------------------+---------------------------------------------------
Reporter: arma | Owner:
Type: defect | Status: new
Priority: major | Milestone: Tor: 0.2.4.x-final
Component: Tor | Version:
Keywords: tor-client | Parent: #7172
Points: | Actualpoints:
------------------------+---------------------------------------------------
Comment(by arma):
rHere's the diff I gave Chris, who used it successfully for the December
demo:
{{{
diff --git a/src/or/directory.c b/src/or/directory.c
index 1d511b5..2ba5d54 100644
--- a/src/or/directory.c
+++ b/src/or/directory.c
@@ -3616,7 +3616,7 @@ 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, 5, 10, 15, 20, 30, 60
};
/** Schedule for when servers should download consensuses. */
static const int server_consensus_dl_schedule[] = {
@@ -3624,7 +3624,7 @@ 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, 5, 10, 15, 20, 30, 60
};
/** Schedule for when clients should download bridge descriptors. */
static const int bridge_dl_schedule[] = {
}}}
I also added
{{{
diff --git a/src/or/main.c b/src/or/main.c
index 446836a..e3b9345 100644
--- a/src/or/main.c
+++ b/src/or/main.c
@@ -148,7 +148,7 @@ int can_complete_circuit=0;
/** How often do we check for router descriptors that we should download
* when we have too little directory info? */
-#define GREEDY_DESCRIPTOR_RETRY_INTERVAL (10)
+#define GREEDY_DESCRIPTOR_RETRY_INTERVAL (5)
/** How often do we check for router descriptors that we should download
* when we have enough directory info? */
#define LAZY_DESCRIPTOR_RETRY_INTERVAL (60)
diff --git a/src/or/nodelist.c b/src/or/nodelist.c
index 95345fb..3b42994 100644
--- a/src/or/nodelist.c
+++ b/src/or/nodelist.c
@@ -1345,10 +1345,10 @@ update_router_have_minimum_dir_info(void)
/* What fraction of desired server descriptors do we need before we will
* build circuits? */
-#define FRAC_USABLE_NEEDED .75
+#define FRAC_USABLE_NEEDED .5
/* What fraction of desired _exit_ server descriptors do we need before
we
* will build circuits? */
-#define FRAC_EXIT_USABLE_NEEDED .5
+#define FRAC_EXIT_USABLE_NEEDED .3
if (num_present < num_usable * FRAC_USABLE_NEEDED) {
tor_snprintf(dir_info_status, sizeof(dir_info_status),
diff --git a/src/or/routerlist.c b/src/or/routerlist.c
index 1735837..6688591 100644
--- a/src/or/routerlist.c
+++ b/src/or/routerlist.c
@@ -3987,7 +3987,7 @@ initiate_descriptor_downloads(const routerstatus_t
*source,
#define MAX_DL_TO_DELAY 16
/** When directory clients have only a few servers to request, they batch
* them until they have more, or until this amount of time has passed. */
-#define MAX_CLIENT_INTERVAL_WITHOUT_REQUEST (10*60)
+#define MAX_CLIENT_INTERVAL_WITHOUT_REQUEST 5
/** Given a <b>purpose</b> (FETCH_MICRODESC or FETCH_SERVERDESC) and a
list of
* router descriptor digests or microdescriptor digest256s in
}}}
You'll notice in the download schedules, I don't have any INT_MAX at the
end -- it just keeps trying, often, for every descriptor. In a closed Tor
network that *should* be safe to do.
More generally, there seem to be two use cases for TestingTorNetwork here:
are you attempting to faithfully reproduce timing/etc problems from the
real Tor network, or is the goal just-run-the-damn-Tor-network-and-make-
it-work?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6752#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list