[tor-dev] Timers in Arti?

Michael Rogers michael at briarproject.org
Wed Jan 10 11:26:29 UTC 2024


On 10/01/2024 01:46, Nick Mathewson wrote:
> On Tue, Jan 9, 2024 at 12:58 PM Micah Elizabeth Scott
> <beth at torproject.org> wrote:
>>
>> Ah. If you want to run an onion service you'll need to keep at least a
>> couple circuits open continuously for the introduction points. I'm not
>> sure where you would meaningfully find time to deep sleep in that
>> scenario. There will be ongoing obligations from the wifi/wan and tcp
>> stacks. You need a continuous TCP connection to the guard, and multiple
>> circuits that are not discarded as idle. Incoming traffic on those
>> circuits need to be addressed quickly or clients won't be able to connect.
>>
>> If we were really optimizing for a low power mobile onion service
>> platform we'd have a different way to facilitate introductions without a
>> continuously open set of circuits, but that would also be much more
>> abuse-prone.
>>
>> -beth
> 
> Hm. Do you know, is it possible to make network-driven wakeup events
> relatively prompt?  (Like, within a second or so if a TCP stream we're
> waiting on wakes up). If so, then onion services have a decent chance
> of being made to work.

Fantastic! Yes, the response to network events should be reasonably 
prompt. I'll try to get some measurements.

> As for the original question about timers, it would be good to know if
> the variance between scheduled wakeup and actual wakeup can be
> bounded, or if there's any way to mark a timer as  high-priority vs
> low-priority or something.

This is unfortunately one of those things that's constantly changing on 
Android and varies between manufacturers. In theory we should be able to 
set a periodic alarm that fires within fifteen minutes of the last 
firing, although not all manufacturers honour this.

When the alarm fires the device will come out of suspension and the app 
will be able to grab a temporary wake lock, which we can hold for some 
amount of time (say a minute, for the sake of argument) to let Tor do 
whatever it needs to do.

As far as I know these alarms can only be scheduled via a Java API, so 
Tor would either need to signal to the controller that an alarm was 
needed, or the controller could just assume this whenever hidden 
services were published, and wake the device every fifteen minutes 
without explicitly communicating with Tor about alarms.

Cheers,
Michael

> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x11044FD19FC527CC.asc
Type: application/pgp-keys
Size: 12048 bytes
Desc: OpenPGP public key
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20240110/1c8cffa0/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20240110/1c8cffa0/attachment.sig>


More information about the tor-dev mailing list