[tor-bugs] #2355 [Tor Bridge]: change the meaning of UseBridges

[Tor Bug Tracker & Wiki]

#2355: change the meaning of UseBridges
---------------------------------+------------------------------------------
    Reporter:  anonym            |        Type:  enhancement
      Status:  needs_review      |    Priority:  minor      
   Milestone:  Tor: unspecified  |   Component:  Tor Bridge 
     Version:                    |    Keywords:             
      Parent:                    |      Points:             
Actualpoints:                    |  
---------------------------------+------------------------------------------

Comment(by anonym):

 Replying to [comment:9 nickm]:
 > In the new check, we give the warning if UseBridges is 0.  But
 previously, we gave it if it was nonzero.  Maybe a strcmp mistake?

 Err, yeah I screwed up. Will fix it in next patch.


 > I'm not sure about launching the bridge descriptor fetch from config.c ;
 the more stuff we launch from configuration parsing, the more spaghettiish
 our code has gotten historically. We already retry launching downloads
 every 10 or 60 seconds from main.c; perhaps what we need is a function to
 tell main that it needs to retry downloads right away.

 Do you think this any of these approaches are viable?

 1. Make run_scheduled_events()'s static variable
 time_to_try_getting_descriptors global, and add a function
 schedule_imminent_descriptor_refetch() which simply zeros
 time_to_try_getting_descriptors and hence a bridge descriptor refetch is
 done within a second or so. schedule_imminent_descriptor_refetch() is then
 called instead of fetch_bridge_descriptors() in config.c.

 2. Alternatively (different style but equivalent behaviour), if we don't
 want to make time_to_try_getting_descriptors global (which might be
 undesirable as it makes it stand out from all the other time_to_*
 variables), what about adding a global variable forced_descriptor_refetch
 and change the if-statment in main.c:915 to

 {{{
 #!c
   if (time_to_try_getting_descriptors < now ||
       forced_descriptor_refetch) {
     forced_descriptor_refetch = 0;
     /* ... the rest is unchanged ... */
   }
 }}}

 schedule_imminent_descriptor_refetch() would then simply set
 forced_descriptor_refetch to 1.


 > The any_bridge_descriptors_known() logic is fragile in depending on
 have_bridge_descriptors anc choose_random_entry; instead IMO it should
 probably just iterate through bridge_list and see whether we have a
 descriptor for any member.

 Say I somehow implement the function "routerinfo_t *
 get_router_by_bridgeinfo()" (or have I missed any other practical function
 which will do the trick?), which is the opposite of
 get_configured_bridge_by_routerinfo(), and then change
 any_bridge_descriptors_known() to the below, would that be ok?

 {{{
 #!c
 int
 any_bridge_descriptors_known(void)
 {
   tor_assert(get_options()->EffectiveUseBridges);

   SMARTLIST_FOREACH_BEGIN(bridge_list, bridge_info_t *, bridge)
     {
       if (get_router_by_bridgeinfo())
         return 1;
     }
   SMARTLIST_FOREACH_END(bridge);

   return 0;
 }
 }}}

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