Re: hello from slovenia

[Roger Dingledine <arma@mit.edu>]

On Mon, Jul 01, 2002 at 08:11:30AM -0400, Matej Pfajfar wrote:
> Hiya,
> 
> Just to say that I am back on-line - have got the latest code and will get 
> to grips with it.
> 
> Roger - which bits in your TODO list are a priority? Anything you want me 
> to work on in particular?

Great. Useful things that you or Bruce might do include:

* Look through the code and tell me where things don't make sense. I'm
still working on integrating the OP into it, and I'm afraid that will
complicate things a bit more (the OP is harder to do non-blocking that
I'd realized, because sometimes you have to drop everything, store state,
wait until it opens the new connection, and then go back and send the
onion/etc). So there will be plenty of things that don't make sense,
aren't documented, etc. Ask me questions about them, and either get me
to make the code better or make it better yourself. :)

* Start a test suite. Something that we can run with 'make tests' to
have a good idea that we didn't break anything with a new change. (Are
you familiar with the 'make tests' that, say, cpan modules include?) Our
test suite should start with the easy tests -- call various functions
with expected and unexpected arguments, and make sure they behave
appropriately. We can then move on to the harder stuff, like making sure
the network-based programs behave as expected. A side-effect of working on
a test suite is that we'll realize how to make each function more modular.
Example: if we start with a function that pulls data off a socket and
does stuff to it, it's hard to test that function because it's hard to
"fake" being the network. But if we split the function into two, it's
easy to test the "does stuff to it" function, and the "get data off a
socket" function will be shorter and easier to analyze. I've tried to
do that already, but I'm sure things can be improved.

* I'd like a cleaner interface for the configuration files, keys, etc.
I'm about to merge routers.op and routers.or, so specifically the changes
I'm thinking of at this point are:
  -- Each router now has an ORPort, OPPort, and APPort. Routers are still
     "named" by the IP/ORPort.
  -- Each router now has a set of zero or more twins, which are
     essentially totally different routers except they share the same key.
     I'm not sure of the right way to describe that in the config file
     (and so far I don't want to touch routers.c ;)
     Perhaps you or Bruce or Andrei should start a thread with more
     details on the config file format/elements, and tools for reading
     them?

* We need to think more about application proxies. Bruce is currently
working on cleaning up some of the application proxy code; but I think
bigger-picture we're going to want to start looking at taking existing
applications and making them onion-routing-aware.
http://freshmeat.net/search/?q=filtering+proxy&section=projects
is a good place to start looking. For instance,
http://www.delegate.org/, http://dansguardian.org/, squid itself,
http://sourceforge.net/projects/middle-man, all look promising.

Our goal for down the road should be to pick one or a few good proxy
systems that are already being maintained by others, give them some
patches so they work with the OR network, and then for the most part let
them take care of maintaining those patches. It might be that we can patch
squid and then simply use something like dansguardian on top unchanged.


Please let me know if any of these catch your eye, or if there are other
things you'd like to work on. There's still plenty to do.
Thanks,
--Roger