On Wed, Nov 21, 2018 at 5:10 PM Michael Rogers <mich...@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. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
