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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev