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

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri May 2 04:57:53 UTC 2014


#11679: Download status for consensus scheduled as generic
-------------------------+---------------------
 Reporter:  cypherpunks  |          Owner:
     Type:  defect       |         Status:  new
 Priority:  normal       |      Milestone:
Component:  Tor          |        Version:
 Keywords:               |  Actual Points:
Parent ID:               |         Points:
-------------------------+---------------------
 Currently download status scheduled as generic (DL_SCHED_GENERIC = 0);
 {{{
 /** Download status for the current consensus networkstatus. */
 static download_status_t consensus_dl_status[N_CONSENSUS_FLAVORS];
 }}}
 Before
 [https://gitweb.torproject.org/tor.git/commitdiff/851a980065e6b2df8d7cb35a22d0675b8918214b
 implementing] of consensus for md it was DL_SCHED_CONSENSUS:
 {{{
 static download_status_t consensus_dl_status = { 0, 0, DL_SCHED_CONSENSUS
 };
 }}}

 That means unfriendly schedule for client with fragile network connection.
 {{{
 /** Schedule for when clients should download things in general. */
 static const int client_dl_schedule[] = {
   0, 0, 60, 60*5, 60*10, INT_MAX
 };
 }}}
 vs.
 {{{
 /** 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
 };
 }}}
 Tor will reset download status by `networkstatus_reset_download_failures`
 once a hour so client will have a chance to retry, so no unresolved state
 actually.

 Is it worth to initialize download status for consensus schedule? Or to
 rename schedule if planned to use it for certs only?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11679>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list