[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #9574 [Tor]: Process ntor create cells before tap create cells?
#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: |
-----------------------------+---------------------------------------
Changes (by isis):
* cc: isis@â (added)
Comment:
I tested and this seems to be working, I also briefly reviewed the
patches. Attached is the torrc for that relay and some info logs plus the
events from `SETEVENTS EXTENDED CIRC CLIENTS_SEEN INFO DESCCHANGED
BUILDTIMEOUT_SET`.
CPU went from wavering around 400% (with `NumCPUs 4`) to 80%-140%. I had
one failure before this patch from lack of available fds, which had been
~3900 out of 4096 for several days -- now fd levels are at ~1200/4096.
It's still getting CIRC FAILEDs, but I think this is from the other relays
not being able to handle more circuits.
Replying to [comment:12 nickm]:
> * The code in onion_next_task is too aggressive: it does "never answer
a TAP request while any ntor request is pending", which means that in
practice I doubt we'll answer TAP requests at all on a busy node.
Mine isn't the biggest exit relay, I think it's only 0.15% of the total
exit capacity, but the TAP queues so far have stayed pretty low. That
might change if more relays start running with these patches.
> Here are some other ideas we could take:
> * Always answer at least N ntor requests for every 1 TAP request,
if we have both. (N=5? 10?)
> * When we have both ntor and TAP requests, choose an ntor request
with probability P. (P=.8? P=.9?)
> * When we have both ntor and TAP requests, choose an ntor request
unless the oldest pending TAP request is N msec older than the oldest
pending ntor request. (N=???)
> * What else?
>
> Also, does this imply that we ought to start designing a handshake with
scalable client proof-of-something?
>
I wanted PoW for BridgeDB, researched it a bit (see
[https://trac.torproject.org/projects/tor/ticket/7520#comment:14
#7520:comment14]), wasn't very hopeful about finding a workind PoW scheme,
and then phw convinced me that anything we expect a Tor client to do, an
adversary can certainly do. Though I would really love to see this proven
wrong.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9574#comment:13>
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