r15599@catbus: nickm | 2007-10-09 16:44:36 -0400

Fix the bug that was making moria1 set valid-after wrong in its votes: we were looking at the preferred timing when we should have been looking at the consensus timing.


svn:r11818
This commit is contained in:
Nick Mathewson 2007-10-09 20:44:51 +00:00
parent 8b71a76dd3
commit 97fa3fdf16
2 changed files with 14 additions and 2 deletions

View file

@ -40,6 +40,8 @@ Changes in version 0.2.0.8-alpha - 2007-??-??
gets rid of annoying "400 OK" log messages, which may have been masking
some deeper issue. Bugfix on 0.2.0.7-alpha.
- When we get a valid consensus, recompute the voting schedule.
- Base the valid-after time of a vote on the consensus voting schedule,
not on our preferred schedule.
o Minor bugfixes (performance):
- Use a slightly simpler string hashing algorithm (copying Python's

View file

@ -2017,8 +2017,18 @@ generate_networkstatus_vote_obj(crypto_pk_env_t *private_key,
v3_out->is_vote = 1;
dirvote_get_preferred_voting_intervals(&timing);
v3_out->published = now;
v3_out->valid_after =
dirvote_get_start_of_next_interval(now, timing.vote_interval);
{
networkstatus_vote_t *current_consensus =
networkstatus_get_live_consensus(now);
time_t consensus_interval;
if (current_consensus)
consensus_interval = current_consensus->fresh_until -
current_consensus->valid_after;
else
consensus_interval = timing.vote_interval;
v3_out->valid_after =
dirvote_get_start_of_next_interval(now, consensus_interval);
}
v3_out->fresh_until = v3_out->valid_after + timing.vote_interval;
v3_out->valid_until = v3_out->valid_after +
(timing.vote_interval * timing.n_intervals_valid);