[tor-bugs] #1297 [Tor Hidden Services]: Update hidden service logic to be more resilient to timeout

[Tor Bug Tracker & Wiki]

#1297: Update hidden service logic to be more resilient to timeout
------------------------------------+---------------------------------------
    Reporter:  mikeperry            |       Owner:  rransom           
        Type:  defect               |      Status:  needs_review      
    Priority:  major                |   Milestone:  Tor: 0.2.3.x-final
   Component:  Tor Hidden Services  |     Version:  0.2.2.10-alpha    
  Resolution:  None                 |    Keywords:                    
      Parent:  #2552                |      Points:                    
Actualpoints:                       |  
------------------------------------+---------------------------------------

Comment(by rransom):

 Replying to [comment:16 nickm]:
 > Looks good, I think.  Could I have some comments explaining what can
 happen to a circuit once hs_circ_has_timed_out is set on it?  The current
 comments do a good job of explaining when the flag is set, but not the
 allowable transitions out of that state.

 OK.  I'll push a comment change tomorrow.

 > (So, the idea is that a "timed out" circuit is not really timed out, but
 allowed to stick around a little longer in case it works, in which case we
 declare it to be okay?)

 Yes, that's the idea.

 > Why would you want to set CloseHSClientCircuitsImmediatelyOnTimeout ? Is
 it just there for testing, or what?

 The justification for Tor's adaptive-CBT code is that circuits which are
 built more quickly are also ‘faster’ after they are built.  These changes
 will cause clients to use circuits with longer build times, in order to
 decrease the overall time until some circuit is connected to a hidden
 service.  Users who connect to or host latency-sensitive hidden services
 (e.g. IRC) might want to set the options which disable these changes.

 We will also want to use those options to test the impact of this change
 on performance, someday when we have a performance-measurement tool which
 measures the latency on an open circuit (rather than only measuring the
 time until a first request has completed through a Tor client with no
 circuits open).

 > Is there any limit on how many times this code can relaunch circuits on
 timeout for the same request?

 On the client side, HS circuits are relaunched by the existing code in
 `circuit_get_open_circ_or_launch` when it does not find an ‘acceptable’
 circuit to use (as defined by `circuit_is_acceptable`, which never
 considers a circuit with `hs_circ_has_timed_out` set acceptable).  The
 client will continue launching circuits as long as there is an AP
 connection trying to connect to the hidden service and there is an intro
 point remaining to try for the HS.  (Before the last #3825 change, clients
 could keep pounding an intro point for SocksTimeout seconds; now, the
 maximum number of intro circs is five circs per intro point.)

 On the service side, rendezvous circuits are relaunched when they reach
 the normal timeout for four-hop circuits.  The service will stop launching
 circuits to a client's rendezvous point after launching MAX_REND_FAILURES
 circuits (currently 30) or after trying to connect for MAX_REND_TIMEOUT
 seconds (currently 30).  [ticket:4241 MAX_REND_FAILURES is too high], but
 I don't know what number to lower it to yet.

 This change does not increase the number of circuits built for a hidden-
 service connection attempt; it is likely to decrease the number of
 circuits, by decreasing the time before a client successfully connects to
 a hidden service (and thus decreasing the time for which it builds new
 circuits for the HS connection attempt).

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1297#comment:17>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online