A variety of timers are needed on the relay side; on the client side
though, aren't you mostly limited by the requirement of keeping a TCP
connection open?
Really deep sleep would involve avoiding any protocol-level keepalives
as well as TCP keepalives. This seems a lot like just shutting down the
connection to the guard when sleeping; but of course that's got a
latency penalty and it's visible to anyone who can see network activity.
-beth
On 1/4/24 04:48, Michael Rogers wrote:
Hi,
If I understand right, the C implementation of Tor has various state
machines that are driven by local libevent timers as well as events
from the network. For example, when building a circuit, if there
hasn't been any progress for a certain amount of time then a timer
fires to handle the timeout.
When running Tor on Android, we need to prevent the OS from suspending
so that these timers fire when they're supposed to. This uses a lot of
battery, because normally the OS would spend most of its time
suspended. Unlike a laptop, an Android device with its screen turned
off is constantly dipping in an out of suspension, and a lot of the
platform's power optimisations are aimed at batching whatever work
needs to be done so that the periods of suspension can be longer.
If we allowed the OS to suspend then the timers would fire with
arbitrary delays, and I don't really know what impact that would have:
I'd speculate that there might be connectivity problems (eg dead
circuits not being detected and replaced) and/or network-visible
changes in the behaviour of circuits that could affect anonymity.
So I've had a longstanding but not-very-hopeful request that maybe
Tor's reliance on timers could be reduced, or at least clarified, so
that we could either allow the OS to suspend without breaking
anything, or at least know what was likely to break.
And basically I'd just like to renew that request for Arti. Could
anyone give me an overview of how these local timers are handled in
Arti, or any information about what's likely to happen if the timers
are arbitrarily delayed?
Thanks,
Michael
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
