(FWD) [or-cvs] a new TODO file with more details
Roger Dingledine
arma at mit.edu
Fri Feb 14 04:13:31 UTC 2003
I've started a cleaner more expansive TODO version, based on Nick's
convention for writing TODO files. Please feel free to add to it,
rearrange it, do parts of it ;), etc.
--Roger
----- Forwarded message from Roger Dingledine <arma at seul.org> -----
From: arma at seul.org (Roger Dingledine)
Date: Thu, 13 Feb 2003 23:10:28 -0500 (EST)
To: or-cvs at freehaven.net
Subject: [or-cvs] a new TODO file with more details
Update of /home/or/cvsroot
In directory moria.mit.edu:/home/arma/work/onion/cvs
Modified Files:
README TODO configure.in
Log Message:
a new TODO file with more details
Index: TODO
===================================================================
RCS file: /home/or/cvsroot/TODO,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- TODO 23 Nov 2002 06:48:55 -0000 1.6
+++ TODO 14 Feb 2003 04:09:56 -0000 1.7
@@ -1,106 +1,107 @@
-[First four are all equally first.
-Others follow in order of priority.]
-
-Patch well-known proxies to make them OR compliant
- Data stream anonymizing, HTTP/FTP (Privoxy, Squid), SMTP, etc.
- Packet Redirector, a la FreeBSD (DNS, authenticated connections, etc.)
-
-Deploy and manage open source development site.
-Manage and maintain code, write documentation, design and write
- unit tests, handle patch submissions, make the autoconf work, etc
-
-Deploy a widespread network: manage deployment.
-Maintain and distribute directory/network state information etc. Keep
-operators and users happy.
-
-Test OR network for reliability and performance, with and without
- mechanisms for throttling, congestion control, padding, load balancing
- if applicable, etc.
- Use httperf and webload to get some performance stats
- Modify code as dictated by testing.
-
-Develop rendezvous points
-Implement reply onions
-Develop location protected servers idea
-
-Enhance router twins to do load balancing as well as DoS prevention
-
-Develop and deploy automated reputation management, directory servers,
-and directory/network state monitoring.
-
----
-
-debian / red hat spec file
-handle starting things as a system daemon
-transition addr to sin_addr
-get proxy to choose the same conn if it's open
-
-Obvious things I'd like to do that won't break anything:
-
-* Abstract out crypto calls (done), with the eventual goal of moving
- from openssl to something with a more flexible license.
-
-* Test suite. We need one.
-
-* Since my OR can handle multiple circuits through a given OP,
- I think it's clear that the OP should pass new create cells through the
- same channel. Thus we can take advantage of the padding we're already
- getting. Does that mean the choose_onion functions should be changed
- to always pick a favorite OR first, so the OP can minimize the number
- of outgoing connections it must sustain?
-
-* Figure out what .h files we're actually using, and how portable
- those are.
-
-* Exit policies. Since we don't really know what protocol is being spoken,
- it really comes down to an IP range and port range that we
- allow/disallow. The 'application' connection can evaluate it and make
- a decision.
-
-* We currently block on gethostbyname at the exit. This is poor. We need
- to set it up so we have a separate process that we talk to. There are
- some free software versions we can use, but they'll still be tricky.
-
-* I'd like a cleaner interface for the configuration files, keys, etc.
- Perhaps the next step is a central repository where we download router
- lists? We can aim to make use of the directory servers that Mixminion
- deploys.
-
-* ORs should rotate their link keys periodically. Later.
-
-* The parts of the code that say 'FIXME'
-
-* Clean up the number of places that get to look at prkey. Later.
-
-* Circuits should expire sometime, say, when circuit->expire triggers?
- Later.
-
-
+Legend:
+SPEC!! - Not specified
+SPEC - Spec not finalized
+ - Not done
+ * Top priority
+ . Partially done
+ o Done
+ D Deferred
+ X Abandoned
-Non-obvious things I'd like to do:
-(Many of these topics are inter-related. It's clear that we need more
-analysis before we can guess which approaches are good.)
+ . Topics / circuits
+ o Implement topics
+ - Rotate circuits after N minutes?
+ - Circuits should expire when circuit->expire triggers
+ - Handle half-open connections
+ . Clean up the event loop (optimize and sanitize)
+ - Exit policies
+ - Path selection algorithms
+ - Let user request certain nodes
+ - And disallow certain nodes
+ - Choose path by jurisdiction, etc?
+ - Implement our own memory management, at least for common structs
+ . Appropriate logging
+ - Come up with convention for what log level means what
+ - Make code follow convention
+ . Terminology
+ o Circuits, topics, cells stay named that
+ - 'Connection' gets divided, or renamed, or something?
+ . DNS farm
+ o Distribute queries onto the farm, get answers
+ o Preemptively grow a new worker before he's needed
+ - Prune workers when too many are idle
+ - Keep track of which connections are in dns_wait
+ - Need to cache positives/negatives on the tor side
+ - Keep track of which queries have been asked
+ - Better error handling when
+ - An address doesn't resolve
+ - We have max workers running
+ . Directory servers
+ - Automated reputation management
+ - Include key in source; sign directories
+ - Have directories list recommended-versions
+ - Quit if running the wrong version
+ - Command-line option to override quit
+ . Add more information to directory server entries
+ - Exit policies
+ - jurisdiction? others?
+SPEC!! - Figure out how to do threshold directory servers
+ . Scrubbing proxies
+ - Find an smtp proxy?
+ - Find an ftp proxy? Figure out how that would work?
+ - Wait until there are packet redirectors for Linux
+ . Get socks4a support into Mozilla
+ . Get tor to act like a socks server
+ o socks4, socks4a
+ - socks5
+SPEC!! - Handle socks commands other than connect, eg, bind?
+ - Develop rendezvous points
+ D Implement reply onions
+ D Deploy and manage open source development site.
+ . Documentation
+ . Discussion of socks, tsocks, etc
+ - On-the-network protocol
+ - Onions
+ - Cells
+ . Better comments for functions!
+ - Tests
+ - Testing harness/infrastructure
+ - Unit tests
+ - System tests (how?)
+ - Performance tests, so we know when we've improved
+ . webload infrastructure (Bruce)
+ . httperf infrastructure (easy to set up)
+ . oprofile (installed in RH 8.0)
+ D Deploy a widespread network
+ . Router twins
+ o Choose twin if primary is down, when laying circuit
+ - Load balancing between twins
+ - Keep track of load over links/nodes, to
+ know who's hosed
+ - Daemonize and package
+ - Teach it to fork and background
+ - Red Hat spec file
+ - Debian spec file equivalent
+
+ . Autoconf
+ . Which .h files are we actually using? Port to:
+ o Linux
+ o BSD
+ . Solaris
+ . Windows
+ . Move away from openssl
+ o Abstract out crypto calls
+ - Look at ndss, others? Just include code?
-* Currently when a connection goes down, it generates a destroy cell
- (either in both directions or just the appropriate one). When a
- destroy cell arrives to an OR (and it gets read after all previous
- cells have arrived), it delivers a destroy cell for the "other side"
- of the circuit: if the other side is an OP or App, it closes the entire
- connection as well.
+ . transition addr to sin_addr (huh?)
- But by "a connection going down", I mean "I read eof from it". Yet
- reading an eof simply means that it promises not to send any more
- data. It may still be perfectly fine receiving data (read "man 2
- shutdown"). In fact, some webservers work that way -- the client sends
- his entire request, and when the webserver reads an eof it begins
- its response. We currently don't support that sort of protocol; we
- may want to switch to some sort of a two-way-destroy-ripple technique
- (where a destroy makes its way all the way to the end of the circuit
- before being echoed back, and data stops flowing only when a destroy
- has been received from both sides of the circuit); this extends the
- one-hop-ack approach that Matej used.
+ . Clean up the number of places that get to look at prkey
+SPEC!! - Non-clique topologies, clearer bandwidth management
+ . Look at OR handshake in more detail
+ - Spec it
+ - Merge OR and OP handshakes?
+ - Periodic link key rotation. Spec?
-* Reply onions. Hrm.
Index: configure.in
===================================================================
RCS file: /home/or/cvsroot/configure.in,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -d -r1.10 -r1.11
--- configure.in 23 Nov 2002 06:48:55 -0000 1.10
+++ configure.in 14 Feb 2003 04:09:56 -0000 1.11
@@ -1,6 +1,6 @@
AC_INIT
-AM_INIT_AUTOMAKE(tor, 0.0.1)
+AM_INIT_AUTOMAKE(tor, 0.0.2pre4)
AM_CONFIG_HEADER(orconfig.h)
CFLAGS="-Wall -O2"
----- End forwarded message -----
More information about the tor-dev
mailing list