Opened 12 years ago

Last modified 7 years ago

#422 closed defect (Fixed)

Need to back off better when oldest networkstatus isn't downloading right

Reported by: arma Owned by:
Priority: High Milestone:
Component: Core Tor/Tor Version: 0.1.2.13
Severity: Keywords:
Cc: arma, nickm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

dizum hasn't published a new networkstatus in the past five days. So
clients are rightly calling dizum the oldest, and trying to fetch a
new version. But there isn't a new enough one, so they keep trying,
once per minute.

May 05 01:36:47.708 [info] router_set_networkstatus(): Not replacing
network-status from directory server "dizum" at 194.109.206.212:80
(published 2007-05-01 19:33:17); we have a newer one (published
2007-05-01 19:34:23) for this authority.

http://74.98.7.159:16012/Chatty_Tor.zip has more details. We need
to make clients remember that the networkstatus they're about to
fetch is the same one they fetched last time, and back off if it
keeps failing.

The other piece of this bug is that apparently the network isn't
converging on a single networkstatus from dizum. The fellow who
reported this bug has one from "2007-05-01 19:34:23", but moria2
is currently serving one from "2007-05-01 19:33:17". Is this
because moria2 only asks dizum for updates, and dizum is down,
whereas some dir mirrors ask other places? For completeness:
tor26 is serving one from "2007-05-01 19:31:33", moria1 is serving
one from "2007-05-01 19:30:30", and lefkada has one from
"2007-05-01 19:29:54".

Presumably a few lucky dir mirrors got the latest one from dizum
before it croaked, but the dir mirrors are only asking the dir
authorities, so it's not spreading.

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (7)

comment:1 Changed 12 years ago by nickm

The diagnosis is right: dir authorities only ask the proper authority for that authority's network status.

Maybe if that fails, they should try periodically asking one of the other dirservers too.

comment:2 Changed 12 years ago by arma

Well, the real bug is that we try once per minute to replace our oldest
networkstatus, even if it's failing every single time. (See section 2b
of run_scheduled_events() in main.c).

I've checked in r10153 and r10156 that should help with this part. Let me
know if you think they'll break other parts. (E.g. if we increment the
failure counts in the wrong situations and end up not trying to fetch
things we should be trying to fetch)

comment:3 Changed 12 years ago by nickm

Okay, are we willing to call this "fixed" now?

comment:4 Changed 12 years ago by nickm

Roger: ping? I'm willing to call this "fixed enough" since we checked in a decent workaround, and
since the whole "replace the oldest networkstatus" code logic is going to get completely ripped out
once we switch to the v3 directory client logic.

comment:5 Changed 12 years ago by nickm

Marking as fixed; please re-open if you disagree.

comment:6 Changed 12 years ago by nickm

flyspray2trac: bug closed.

comment:7 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.