[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #33029 [Core Tor/Tor]: dir-auth: Dir auths should resume sending 503's but never to relays or other dir auths
#33029: dir-auth: Dir auths should resume sending 503's but never to relays or
other dir auths
-------------------------------------+------------------------------------
Reporter: dgoulet | Owner: dgoulet
Type: defect | Status: needs_revision
Priority: Medium | Milestone: Tor: 0.4.3.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: tor-dirauth 043-should? | Actual Points:
Parent ID: #33018 | Points: 0.4
Reviewer: nickm, teor, armadev | Sponsor:
-------------------------------------+------------------------------------
Comment (by arma):
Replying to [comment:19 teor]:
> What about the bridge authority?
> Does it need to allow bridges to post descriptors
None of these functions are about how to respond to
directory_handle_command_post(), so posting descriptors should be fine and
unaffected, both from bridge relays and from other kinds of relays.
> and get directory documents?
I don't think the bridge authority is any different from any other dir
cache, with respect to publishing the consensus. The fact that it doesn't
have the Guard flag will mean it is mostly ignored by clients.
In an alternate universe where we'd finished building
UpdateBridgesFromAuthority, then we'd want to make sure that it is willing
to serve bridge descriptors to people who know the right fingerprint for
them. But we don't live in that universe so I don't think it's an issue.
And also that design is about responding to clients -- who might be
routing their requests via Tor, in which case they'll get prioritized
because the requests come from relays, and if not, they would be random
looking clients anyway.
Though! This does make me realize: our changed behavior here applies to
begindir requests over the ORPort too, right? So we are now willing to
give 503 responses to clients when we're under load. Maybe that's a
feature, since "under load" means we'd be answering them poorly anyway. It
definitely makes me more interested in the "several tiers of responses
(like 'orport or dirport', 'micro flavored consensus or vanilla flavored
consensus', 'requests compression or doesn't') where we reserve some of
our bandwidth and don't spend it on the lowest tier" sort of design. But
that's something we can save for #33018.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33029#comment:20>
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