[tor-bugs] #11679 [Tor]: Download status for consensus scheduled as generic

[Tor Bug Tracker & Wiki]

#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