[tor-bugs] #3335 [Tor Hidden Services]: Remove an HS's entries in last_hid_serv_requests when a connection attempt ends

[Tor Bug Tracker & Wiki]

#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