Increase client idle and connection timeouts to reduce network load
These changes were introduced in d5a151a in 0.3.1.1.
Maybe we should:
- revert the changes, or increase the values
- make consensus parameters for them
+/** If we haven't yet decided on a good timeout value for circuit
+ * building, we close idle circuits aggressively so we can get more
+ * data points. */
+#define IDLE_TIMEOUT_WHILE_LEARNING (1*60)-/** If we haven't yet decided on a good timeout value for circuit
- * building, we close idles circuits aggressively so we can get more
- * data points. */
-#define IDLE_TIMEOUT_WHILE_LEARNING (10*60)+#define CONNTIMEOUT_CLIENTS_BASE 180 // 3 to 4.5 min
+ timeout = CONNTIMEOUT_CLIENTS_BASE
+ + crypto_rand_int(CONNTIMEOUT_CLIENTS_BASE/2);Activity
changed milestone to %Tor: 0.3.3.x-final
added 025-backport-maybe 029-backport 031-backport 032-backport 033-must component::core tor/tor dos-resistance milestone::Tor: 0.3.3.x-final owner::mikeperry points::1 priority::high resolution::implemented review-group-32 reviewer::nickm severity::normal status::closed tor-client type::defect version::tor 0.3.1.1-alpha labels
Woah. Yeah. So, right now we close circuits 60 seconds after making them, even if we opt to make testing circuits much less frequently? That is, when we have any predicted ports, we're going to end up churning through all our circuits every minute, anyway? That's crummy. It seems like the idle-timeout-while-learning should be a function of the cbttestfreq?
Replying to arma:
Woah. Yeah. So, right now we close circuits 60 seconds after making them, even if we opt to make testing circuits much less frequently? That is, when we have any predicted ports, we're going to end up churning through all our circuits every minute, anyway? That's crummy. It seems like the idle-timeout-while-learning should be a function of the cbttestfreq?
Yes, I think we need to make it configurable, and possibly backport the change. (But not to 0.2.8, because it's not supported as of 1 January 2018.)
I'm not sure what to do about the regular connection timeout. We should check what it was before, and maybe see if it needs to be longer.
Trac:
Keywords: N/A deleted, 029-backport, 032-backport, 031-backport, 025-backport-maybe addedTrac:
Parent: #24716 (moved) to N/A
This also came up in #24228 (moved), where we found that Tor was creating a new circuit about every 6 seconds with this timeout.
The goal is to learn a circuit build timeout within 30 minutes, so that unused orconn connections aren't padded by the netflow padidng for too long while we learn this timeout (which wastes bandwidth for clients that want less padding). In #24228 (moved), it looked like we may actually learn it within 10. So we could make this default 3X slower.
I will look at this and work on a patch to change the default and make it a consensus param.
Trac:
Status: new to assigned
Owner: N/A to mikeperry
The code looks safe enough to me, and the defaults don't seem unreasonable.
My only worry would be that maybe networkstatus_get_param() might get called too often, but I don't think that will be the case in these contexts.
Merging to master!
Trac:
Resolution: N/A to implemented
Status: needs_review to closedmoved to tpo/core/tor#24769 (closed)
