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! 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? 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? 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. Cheers, Michael
Attachment:
0x11044FD19FC527CC.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