Commit 97249c4f authored by teor's avatar teor Committed by Nick Mathewson
Browse files

Make bridge clients download bridge descriptors immediately

The download schedule tells Tor to wait 15 minutes before downloading
bridge descriptors. But 17750 made Tor ignore that and start immediately.
Since we fixed 17750, Tor waits 15 minutes for bridge client bootstrap,
like the schedule says.

This fixes the download schedule to start immediately, and to try each
bridge 3 times in the first 30 seconds. This should make bridge bootstraps
more reliable.

Fixes 23347.
parent 43595253
o Minor bug fixes (bridge client bootstrap):
- Make bridge clients download bridge descriptors immediately.
The bridge schedules were never correct, but we didn't realise until
the fix for 17750 made bridge clients hang for 15 minutes before
bootstrapping.
Fixes bug 23347. Not in any released version of Tor.
......@@ -2475,7 +2475,7 @@ The following options are used for running a testing Tor network.
TestingClientDownloadSchedule 0, 0, 5, 10, 15, 20, 30, 60
TestingServerConsensusDownloadSchedule 0, 0, 5, 10, 15, 20, 30, 60
TestingClientConsensusDownloadSchedule 0, 0, 5, 10, 15, 20, 30, 60
TestingBridgeDownloadSchedule 60, 30, 30, 60
TestingBridgeDownloadSchedule 0, 5, 10, 30, 60
TestingClientMaxIntervalWithoutRequest 5 seconds
TestingDirConnectionMaxStall 30 seconds
TestingConsensusMaxDownloadTries 80
......@@ -2541,7 +2541,8 @@ The following options are used for running a testing Tor network.
[[TestingBridgeDownloadSchedule]] **TestingBridgeDownloadSchedule** __N__,__N__,__...__::
Schedule for when clients should download bridge descriptors. Changing this
requires that **TestingTorNetwork** is set. (Default: 1200, 900, 900, 3600)
requires that **TestingTorNetwork** is set. (Default: 0, 8, 3600, 10800,
25200, 54000, 111600, 262800)
[[TestingClientMaxIntervalWithoutRequest]] **TestingClientMaxIntervalWithoutRequest** __N__ **seconds**|**minutes**::
When directory clients have only a few descriptors to request, they batch
......
......@@ -632,7 +632,9 @@ fetch_bridge_descriptors(const or_options_t *options, time_t now)
continue;
}
/* schedule another fetch as if this one will fail, in case it does */
/* schedule another fetch as if this one will fail, in case it does
* (we can't increment after a failure, because sometimes we use the
* bridge authority, and sometimes we use the bridge direct) */
download_status_failed(&bridge->fetch_status, 0);
can_use_bridge_authority = !tor_digest_is_zero(bridge->identity) &&
......@@ -787,8 +789,13 @@ learned_bridge_descriptor(routerinfo_t *ri, int from_cache)
if (bridge) { /* if we actually want to use this one */
node_t *node;
/* it's here; schedule its re-fetch for a long time from now. */
if (!from_cache)
if (!from_cache) {
download_status_reset(&bridge->fetch_status);
/* We have two quick attempts in the bridge schedule, and then slow
* ones */
download_status_failed(&bridge->fetch_status, 0);
download_status_failed(&bridge->fetch_status, 0);
}
node = node_get_mutable_by_id(ri->cache_info.identity_digest);
tor_assert(node);
......
......@@ -586,7 +586,10 @@ static config_var_t option_vars_[] = {
* blackholed. Clients will try 3 directories simultaneously.
* (Relays never use simultaneous connections.) */
V(ClientBootstrapConsensusMaxInProgressTries, UINT, "3"),
V(TestingBridgeDownloadSchedule, CSV_INTERVAL, "1200, 900, 900, 3600"),
/* The bridge code relies on the third item in this schedule being slow
* (~ 1 consensus interval) */
V(TestingBridgeDownloadSchedule, CSV_INTERVAL,
"0, 8, 3600, 10800, 25200, 54000, 111600, 262800"),
V(TestingClientMaxIntervalWithoutRequest, INTERVAL, "10 minutes"),
V(TestingDirConnectionMaxStall, INTERVAL, "5 minutes"),
V(TestingConsensusMaxDownloadTries, UINT, "8"),
......@@ -648,7 +651,9 @@ static const config_var_t testing_tor_network_defaults[] = {
"15, 20, 30, 60"),
V(TestingClientConsensusDownloadSchedule, CSV_INTERVAL, "0, 0, 5, 10, "
"15, 20, 30, 60"),
V(TestingBridgeDownloadSchedule, CSV_INTERVAL, "60, 30, 30, 60"),
/* The bridge code relies on the third item in this schedule being slow
* (~ 1 consensus interval) */
V(TestingBridgeDownloadSchedule, CSV_INTERVAL, "0, 5, 10, 30, 60"),
V(TestingClientMaxIntervalWithoutRequest, INTERVAL, "5 seconds"),
V(TestingDirConnectionMaxStall, INTERVAL, "30 seconds"),
V(TestingConsensusMaxDownloadTries, UINT, "80"),
......
......@@ -5663,8 +5663,8 @@ download_status_get_initial_delay_from_now(const download_status_t *dls)
* (We find the zeroth element of the download schedule, and set
* next_attempt_at to be the appropriate offset from 'now'. In most
* cases this means setting it to 'now', so the item will be immediately
* downloadable; in the case of bridge descriptors, the zeroth element
* is an hour from now.) */
* downloadable; when using authorities with fallbacks, there is a few seconds'
* delay.) */
void
download_status_reset(download_status_t *dls)
{
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment