Hi Nick, On 30/11/17 12:55, Nick Mathewson wrote: > 2. Improvements to the hibernation model > > To present a consistent interface that applications and > controllers can use to manage power consumption, we make these > enhancements to our hibernation model. > > First, we add three new hibernation states: "IDLE", > "IDLE_UPDATING", "SLEEP", and "SLEEP_UPDATING". > > "IDLE" is like the current "idle" or "no predicted ports" state: > Tor doesn't launch circuits or start any directory activity, but > its listeners are still open. Tor clients can enter the IDLE > state on their own when they are LIVE, but haven't gotten any > client activity for a while. Existing connections and circuits > are not closed. If the Tor instance receives any new connections, > it becomes LIVE. Does receiving a new connection include receiving a rendezvous cell from one of the instance's intro points? If not, do we need a new status message to tell the controller about this, or is there an existing message we can use? > 2.2. Onion service operation > > When a Tor instance that is running an onion service is IDLE, it > does the minimum to try to remain responsive on the onion > service: It keeps its introduction points open if it can. Once a > day, it fetches new directory information and opens new > introduction points. If a client connects to the service, the service will need to build a circuit to the rendezvous point. Does it fetch up-to-date directory information before doing so? If so, there's a delay that may let the client know the service was idle. Is that a problem? Two other possibilities would be for the service to fetch directory information every hour in case a client connects, or to build the circuit using whatever information it has available, which may be up to a day old. Is that a problem? > 3.2. Changing the hibernation state > > We add the following new possible values to the SIGNAL controller > command: > "SLEEP" -- enter the sleep state, after an appropriate > shutdown interval. > > "IDLE" -- enter the idle state > > "SLEEPWALK" -- If in sleep or idle, start probing for > directory information in the sleep-update or idle-update > state respectively. Remain in that state until we've > probed for directory information, or until we're told to > IDLE or SLEEP again, or (if we're idle) until we get client > activity. Has no effect if not in sleep or idle. > > "WAKEUP" -- If in sleep, sleep-update, idle, idle-update, or > shutdown:sleep state, enter the live state. Has no effect > in any other state. How does the controller find out when the Tor instance next needs to fetch directory information (or post a hidden service descriptor) so it can send a SLEEPWALK command at the right time? Or should the controller just send the command periodically, maybe once an hour? Cheers, Michael
Attachment:
0x9FC527CC.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev