[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors



#23817: Tor re-tries directory mirrors that it knows are missing microdescriptors
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:  (none)
     Type:  defect                               |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.3.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-guard, tor-hs, prop224,          |  Actual Points:
  032-backport? 031-backport? spec-change        |
Parent ID:  #21969                               |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by asn):

 OK, I pushed a branch `bug23817_v2` with the following changes:

 - It's now rebased on latest master (I will also prepare an 032 branch)
 - Renames `relay_digest` to `dir_id` in `directory.c`.
 - Adds a log message for failed mds.
 - Does not add dirauths as outdated dirservers.
 - Cleans up the outdated list if it grows above 30 elements.

 A few notes:

 - I'm not checking if we have a recent consensus when we blacklist
 dirservers, as Nick suggested, which might actually be a problem. I think
 teor's suggestion of "check if our consensus is recent and try to get a
 newer one" is a whole project of its own that warrants its own ticket (or
 not?). What should we do here? Maybe we should not register outdated
 dirservers if we don't have a live consensus?
 - teor, I'm not sure if I agree with your exponential backoff + list size
 argument, since IIUC the exponential backoff applies only when we fail to
 fetch the same md multiple times, whereas the outdated list can overgrow
 just by failing many fetches for different mds. In any case, I opted for
 resetting the list after 30 arguments, which is a bit arbitrary but
 perhaps can save us from any surprising issues (?).
 - I did not reset the list based on elapsed time because of teor's
 argument about clients fetching consensuses every 1 hour or so. Let me
 know if you don't like this.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23817#comment:18>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs