Re: [tor-bugs] #2149 [Tor Client]: new 'extra dormant' mode for people who never use their tor

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#2149: new 'extra dormant' mode for people who never use their tor
---------------------------------+------------------------------------------
 Reporter:  arma                 |          Owner:                    
     Type:  enhancement          |         Status:  new               
 Priority:  major                |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor Client           |        Version:                    
 Keywords:  performance scaling  |         Parent:                    
   Points:                       |   Actualpoints:                    
---------------------------------+------------------------------------------

Comment(by arma):

 Early thoughts:

 - We can probably just call it 'Dormant' in the state file. There isn't
 any other 'dormant' notion there to confuse it with.

 - If we put a timestamp of when Tor was last used in the state file, there
 are privacy concerns. So we should only do that if we have a specific use
 in mind for it. Otherwise I'd suggest we just make it a boolean ("Dormant
 1" or not).

 - That said, when we're not currently dormant, we'll need to track in
 memory a timestamp of when we last did something, so we can notice when it
 gets sufficiently long ago.

 We'll need to define what exactly counts as "something". One thought is a
 static time_t near directory_too_idle_to_fetch_descriptors() that
 remembers the timestamp of when we last transitioned from returning 0 to
 returning 1, and gets zeroed whenever it returns 0.

 Then directory_too_idle_to_fetch_consensuses() would return true if
 directory_too_idle_to_fetch_descriptors() is true and (that timestamp is
 far enough in the past or state->dormant is 1). And whenever it returns,
 it also modifies state->dormant as needed (and when it does, it triggers
 an or_state_mark_dirty() call).

 Then when we read the state file on startup, and state->dormant is 1, so
 long as directory_too_idle_to_fetch_descriptors() is never false,
 directory_too_idle_to_fetch_consensuses() will return true.

 Which means during the startup process, we'll need to check whether
 state->dormant to decide whether predicted_ports_init() should call
 add_predicted_port().

 That still leaves "what parts of the directory fetching code should check
 directory_too_idle_to_fetch_consensuses() before doing their fetch". See
 how we use options->DisableNetwork. But also see how we use
 should_delay_dir_fetches(). I'm not sure yet which approach makes more
 sense here.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2149#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