[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #11679 [Tor]: Download status for consensus scheduled as generic
#11679: Download status for consensus scheduled as generic
-----------------------------+-------------------------------------------
Reporter: cypherpunks | Owner:
Type: defect | Status: new
Priority: normal | Milestone: Tor: 0.2.6.x-final
Component: Tor | Version:
Resolution: | Keywords: tor-client easy 026-triaged-1
Actual Points: | Parent ID:
Points: |
-----------------------------+-------------------------------------------
Comment (by arma):
What would you think of this patch?
{{{
diff --git a/src/or/networkstatus.c b/src/or/networkstatus.c
index 95eb320..2f22eb1 100644
--- a/src/or/networkstatus.c
+++ b/src/or/networkstatus.c
@@ -754,6 +754,7 @@ update_consensus_networkstatus_downloads(time_t now)
resource = networkstatus_get_flavor_name(i);
+ consensus_dl_status[i].schedule = DL_SCHED_CONSENSUS;
if (!download_status_is_ready(&consensus_dl_status[i], now,
options->TestingConsensusMaxDownloadTries))
continue; /* We failed downloading a consensus too recently. */
}}}
It sets the schedule every time it goes through, which should be cheap to
do, and is maybe a bit less intuitive than having a separate
initialization function, but makes up for it in simplicity.
Here's the more complicated version:
{{{
diff --git a/src/or/networkstatus.c b/src/or/networkstatus.c
index 95eb320..e2e5a95 100644
--- a/src/or/networkstatus.c
+++ b/src/or/networkstatus.c
@@ -722,6 +722,14 @@ we_want_to_fetch_flavor(const or_options_t *options,
int f
return flavor == usable_consensus_flavor();
}
+static void
+initialize_dl_status_schedule(void)
+{
+ int i;
+ for (i=0; i < N_CONSENSUS_FLAVORS; ++i)
+ consensus_dl_status[i].schedule = DL_SCHED_CONSENSUS;
+}
+
/** How long will we hang onto a possibly live consensus for which we're
* fetching certs before we check whether there is a better one? */
#define DELAY_WHILE_FETCHING_CERTS (20*60)
@@ -734,6 +742,8 @@ update_consensus_networkstatus_downloads(time_t now)
int i;
const or_options_t *options = get_options();
+ initialize_dl_status_schedule();
+
for (i=0; i < N_CONSENSUS_FLAVORS; ++i) {
/* XXXX need some way to download unknown flavors if we are caching.
*/
const char *resource;
}}}
and we could make it even more complicated still by having a
static int have_initialized_dl_status_schedule = 0;
which we check in update_consensus_networkstatus_downloads(), and call
initialize_dl_status_schedule() if needed and then set the value to 1.
I'd argue for the simple approach, but this is a fine Chief Architect
taste question. :)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11679#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs