A Java-based Tor simulator -- where can I share it?

[Karsten Loesing]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

as a preparatory work for my GSoC project I implemented a Java-based Tor
simulator that might also be useful for others (the other GSoC
students?). Originally, it was intended to analyze behavior of hidden
service requests in public and private Tor networks. But I think it can
be used for other services in Tor, too. At least it can be a start to
generate a first network configuration. If you want to read more, I
attached the first section of the howto to this mail. And maybe you can
read even more in the future......

(and this brings me to my actual question): ...... where? How can I
share this code? Can you host it at your Subversion repository? Or will
Google host it (because it's part of the project)? I could also host it
at the CVS repository at our university, but how would others learn
about it (link)?

The next question is about the code that we GSoCers are going to write
during our projects: do you create a branch for each GSoC project? Or
will we host our projects at Google or by ourselves?

And the last question: What about licenses? What do I have to write to
the code to include it in the license?

- --Karsten


- ---- Introduction section of User's Guide ----

PuppeTor (working title) is a Java framework that facilitates the
configuration of a set of local Tor processes and the execution of
automatic tests based on these processes. The intention is to make it
easier for developers to analyze Tor's behavior in arbitrary network
settings and to measure the effects of changes to the Tor source code.
Due to the automation of configuration and execution, these experiments
can be done in an unsupervised batch fashion.

An application that makes use of this framework starts with setting up a
set of pre-defined Tor processes: proxy, router, and directory. Though
these configurations should work in most settings, they can be altered
by adding or removing configuration entries. After deciding whether the
processes shall either create a private Tor network, or connect to the
public Tor network, processes are started. Now the application can start
clients and servers and perform requests using the local processes. In
doing so, it can measure time intervals between events originating from
Tor processes and it can synchronize with such events. Further, the
application can re-configure processes during their execution using the
Tor controller.

There are two typical situations in which this framework can be useful:

1. Developers need to oversee the effects of their changes to the source
code. Therefore, it is useful to have a clean setting of Tor nodes in a
private network, so that all nodes are under full control of the developer.

2. Developers might want to measure the real-world performance of
certain Tor operations. Hence, they can set up nodes at the edge of the
public Tor network and conduct performance measurements, maybe in a
batch of some hundreds or thousands of runs.

Of course, the applications described here are possible without this
framework. But this framework has certain advantages over writing own
configuration files and test scripts:

1. It provides developers with pre-defined configurations of nodes.
Especially the configuration of nodes in a private network with own
directory nodes is not a trivial task.

2. It takes away the need to implement synchronization of a test
application with events created by Tor processes. This, too, is a
non-trivial task and can, if not done properly, lead to deadlocks or
inconsistent states (yes, this happened during development of the
framework, too).

3. It relieves the developer from the task to collect and merge log
files. Typically, every Tor process produces its own log file, so that
all files might need to be merged in chronological order to identify
causal dependencies.

Originally this framework has been designed to perform experiments on
Tor hidden services. But it should be feasible for experiments on onion
routing and other Tor services, too. If you have found an alternative
usage for it, and maybe have changed or extended it to support your own
application, please feel free to contribute your additions. And please
report bugs.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGK/K+0M+WPffBEmURAs60AJ4g96GSKXmoHx1lhO3oWPPmaamN/gCgz/UK
6wNI6WXNcxuNAO3+1w7XsJc=
=kZbs
-----END PGP SIGNATURE-----