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 sysrqb):

 (I apologize, in advance, if I missed any past discussions relating to
 this
 topic while I was researching it.)

 Memory Across Boot:
   We can make a one-off addition to the values stored in the state file
   by adding another field called ExtraDormantState that will store
   either the timestamp of the last wakeup or a bit field* indicating
   that the client should resume in a dormant state. I'm not sure which
   value will be more useful. The presence, or lack of, a value (whether
   as a timestamp or a bitfield > 0) can indicate the dormant state,
   but with the timestamp we'll know approximately the last time the client
   was used. This way we have the option of behaving differently depending
   on the last time it was used. Should the client still remain in a
 dormant
   state if it was last used a month ago (or more)? On the other hand, the
   bit field can have a bit for the dormant state and another for an
   "extra dormant" state. Is there any additional information for which we
   might want a flag?


   *The further I got into writing this and the more I thought about using
   it as a bitfield, the less it made sense, but I'll still leave it as an
   option for discussion.

 Internal Storage:
   Following from the above, internally ExtraDormantState can be appended
   to or_state_t as time_t and be use for the timestamp and a bitfield,
   depending on what we decide.

   With that being said, it's probably easiest to leave the mutation of
 this
   value in the file to run_scheduled_events. I assume config dump will
 need
   to be adjusted to support this new value.

 Enter Extra Dormant Mode:
   1) Setting ExtraDormantState:
        After a lot of (misguided) backtracing, and with some help from
        nickm et al., I realized this shouldn't require much additional
        overhead. I think we can piggyback on the functions that are
 already
        used to check if the client is currently dormant if we modify
        directory_too_idle_to_fetch_descriptors so that the logical AND
        determines the value of ExtraDormantState. The first time
        directory_too_idle_to_fetch_descriptors is called and the ANDing
        is != 0, we check the current value of ExtraDormantState
        (which should be 0) and set it to the current time(NULL) and the
        function will return true. All subsequent calls to the function
        will test if ExtraDormantState was set longer than 1 day ago.
        Unless this is true, the function simply returns true. Once this
        condition is true, depending on what we want to do with it,
        ExtraDormantState can either remain a time value or become a
 bitfield.
        directory_too_idle_to_fetch_descriptors will continue to return the
        correct value.

   2) Stop Fetching Consensus:
        To transition the process of fetching a new consensus into a
 dormant
        state, as far as I can tell we can simply call
        update_consensus_networkstatus_fetch_time with a parameter of a
 future
        time, be it a day in the future or more. This will prevent the
 client
        from downloading a consensus until after the specified time. Let me
        know if there is another path that I missed that will still
 successfully
        fetch updates.

 Exit Dormant Mode:
   If ExtraDormantState is set but the condition in
   directory_too_idle_to_fetch_descriptors fails, then unset
 ExtraDormantState
   and set each index of time_to_download_next_consensus to the current
 time.

 Reenter (Extra) Dormant State After Reboot:
   When options_act is called and the config is reloaded we can call
   update_consensus_networkstatus_fetch_time as above hibernate_go_dormant
   which will ensure any circuits that have been built will be destroyed.
 I'm
   not sure the latter call is necessary, though, depending on where in
   options_act we check if ExtraDormantState has a value.



 All feedback is welcome. If you think of a better name than
 ExtraDormantState,
 I'm all ears.

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