summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2016-11-07 11:01:31 -0500
committerNick Mathewson <nickm@torproject.org>2016-11-07 11:01:31 -0500
commit293aca9929cfa0205d16899191c16855a607ac77 (patch)
tree9ae00a8d7068440b9f157297b031ecf56f27fb9e
parente4b793fe41fc09cc1f7753cfe90b74095a49a34f (diff)
parente51f105c417aff1840126fddd11875fec84c86a9 (diff)
downloadtor-293aca9929cfa0205d16899191c16855a607ac77.tar.gz
tor-293aca9929cfa0205d16899191c16855a607ac77.zip
Merge branch 'bug20534_029_squashed' into maint-0.2.9
-rw-r--r--changes/bug205346
-rw-r--r--changes/bug205936
-rw-r--r--src/or/config.c4
-rw-r--r--src/or/directory.c28
4 files changed, 30 insertions, 14 deletions
diff --git a/changes/bug20534 b/changes/bug20534
index 1ffa1f32e9..49db433a01 100644
--- a/changes/bug20534
+++ b/changes/bug20534
@@ -2,5 +2,7 @@
- Remove the maximum delay on exponential-backoff scheduling.
Since we now allow an infinite number of failures (see ticket
20536), we must now allow the time to grow longer on each failure.
- Fixes bug 20534; bugfix on 0.2.9.1-alpha.
-
+ Fixes part of bug 20534; bugfix on 0.2.9.1-alpha.
+ - Use initial delays and decrements in download scheduling closer to
+ those from 0.2.8. Fixes another part of bug 20534; bugfix on
+ 0.2.9.1-alpha.
diff --git a/changes/bug20593 b/changes/bug20593
new file mode 100644
index 0000000000..e9f54d317a
--- /dev/null
+++ b/changes/bug20593
@@ -0,0 +1,6 @@
+ o Minor bugfixes (client directory scheduling):
+ - Treat "relay too busy to answer request" as a failed request and a
+ reason to back off on our retry frequency. This is safe now that
+ exponential backups retry indefinitely, and avoids a bug where we would
+ reset our download schedule erroneously.
+ Fixes bug 20593; bugfix on 0.2.9.1-alpha.
diff --git a/src/or/config.c b/src/or/config.c
index 08c576e3d4..9ad5d63f8d 100644
--- a/src/or/config.c
+++ b/src/or/config.c
@@ -501,7 +501,7 @@ static config_var_t option_vars_[] = {
* When clients have authorities and fallbacks available, they use these
* schedules: (we stagger the times to avoid thundering herds) */
V(ClientBootstrapConsensusAuthorityDownloadSchedule, CSV_INTERVAL,
- "10, 11, 3600, 10800, 25200, 54000, 111600, 262800" /* 3 days + 1 hour */),
+ "6, 11, 3600, 10800, 25200, 54000, 111600, 262800" /* 3 days + 1 hour */),
V(ClientBootstrapConsensusFallbackDownloadSchedule, CSV_INTERVAL,
"0, 1, 4, 11, 3600, 10800, 25200, 54000, 111600, 262800"),
/* When clients only have authorities available, they use this schedule: */
@@ -512,7 +512,7 @@ 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, "3600, 900, 900, 3600"),
+ V(TestingBridgeDownloadSchedule, CSV_INTERVAL, "1200, 900, 900, 3600"),
V(TestingClientMaxIntervalWithoutRequest, INTERVAL, "10 minutes"),
V(TestingDirConnectionMaxStall, INTERVAL, "5 minutes"),
V(TestingConsensusMaxDownloadTries, UINT, "8"),
diff --git a/src/or/directory.c b/src/or/directory.c
index 5fc15724cc..1f399818c4 100644
--- a/src/or/directory.c
+++ b/src/or/directory.c
@@ -3796,14 +3796,21 @@ next_random_exponential_delay(int delay, int max_delay)
/* How much are we willing to add to the delay? */
int max_increment;
+ const int multiplier = 3; /* no more than quadruple the previous delay */
- if (delay)
- max_increment = delay; /* no more than double. */
- else
- max_increment = 1; /* we're always willing to slow down a little. */
+ if (delay && delay < (INT_MAX-1) / multiplier) {
+ max_increment = delay * multiplier;
+ } else if (delay) {
+ max_increment = INT_MAX-1;
+ } else {
+ max_increment = 1;
+ }
+
+ if (BUG(max_increment < 1))
+ max_increment = 1;
- /* the + 1 here is so that we include the end of the interval */
- int increment = crypto_rand_int(max_increment+1);
+ /* the + 1 here is so that we always wait longer than last time. */
+ int increment = crypto_rand_int(max_increment)+1;
if (increment < max_delay - delay)
return delay + increment;
@@ -3933,15 +3940,16 @@ time_t
download_status_increment_failure(download_status_t *dls, int status_code,
const char *item, int server, time_t now)
{
+ (void) status_code; // XXXX no longer used.
+ (void) server; // XXXX no longer used.
int increment = -1;
int min_delay = 0, max_delay = INT_MAX;
tor_assert(dls);
- /* only count the failure if it's permanent, or we're a server */
- if (status_code != 503 || server) {
- if (dls->n_download_failures < IMPOSSIBLE_TO_DOWNLOAD-1)
- ++dls->n_download_failures;
+ /* count the failure */
+ if (dls->n_download_failures < IMPOSSIBLE_TO_DOWNLOAD-1) {
+ ++dls->n_download_failures;
}
if (dls->increment_on == DL_SCHED_INCREMENT_FAILURE) {