[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