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

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Thu Oct 11 21:54:18 UTC 2012


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

Comment(by sysrqb):

 I finally had a chance to get back to this..sorry it took so long.

 There were a lot of things I missed earlier, but this patch seems to work.
 I've been running a client for the past day off and on and it transitions
 between the states correctly, thus far. I also decreased the timeout from
 1 day to 2 hours so I didn't have to wait so long.

 This patch is in bug2149-rebased on git://gitweb.evolvesoftware.cc/tor.git
 and I'll attach it, too.

 A few questions that I have:

 1) I have a log at notice for when the client transitions, should this be
 removed due to privacy concerns because it gives a specific date/time this
 state was entered?

 2) The main implementation is in directory_too_idle_to_fetch_descriptors
 and directory_too_idle_to_fetch_consensuses, but the dormant state is only
 for clients. Should these functions be moved out of dirserv and placed
 somewhere else?

 3) This implementation still uses a staged progression towards entering
 dormancy. Will this have subsequent privacy related side-affects that
 should be accounted for?

 For arma's last point

 >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().

 If we wait to call predicted_ports_init after we parse the state file then
 we end up asserting when we parse the bandwidth history data. As a
 workaround, after rep_hist_load_state is called all the predicted ports
 are removed which then retains the dormant state. Is this too much of a
 hack?

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


More information about the tor-bugs mailing list