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

Re: [tor-bugs] #4483 [Tor]: If k of n authorities are down, k/n bootstrapping clients are delayed for minutes

#4483: If k of n authorities are down, k/n bootstrapping clients are delayed for
minutes
-------------------------------------------------+-------------------------
 Reporter:  arma                                 |          Owner:  teor
     Type:  defect                               |         Status:
 Priority:  High                                 |  needs_review
Component:  Tor                                  |      Milestone:  Tor:
 Severity:  Normal                               |  0.2.8.x-final
 Keywords:  performance, bootstrap, dirauth-     |        Version:
  dos-resistance, tor-client, large-feature,     |     Resolution:
  prop210, 028-triage, TorCoreTeam201512,        |  Actual Points:
  MikePerry201512R                               |         Points:
Parent ID:  #2664                                |  medium/large
  Sponsor:  SponsorU                             |
-------------------------------------------------+-------------------------

Comment (by teor):

 Replying to [comment:39 nickm]:
 > Starting to review v10, since that's what I see...
 >
 > (Please do not do a rebase that changes stuff in these commits; instead,
 make fixup! or squash! commits so that I can review the changes and won't
 have to re-review what I've already been over.)

 I have added commits to feature4483-v10. (Please ignore feature4483-v11.)

 > 452272b4b7c03b1504fb8d04054473b275fa18e2 (#17574) --
 >   * I am not sure about the must/should distinction at all.  We'd like
 to avoid loops, sure, but I kinda feel like it isn't really true that a
 fallbackdir ''must never'' ask another fallback dir for information.  Must
 think more here.

 I'm not convinced it's needed either, I think the current behaviour is
 acceptable. (See my detailed comments in #17574.)
 We might want to explore it if we decide to make directory mirrors fetch
 from fallbacks (#17709).

 Reverted in 69faddc, which also reverts instances of should_fetch in
 subsequent commits.

 > f4397294e75dc4a419e8dfca95f1cf4e745e842a (#17716) --

 Reverted in a22cfec, as we're modifying this message as part of the
 refactoring in #17739.

 >   * maybe a router_digest_is_fallback_dir function would be handy to
 have.

 Yes, we'll definitely need this at some point.
 Added in 76c5b53.

 > 607fdd0a52f4ee41fe0cc27a102db53681a6aff4 (Refactor connection_get_* to
 produce lists and counts)

 See fixup commit f9f03c6 for all the fixes on this commit.

 >   * There is a huge amount of duplicate code here.  Having the same
 12-line function written   more than once is just asking for trouble
 IMNSHO.

 I've removed the duplicate code in the get* functions, by using template
 macros.

 This adds an extra check to connection_get_by_global_id, but doesn't
 change the behaviour of tor, because its only caller also makes this
 check.

 >   * strcmp_opt() could simply two of these functions.

 I've modified those functions to use strcmp_opt.

 >   * In connection.h, you're calling free(conns), not
 smartlist_free(conns).

 I've removed the duplicate code in the header, by using a template macro.
 This also fixes the free() issue.

 Oh, and the unit tests still pass, so I didn't break anything in these
 transformations.

 >
 > 88821fe930d5275eadec3125e097674124477b30 (Add want_authority to
 directory_get_from_dirserver)
 >   * Are the only options really DL_WANT_AUTHORITY and DL_WANT_FALLBACK ?
 Shouldn't there be a third state for "any cache would be okay" ?  Or am I
 not understanding right?  (In that case, please consider making the
 documentation more idiot-friendly)

 Ugh, I was so stuck in the bootstrap world I baked it into the name!

 See my fixup 8b5085a, where I change all DL_WANT_FALLBACK to
 DL_WANT_ANY_DIRSERVER, and add appropriate comments. In particular, while
 I could have changed launch_dummy_descriptor_download_as_needed() to use
 an authority to get a more trusted source for its IP address, I don't like
 the idea of some relays contacting an authority every 20 minutes. (So I
 left the previous behaviour intact.)

 > bc8f21f7bd4ed3ea52da94f44c58f34919841307 (Add attempt-based connection
 schedules)
 >   * .... (more to follow)...
 >

 I am ready to receive further instructions...

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4483#comment:40>
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