Hi Nick,
Thanks very much for the reply. Follow-ups inline below.
On 02/01/2019 21:00, Nick Mathewson wrote:
On Fri, Dec 21, 2018 at 6:34 AM Michael Rogers michael@briarproject.org wrote:
Hi Nick,
Is the guard connection closed when becoming dormant?
No; it times out independently.
That's good news from my point of view, but in that case I think the idea of terminating the pluggable transport process when becoming dormant might need to be reconsidered?
On 13/12/2018 20:56, Nick Mathewson wrote:
DormantTimeoutDisabledByIdleStreams 0|1 If true, then any open client stream (even one not reading or writing) counts as client activity for the purpose of DormantClientTimeout. If false, then only network activity counts. (Default: 1)When this option's set to 0 and Tor becomes dormant, will it close any idle client connections that are still open?
No. By default, it won't go dormant if there are any idle client connections. See DormantTimeoutDisabledByIdleStreams for the option that overrides that behavior.
When DormantTimeoutDisabledByIdleStreams is set to 0, what happens to idle client connections when Tor goes dormant?
Will it close client connections on receiving SIGNAL DORMANT?
No.
If Tor doesn't close client connections when becoming dormant, will it become active again (or send an event that the controller can use to trigger SIGNAL ACTIVE) if there's activity on an open client stream?
No, but that might be a good idea if DormantTimeoutDisabledByIdleStreams is set to 0.
Sorry, do you mean it might be a good idea for Tor to become active again/send an event in that case? Should I open a ticket for this if it looks like we'll need it?
Cheers, Michael