[tor-bugs] #9574 [Tor]: Process ntor create cells before tap create cells?

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Sep 4 01:06:08 UTC 2013


#9574: Process ntor create cells before tap create cells?
-----------------------------+---------------------------------------
     Reporter:  arma         |      Owner:
         Type:  enhancement  |     Status:  needs_review
     Priority:  normal       |  Milestone:  Tor: 0.2.5.x-final
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:  tor-relay, maybe-proposal
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+---------------------------------------

Comment (by arma):

 Replying to [comment:18 nickm]:
 > I'm also concerned that this code:
 > {{{
 > +  if (type == ONION_HANDSHAKE_TYPE_NTOR &&
 > +      ntor_usec / 1000 > (uint64_t)options->MaxOnionQueueDelay)
 > +    return 0;
 > +
 > +  if (type == ONION_HANDSHAKE_TYPE_TAP &&
 > +      (tap_usec + ntor_usec) / 1000 >
 (uint64_t)options->MaxOnionQueueDelay)
 >      return 0;
 > }}}
 > will lead to us just not accepting any TAP onionskins beyond the 50 that
 we always accept for each type.

 If our ntor queue remains substantially empty, then we'll accept tap cells
 about like we did before.

 If our ntor queue gets pretty big, and our processing estimates indicate
 it will take a long time to answer them, then we *should* refuse tap cells
 quickly, since we're unlikely to get around to them anytime soon.

 This reasoning is complicated by the new NumNTorsPerTAP consensus param
 though. Maybe we should do some complex math to reason about the sum of
 the queued onionskins times the fraction of each we plan to get to?

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


More information about the tor-bugs mailing list