On Wed, Nov 21, 2018 at 5:10 PM Michael Rogers michael@briarproject.org wrote:
On 20/11/2018 19:28, Nick Mathewson wrote:
Hi! I don't know if this will be useful or not, but I'm wondering if you've seen this ticket: https://trac.torproject.org/projects/tor/ticket/28335
The goal of this branch is to create a "dormant mode" where Tor does not run any but the most delay- and rescheduling-tolerant of its periodic events. Tor enters this mode if a controller tells it to, or if (as a client) it passes long enough without user activity. When in dormant mode, it doesn't disconnect from the network, and it will wake up again if the controller tells it to, or it receives a new client connection.
Would this be at all helpful for any of this?
This looks really useful for mobile clients, thank you!
Glad to hear it -- it's now merged into Tor's master branch.
The comments on the pull request (https://github.com/torproject/tor/pull/502) suggest that Tor won't enter dormant mode if it's running a hidden service. Are there any plans to support that in future?
I want to support this for hidden services. Here's the ticket to track that: https://trac.torproject.org/projects/tor/ticket/28424
This is going to be harder than the other cases, though, so we decided to defer it for now and see if we have time later.
One of the comments mentions a break-even point for consensus diffs, where it costs less bandwidth to fetch a fresh consensus than all the diffs from the last consensus you know about. Are diffs likely to remain available up to the break-even point, or are there times when it would be cheaper to use diffs, but you have to fetch a fresh consensus because some of the diffs have expired?
This shouldn't be a problem: directory caches will (by default) keep diffs slightly beyond the break-even point.
(I think. I haven't measured this in a while.)
Essentially I'm wondering whether we'd want to wake Tor from dormant mode occasionally to fetch diffs before they expire, so we can avoid fetching a fresh consensus later.