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

Re: [tor-bugs] #13239 [Tor]: Maybe we want three preemptive internal circs for hidden services?

#13239: Maybe we want three preemptive internal circs for hidden services?
------------------------+---------------------------------
     Reporter:  arma    |      Owner:
         Type:  defect  |     Status:  new
     Priority:  normal  |  Milestone:  Tor: 0.2.???
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  SponsorR tor-client
Actual Points:          |  Parent ID:
       Points:          |
------------------------+---------------------------------

Comment (by sysrqb):

 When a client cannibalizes a circuit for establishing a rend point, it
 doesn't modify the circuit and uses it as-is, so it remains 3 hops.

 circuituse.c:circuit_launch_by_extend_info()
 {{{
 switch (purpose) {
         case CIRCUIT_PURPOSE_C_ESTABLISH_REND:
           /* it's ready right now */
           break;
         case CIRCUIT_PURPOSE_C_INTRODUCING:
         case CIRCUIT_PURPOSE_S_CONNECT_REND:
         case CIRCUIT_PURPOSE_C_GENERAL:
         case CIRCUIT_PURPOSE_S_ESTABLISH_INTRO:
           /* need to add a new hop */
           tor_assert(extend_info);
           if (circuit_extend_to_new_exit(circ, extend_info) < 0)
             return NULL;
           break;
         default:
 }}}

 This seems like a better way to improve performance than explicitly
 establishing a rendezvous circuit for each onion service connections
 (#13222).


 Branch bug13239 pushed. It also tries to make the logic a little more
 readable.

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