[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3335 [Tor Hidden Services]: Remove an HS's entries in last_hid_serv_requests when a connection attempt ends
#3335: Remove an HS's entries in last_hid_serv_requests when a connection attempt
ends
---------------------------------+------------------------------------------
Reporter: rransom | Owner: rransom
Type: enhancement | Status: needs_review
Priority: normal | Milestone: Tor: 0.2.2.x-final
Component: Tor Hidden Services | Version:
Keywords: | Parent:
Points: | Actualpoints:
---------------------------------+------------------------------------------
Comment(by rransom):
Replying to [comment:3 nickm]:
> The XXX023 comment notation usually means a potential problem that we
need to fix before 0.2.3 comes out. What's the problem with those
asserts?
I think we should add those asserts (i.e. uncomment them) on 0.2.3.x, but
not on 0.2.2.x (if/when we merge this branch there).
> The documentation for the get_last_hid_serv_requests() strmap and its
friends really need to get updated for the new strmap key format.
Oops. I didn't realize the key format had been documented. Fix pushed.
> Is there any way for the new code to result in repeatedly hammering the
network by trying and failing to connect to the same nonworking hs? That
was one of the points of the 15 minute timeout, IIRC. What replaces that
functionality now?
If the user repeatedly opens new streams to a hidden service address such
that (a) there is no HS with that address, (b) the HS with that address
has not published its HS descriptors yet, or (c) the HS with that address
has gone offline since the last time it published its HS descriptors, Tor
will now contact each HS directory responsible for a descriptor ID at most
once per connection attempt. I don't think this is significantly worse
than the old situation.
This is actually better than the current behaviour if one of the
directories responsible for a hidden service gets overloaded with CREATE
cells and starts dropping them, because a client might try other HS
directories on their next connection attempt rather than only having the
overloaded directory left for the next 15 minutes and pounding it with a
flood of CREATEs for as long as the user tries to connect to the service.
Sounds like we`^W`I should open a new ticket for âgive up on reaching a
destination for N minutes after M failed circuits for a single streamâ in
general.
See [https://gitweb.torproject.org/rransom/tor.git/shortlog/refs/heads/hs-
fixes-2011-09-29-01 hs-fixes-2011-09-29-01] (
`https://git.torproject.org/rransom/tor.git hs-fixes-2011-09-29-01` ) for
a fixed #3825 and #3335 branch; see
[https://gitweb.torproject.org/rransom/tor.git/shortlog/refs/heads/bug3335-v2
bug3335-v2] ( `https://git.torproject.org/rransom/tor.git bug3335-v2` )
for a fixed and rebased version (with âFix log message typoâ renamed to
âFix comment typoâ; oops), also containing #3825 for a relatively good
reason: one of the #3335-fix commits changes the
`rend_client_note_connection_attempt_ended` function added for #3825.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3335#comment:4>
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