nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-24 04:13:28 +01:00
Code Issues Packages Projects Releases Wiki Activity

r11550@catbus: nickm | 2007-01-27 02:56:48 -0500

Browse Source 
TODO items: Defer complicated solution to BEGIN_DIR memory problem; mark the simple one partially implemented; note a forward compatibility TODO.


svn:r9431
This commit is contained in:
Nick Mathewson 2007-01-27 07:57:01 +00:00
parent 152547be49
commit 2525c44d17
1 changed files with 31 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

69
doc/TODO
View File

@ -57,45 +57,11 @@ R - Hunt for places that change networkstatus info that I might have
TunnelDirConns and PreferTunneledDirConns
R - actually cause the directory.c functions to know about or_port
and use it when we're supposed to.
N - for tunneled edge conns, stop reading to the bridge connection
N o for tunneled edge conns, stop reading to the bridge connection
when the or_conn we're writing to has a full outbuf.
- This is iffy. Really, it would've been better to stop writing
on the dir conn when the edge conn's inbuf is getting full.
But the issue there is that we package from edge
connections aggressively until we hit their package windows or the
circuit package windows, even if the buffer on the corresponding OR
connection is pretty damn big. This sucks from a RAM usage POV.
Now, we could try to stop reading on the edges (or just the edges
connected to a local bridge) when an or_conn's outbuf is full. But
if we're a server, and we stop reading on some exit conns when OR
conns are full, soon OR conns will contain only traffic from other OR
conns, and the exit data in question will never get written.
- The right solution in the long run (0.2.0) is probably as follows:
- Remove socketpair-based bridges: use shared (or connected) buffers
for communication, rather than sockets.
- When relaying cells from an OR conn to an OR conn, have them wait
in a queue on the or_circuit_t object; don't move them onto the
target conn until there is space in the target conn's outbuf.
Also, only package data from exitconns when there is space in the
target conn's outbuf.
- As an added advantage, this would let us kill stalled _circuits_
when their buffers get too full, rather than killing entire OR
conns. But we must think about anonymity implications of that.
- We'll probably want to do some kind of big refactoring of our
dataflow when we do these changes; stuff is hairy enough already,
and it will only get harrier with this stuff.
- For the short run, our options seem to be:
- Disable BEGIN_DIR support at the server-side unless it's
explicitly turned on.
- Go ahead and make directory bridge data not get produced when the
corresponding or_conn is full, and accept the sometimes directory
data will just never get written.
- Rate-limit directory bridge data somehow when the corresponding
or_conn is full. Possibly based on the flush rate of the or_conn?
- Reject BEGIN_DIR requests that we think will be insanely big.
. make directory bridge data not get produced when the corresponding
or_conn is full, and accept the sometimes directory data will just
never get written.
N - DNS improvements
. Asynchronous DNS
@ -157,6 +123,10 @@ N - Implement, if we think it's smart.
a descriptor.
NR - Design
N - Implement, if we think it's smart.
- Check for any outstanding checks we do on the form or number of client
certificates that would prevent us from executing certain
blocking-resistance strategies.
Topics to think about during 0.1.2.x development:
* Figure out incentives.
@ -197,6 +167,29 @@ P - Figure out why openssl 0.9.8d "make test" fails at sha256t test.
- What do we do about the fact that people can't read zlib-
compressed files manually?
- Change the way we handle cells, flow-control, and bridges.
- The issue is that we package from edge connections aggressively until
we hit their package windows or the circuit package windows, even if
the buffer on the corresponding OR connection is pretty damn big. This
sucks from a RAM usage POV. Now, we could try to stop reading on the
edges (or just the edges connected to a local bridge) when an or_conn's
outbuf is full. But if we're a server, and we stop reading on some
exit conns when OR conns are full, soon OR conns will contain only
traffic from other OR conns, and the exit data in question will never
get written.
- Remove socketpair-based bridges: use shared (or connected) buffers for
communication, rather than sockets.
- When relaying cells from an OR conn to an OR conn, have them wait in a
queue on the or_circuit_t object; don't move them onto the target conn
until there is space in the target conn's outbuf. Also, only package
data from exitconns when there is space in the target conn's outbuf.
- As an added advantage, this would let us kill stalled _circuits_
when their buffers get too full, rather than killing entire OR
conns. But we must think about anonymity implications of that.
- We'll probably want to do some kind of big refactoring of our
dataflow when we do these changes; stuff is hairy enough already,
and it will only get harrier with this stuff.
- If the client's clock is too far in the past, it will drop (or
just not try to get) descriptors, so it'll never build circuits.
- Tolerate clock skew on bridge relays.