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

Re: [tor-dev] Design for an exit relay scanner: feedback appreciated



On Thu, Oct 10, 2013 at 9:57 AM, Philipp Winter <identity.function@xxxxxxxxx> wrote:
On Thu, Oct 10, 2013 at 07:23:11AM +0000, Aaron wrote:
> I have been working on adding a "Tor Network Test Template" to ooni-probe;
> the basic concept is to extend the Tor controller library we use (txtorcon)
> to be able to build and attach circuits to specific streams, and iterate over
> the exits in the consensus. That is, we'll provide primitives that will allow
> you to specify a network interference test and tell ooni to run that test
> against every exit we know about (or a subset, a specific exit, or what have
> you).

I have a very similar goal.  However, instead of extending my controller (I use
stem), I spawn parallel Tor processes out of a process pool (based on Python's
'concurrent' module).  I assume, your scanning would be sequential?

ooni is built with Twisted (http://twistedmatrix.com/), which is a python based asynchronous event-driven framework, similar in concept to libevent. Our scheduler caps the number of 'in flight' measurements to whatever you specify in the ooniprobe.conf 'concurrency' options.


> ooni-probe features a concurrency-based scheduler, so as to limit the impact
> on the network, and we've designed it to support plug-in rate limiting hooks
> if you want to do something fancier.

Rate limiting certainly sounds fancier than what I had in mind :)

We don't do anything that fancy yet, just left the stubs in place for future use as we thought they might come in handy.
 

Cheers,
Philipp
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev