Hi all,
It's great to see that some children of #25500 have already been released in the 0.3.4 series. Can I ask about the longer-term plan for this work, and whether #23289 (or something similar) is part of it?
The context for my question is that we're trying to reduce Briar's power consumption. Until now we've held a wake lock to keep the CPU awake all the time, but normally an Android device would go into "deep sleep" (which corresponds to suspend on other platforms) whenever the screen's turned off, apart from brief wakeups for alarms and incoming network traffic. Holding a permanent wake lock has a big impact on battery life.
Most of our background work can be handled with alarms, but we still need to hold a wake lock whenever Tor's running because libevent timers don't fire when the CPU's asleep, and Tor gets a nasty surprise when it wakes up and all its timers are late.
It looks like most of the work has been moved off the one-second periodic timer, which is great, but I assume that work's now being scheduled by other means and still needs to be done punctually, which we can't currently guarantee on Android without a wake lock.
As far as I can tell, getting rid of the wake lock requires one of the following:
1. Tor becomes extremely tolerant of unannounced CPU sleeps. I don't know enough about Tor's software architecture to know how feasible this is, but my starting assumption would be that adapting a network-oriented codebase that's been written for a world where time passes at a steady rate and timers fire punctually, to a world where time passes in fits and starts and timers fire eventually, would be a nightmare.
2. Tor tolerates unannounced CPU sleeps within some limits. This is similar to the previous scenario, except the controller sets a regular alarm to ensure the CPU never sleeps for too long, and libevent ensures that when the CPU wakes up, any overdue timers fire immediately (maybe this happens already?). Again, I'd assume that adapting Tor to this environment would be a huge task, but at least there'd be limits on the insanity.
One of the difficulties with this option is that under some conditions, the controller can only schedule one alarm every 15 minutes. Traffic from the guard would also wake the CPU, so if we could ask the guard for regular keepalives, we might be able to promise that the CPU will wake once every keepalive interval, unless the guard connection's lost, in which case it will wake once every 15 minutes. But keepalives from the guard would require a protocol change, which would take time to roll out, and would let the guard know (if it doesn't already) that the client's running on Android.
3. Tor knows when it next needs to wake up, and relies on the controller to wake it. This requires a way for the controller to query Tor, and Tor to query libevent, for the next timer that needs to fire (perhaps from some subset of timers that must fire punctually even if the CPU's asleep). Libevent doesn't need to detect overdue timers by itself, but it needs to provide a hook for re-checking whether timers are overdue. The delay until the next timer needs to be at least a few seconds long, at least some of the time, for sleeping to be worthwhile. And finally, even if all those conditions are met, we run up against the 15-minute limit on alarms again.
None of these options are good. I'm not even sure if the first and third are feasible. But I don't know enough about Tor or libevent to be sure. If you do, I'd be really grateful for your help in understanding the constraints here.
Cheers, Michael
On 6 Nov 2018, at 03:38, Michael Rogers michael@briarproject.org wrote:
One of the difficulties with this option is that under some conditions, the controller can only schedule one alarm every 15 minutes. Traffic from the guard would also wake the CPU, so if we could ask the guard for regular keepalives, we might be able to promise that the CPU will wake once every keepalive interval, unless the guard connection's lost, in which case it will wake once every 15 minutes. But keepalives from the guard would require a protocol change, which would take time to roll out, and would let the guard know (if it doesn't already) that the client's running on Android.
Tor implemented netflow padding in 0.3.1.1-alpha (May 2017): https://gitweb.torproject.org/torspec.git/tree/padding-spec.txt
Connection padding may act like a keepalive, we should consider this use case as we improve our padding designs.
T
On Tue, Nov 06, 2018 at 11:38:33AM +1000, teor wrote:
so if we could ask the guard for regular keepalives, we might be able to promise that the CPU will wake once every keepalive interval, unless the guard connection's lost, in which case it will wake once every 15 minutes. But keepalives from the guard would require a protocol change, which would take time to roll out, and would let the guard know (if it doesn't already) that the client's running on Android.
Tor implemented netflow padding in 0.3.1.1-alpha (May 2017): https://gitweb.torproject.org/torspec.git/tree/padding-spec.txt
Connection padding may act like a keepalive, we should consider this use case as we improve our padding designs.
Relays already send a keepalive (padding) cell every 5 minutes: see the KeepalivePeriod config option. That's separate from any of the new netflow padding. Clients send them too.
The netflow padding is more interesting for the Briar case, since it comes way way more often than keepalives: so if you're trying for deep sleep but you wake up for network activity every several seconds, you'll probably end up sad.
--Roger
On 06/11/2018 01:58, Roger Dingledine wrote:
On Tue, Nov 06, 2018 at 11:38:33AM +1000, teor wrote:
so if we could ask the guard for regular keepalives, we might be able to promise that the CPU will wake once every keepalive interval, unless the guard connection's lost, in which case it will wake once every 15 minutes. But keepalives from the guard would require a protocol change, which would take time to roll out, and would let the guard know (if it doesn't already) that the client's running on Android.
Tor implemented netflow padding in 0.3.1.1-alpha (May 2017): https://gitweb.torproject.org/torspec.git/tree/padding-spec.txt
Connection padding may act like a keepalive, we should consider this use case as we improve our padding designs.
Relays already send a keepalive (padding) cell every 5 minutes: see the KeepalivePeriod config option. That's separate from any of the new netflow padding. Clients send them too.
Ah, thanks! I didn't realise keepalives were sent from relays to clients as well as vice versa.
That gives us a max sleep of 5 minutes when a guard connection's open and 15 minutes when it's not, which is a great improvement.
Would it have much impact on the network to reduce the default keepalive interval to, say, one minute?
The netflow padding is more interesting for the Briar case, since it comes way way more often than keepalives: so if you're trying for deep sleep but you wake up for network activity every several seconds, you'll probably end up sad.
Unfortunately we've disabled netflow padding due to bandwidth and battery usage.
Cheers, Michael
On 7 Nov 2018, at 04:10, Michael Rogers michael@briarproject.org wrote:
On 06/11/2018 01:58, Roger Dingledine wrote:
On Tue, Nov 06, 2018 at 11:38:33AM +1000, teor wrote:
so if we could ask the guard for regular keepalives, we might be able to promise that the CPU will wake once every keepalive interval, unless the guard connection's lost, in which case it will wake once every 15 minutes. But keepalives from the guard would require a protocol change, which would take time to roll out, and would let the guard know (if it doesn't already) that the client's running on Android.
Tor implemented netflow padding in 0.3.1.1-alpha (May 2017): https://gitweb.torproject.org/torspec.git/tree/padding-spec.txt
Connection padding may act like a keepalive, we should consider this use case as we improve our padding designs.
Relays already send a keepalive (padding) cell every 5 minutes: see the KeepalivePeriod config option. That's separate from any of the new netflow padding. Clients send them too.
Ah, thanks! I didn't realise keepalives were sent from relays to clients as well as vice versa.
That gives us a max sleep of 5 minutes when a guard connection's open and 15 minutes when it's not, which is a great improvement.
Would it have much impact on the network to reduce the default keepalive interval to, say, one minute?
It's doable, but it would take a while to roll out to all relays. And it seems like a strange solution to a platform-specific problem.
We might also have to be careful, because a multiple of the keepalive interval is used to close connections without any circuits.
The netflow padding is more interesting for the Briar case, since it comes way way more often than keepalives: so if you're trying for deep sleep but you wake up for network activity every several seconds, you'll probably end up sad.
Unfortunately we've disabled netflow padding due to bandwidth and battery usage.
Even with ReducedConnectionPadding?
T
On 07/11/2018 09:04, teor wrote:
On 7 Nov 2018, at 04:10, Michael Rogers michael@briarproject.org wrote:
On 06/11/2018 01:58, Roger Dingledine wrote:
On Tue, Nov 06, 2018 at 11:38:33AM +1000, teor wrote:
so if we could ask the guard for regular keepalives, we might be able to promise that the CPU will wake once every keepalive interval, unless the guard connection's lost, in which case it will wake once every 15 minutes. But keepalives from the guard would require a protocol change, which would take time to roll out, and would let the guard know (if it doesn't already) that the client's running on Android.
Tor implemented netflow padding in 0.3.1.1-alpha (May 2017): https://gitweb.torproject.org/torspec.git/tree/padding-spec.txt
Connection padding may act like a keepalive, we should consider this use case as we improve our padding designs.
Relays already send a keepalive (padding) cell every 5 minutes: see the KeepalivePeriod config option. That's separate from any of the new netflow padding. Clients send them too.
Ah, thanks! I didn't realise keepalives were sent from relays to clients as well as vice versa.
That gives us a max sleep of 5 minutes when a guard connection's open and 15 minutes when it's not, which is a great improvement.
Would it have much impact on the network to reduce the default keepalive interval to, say, one minute?
It's doable, but it would take a while to roll out to all relays. And it seems like a strange solution to a platform-specific problem.
You're right, it's not pretty. Using this hack on the client is bad enough, and asking the network to support the hack is worse.
On the other hand, Android has a lot of users, and battery-friendly hidden services on mobile devices would be a great building block for privacy tools (assuming we could overcome the other obstacles too).
We might also have to be careful, because a multiple of the keepalive interval is used to close connections without any circuits.
The netflow padding is more interesting for the Briar case, since it comes way way more often than keepalives: so if you're trying for deep sleep but you wake up for network activity every several seconds, you'll probably end up sad.
Unfortunately we've disabled netflow padding due to bandwidth and battery usage.
Even with ReducedConnectionPadding?
Interestingly we found that ReducedConnectionPadding didn't make much of a difference for our use case, perhaps because the hidden service keeps the OR connection open. If I understand right, closing the connection is one of the ways ReducedConnectionPadding would normally save bandwidth.
I ran some experiments over the weekend to double-check this. Here's the traffic per hour for Tor 0.3.4.8 running a hidden service with no incoming or outgoing connections, averaged over 12 hours:
Default: sent 415 kB (stdev 90 k), received 434 kB (stdev 114 k) No padding: sent 176 kB (stdev 74 k), received 232 kB (stdev 182 k) Reduced padding: sent 418 kB (stdev 87 k), received 312 kB (stdev 183 k)
Cheers, Michael
On Mon, Nov 5, 2018 at 12:38 PM Michael Rogers michael@briarproject.org wrote:
Hi all,
It's great to see that some children of #25500 have already been released in the 0.3.4 series. Can I ask about the longer-term plan for this work, and whether #23289 (or something similar) is part of it?
The context for my question is that we're trying to reduce Briar's power consumption. Until now we've held a wake lock to keep the CPU awake all the time, but normally an Android device would go into "deep sleep" (which corresponds to suspend on other platforms) whenever the screen's turned off, apart from brief wakeups for alarms and incoming network traffic. Holding a permanent wake lock has a big impact on battery life.
Most of our background work can be handled with alarms, but we still need to hold a wake lock whenever Tor's running because libevent timers don't fire when the CPU's asleep, and Tor gets a nasty surprise when it wakes up and all its timers are late.
It looks like most of the work has been moved off the one-second periodic timer, which is great, but I assume that work's now being scheduled by other means and still needs to be done punctually, which we can't currently guarantee on Android without a wake lock.
As far as I can tell, getting rid of the wake lock requires one of the following:
- Tor becomes extremely tolerant of unannounced CPU sleeps. I don't
know enough about Tor's software architecture to know how feasible this is, but my starting assumption would be that adapting a network-oriented codebase that's been written for a world where time passes at a steady rate and timers fire punctually, to a world where time passes in fits and starts and timers fire eventually, would be a nightmare.
- Tor tolerates unannounced CPU sleeps within some limits. This is
similar to the previous scenario, except the controller sets a regular alarm to ensure the CPU never sleeps for too long, and libevent ensures that when the CPU wakes up, any overdue timers fire immediately (maybe this happens already?). Again, I'd assume that adapting Tor to this environment would be a huge task, but at least there'd be limits on the insanity.
One of the difficulties with this option is that under some conditions, the controller can only schedule one alarm every 15 minutes. Traffic from the guard would also wake the CPU, so if we could ask the guard for regular keepalives, we might be able to promise that the CPU will wake once every keepalive interval, unless the guard connection's lost, in which case it will wake once every 15 minutes. But keepalives from the guard would require a protocol change, which would take time to roll out, and would let the guard know (if it doesn't already) that the client's running on Android.
- Tor knows when it next needs to wake up, and relies on the controller
to wake it. This requires a way for the controller to query Tor, and Tor to query libevent, for the next timer that needs to fire (perhaps from some subset of timers that must fire punctually even if the CPU's asleep). Libevent doesn't need to detect overdue timers by itself, but it needs to provide a hook for re-checking whether timers are overdue. The delay until the next timer needs to be at least a few seconds long, at least some of the time, for sleeping to be worthwhile. And finally, even if all those conditions are met, we run up against the 15-minute limit on alarms again.
None of these options are good. I'm not even sure if the first and third are feasible. But I don't know enough about Tor or libevent to be sure. If you do, I'd be really grateful for your help in understanding the constraints here.
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?
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
On Wed, Nov 21, 2018 at 5:10 PM Michael Rogers michael@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.
On 27 Nov 2018, at 07:46, Nick Mathewson nickm@alum.mit.edu wrote:
On Wed, Nov 21, 2018 at 5:10 PM Michael Rogers michael@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.
The comments on the pull request (https://github.com/torproject/tor/pull/502) ...
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.)
We measured the number of cached consensuses after a collector outage in August:
https://lists.torproject.org/pipermail/tor-relays/2018-August/015850.html
Some relays had ~16 consensuses, others had ~24 or ~48.
If a relay is using lzma, zstd, and gzip compression, then it will only store about 16 past consensuses: https://github.com/torproject/tor/blob/672e26cad837e368dfe39d53546b85afd69ad...
If my sums are correct, that is: 128 files / 2 consensus flavours / (1 consensus + 3 compressed diffs) = 16 consensuses
Should we increase cache_max_num to 196? Should we increase cache_max_num when the sandbox isn't being used?
T
On 26/11/2018 21:46, Nick Mathewson wrote:
On Wed, Nov 21, 2018 at 5:10 PM Michael Rogers michael@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.
Fantastic.
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.
Makes sense. I added some simulation results to the ticket that support dgoulet's assessment that the descriptor may become unreachable within a few hours if not republished, due to HSDir churn.
However, even one hour in dormant mode would be a huge improvement over what we can do now. What are the other blockers for running a hidden service in dormant mode?
Would it be possible/easier to keep an ordinary client circuit alive in dormant mode? That would allow us to keep a connection to a mailbox* while dormant.
Cheers, Michael
* Briar term for a device connected to power and internet that runs a hidden service on behalf of the owner's main device.
Nick Mathewson:
On Mon, Nov 5, 2018 at 12:38 PM Michael Rogers michael@briarproject.org wrote:
Hi all,
It's great to see that some children of #25500 have already been released in the 0.3.4 series. Can I ask about the longer-term plan for this work, and whether #23289 (or something similar) is part of it?
The context for my question is that we're trying to reduce Briar's power consumption. Until now we've held a wake lock to keep the CPU awake all the time, but normally an Android device would go into "deep sleep" (which corresponds to suspend on other platforms) whenever the screen's turned off, apart from brief wakeups for alarms and incoming network traffic. Holding a permanent wake lock has a big impact on battery life.
Most of our background work can be handled with alarms, but we still need to hold a wake lock whenever Tor's running because libevent timers don't fire when the CPU's asleep, and Tor gets a nasty surprise when it wakes up and all its timers are late.
It looks like most of the work has been moved off the one-second periodic timer, which is great, but I assume that work's now being scheduled by other means and still needs to be done punctually, which we can't currently guarantee on Android without a wake lock.
As far as I can tell, getting rid of the wake lock requires one of the following:
- Tor becomes extremely tolerant of unannounced CPU sleeps. I don't
know enough about Tor's software architecture to know how feasible this is, but my starting assumption would be that adapting a network-oriented codebase that's been written for a world where time passes at a steady rate and timers fire punctually, to a world where time passes in fits and starts and timers fire eventually, would be a nightmare.
- Tor tolerates unannounced CPU sleeps within some limits. This is
similar to the previous scenario, except the controller sets a regular alarm to ensure the CPU never sleeps for too long, and libevent ensures that when the CPU wakes up, any overdue timers fire immediately (maybe this happens already?). Again, I'd assume that adapting Tor to this environment would be a huge task, but at least there'd be limits on the insanity.
One of the difficulties with this option is that under some conditions, the controller can only schedule one alarm every 15 minutes. Traffic from the guard would also wake the CPU, so if we could ask the guard for regular keepalives, we might be able to promise that the CPU will wake once every keepalive interval, unless the guard connection's lost, in which case it will wake once every 15 minutes. But keepalives from the guard would require a protocol change, which would take time to roll out, and would let the guard know (if it doesn't already) that the client's running on Android.
- Tor knows when it next needs to wake up, and relies on the controller
to wake it. This requires a way for the controller to query Tor, and Tor to query libevent, for the next timer that needs to fire (perhaps from some subset of timers that must fire punctually even if the CPU's asleep). Libevent doesn't need to detect overdue timers by itself, but it needs to provide a hook for re-checking whether timers are overdue. The delay until the next timer needs to be at least a few seconds long, at least some of the time, for sleeping to be worthwhile. And finally, even if all those conditions are met, we run up against the 15-minute limit on alarms again.
None of these options are good. I'm not even sure if the first and third are feasible. But I don't know enough about Tor or libevent to be sure. If you do, I'd be really grateful for your help in understanding the constraints here.
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?
I think dormant mode sounds like it goes a long way towards making Tor operate the way that Android and iOS apps are expected to. The last missing piece towards making tor daemon behave like native service on those platforms would be a method to make the dormant mode survive being killed and restarted.
In Android and iOS, there isn't really a "dormant" or "sleeping" state for processes like there is for desktop processes. The idea in mobile is that the process serializes any required state out, and is then killed entirely. That process might then be restarted within a minute, 5 minutes, a day, a week depending on what the user does. iOS is especially strict with this.
So if this dormant mode would survive being killed and restarted, then we'll see big gains in battery usage. Usually, the best way to achieve this is to always write required state out to disk as it changes, e.g. to the built-in sqlite. That is because Android/iOS will try to give a process warning before killing it, but they do not _guarantee_ that any warning will be given. It is fully valid and indeed common for a process to be killed without any warning whatsoever.
.hc
On Tue, Nov 27, 2018 at 8:04 AM Hans-Christoph Steiner hans@guardianproject.info wrote: [...]
I think dormant mode sounds like it goes a long way towards making Tor operate the way that Android and iOS apps are expected to. The last missing piece towards making tor daemon behave like native service on those platforms would be a method to make the dormant mode survive being killed and restarted.
FWIW, it looks like Roger opened a ticket for this: see https://trac.torproject.org/projects/tor/ticket/28624 . I bet we could squeeze it in before the feature freeze for 0.4.0.x.
cheers,
On 11/27/18 3:01 PM, Nick Mathewson wrote:
I bet we could squeeze it in before the feature freeze for 0.4.0.x.
On Android you still can (who knows for how long) mark your app as running in the foreground. This prevents it from getting killed and is what Briar is doing. It would therefore benefit more from #28424 going into 0.4.x than from #28624.
Kind Regards, Torsten
-
Hans-Christoph Steiner -
Michael Rogers -
Nick Mathewson -
Roger Dingledine -
teor -
Torsten Grote