12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970 |
- Obvious things I'd like to do that won't break anything:
- * Abstract out crypto calls, 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.
- 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.)
- * 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.
- 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.
- * Reply onions. Hrm.
|