Re: onion_router stress-testing...

[Roger Dingledine <arma@mit.edu>]

On Mon, Nov 25, 2002 at 12:10:17PM -0500, Paul Syverson wrote:
> It was concerns such as these that prompted us to have a separate
> module to handle creates in the old (middle?) architecture. Then nodes
> that get a lot of new connections could shunt the public key operations
> off to the crypto module (which might live on another machine or even
> on a crypto hardware processor) while other cells can flow unimpeded. I
> certainly don't want to suggest ripping everything apart to do this. If
> there's anything I've learned in the last few years looking at both our
> own and other systems, it's to keep it as simple as possible. But, is
> there any way to allow the high load computations to be parallelized
> with ongoing connections in this way?

Good idea. I've just committed a change so onions are now processed
only when there's nothing else waiting to be processed. So we're
still limited to about the same number of new circuits per second, but
hopefully everything doesn't go to hell when too many creates arrive at
once.

There's a new config variable called MaxOnionsPending that limits the
number of pending onions. New onions that arrive when the queue is
full are dropped and we send back a destroy. We also collect data cells
destined for a pending circuit, and process them once the circuit opens.
Destroys also do the right thing.

I've put up a new version: http://freehaven.net/or/tor-0.0.2pre1.tar.gz

As for letting a tor node farm out its crypto to many machines... I think
the right answer for now is if you want to use multiple machines, run more
than one tor node. (You can even run them all with one key, which will
let other nodes load balance in terms of which of your nodes they pick.)
I think that's probably the right answer long-term as well.

--Roger