diff options
author | Nick Mathewson <nickm@torproject.org> | 2011-07-07 10:40:23 -0400 |
---|---|---|
committer | Nick Mathewson <nickm@torproject.org> | 2011-07-19 01:58:45 -0400 |
commit | 20c0581a7935369fecb6c62b7cf5c7c244cdb533 (patch) | |
tree | 6299dd43e16754ad285e9519eb040e99386ac2d1 /src/or/rendclient.h | |
parent | 773bfaf91ebe1ef80f37d473714a11f962e753fb (diff) | |
download | tor-20c0581a7935369fecb6c62b7cf5c7c244cdb533.tar.gz tor-20c0581a7935369fecb6c62b7cf5c7c244cdb533.zip |
Launch sufficient circuits to satisfy pending isolated streams
Our old "do we need to launch a circuit for stream S" logic was,
more or less, that if we had a pending circuit that could handle S,
we didn't need to launch a new one.
But now that we have streams isolated from one another, we need
something stronger here: It's possible that some pending C can
handle either S1 or S2, but not both.
This patch reuses the existing isolation logic for a simple
solution: when we decide during circuit launching that some pending
C would satisfy stream S1, we "hypothetically" mark C as though S1
had been connected to it. Now if S2 is incompatible with S1, it
won't be something that can attach to C, and so we'll launch a new
stream.
When the circuit becomes OPEN for the first time (with no streams
attached to it), we reset the circuit's isolation status. I'm not
too sure about this part: I wanted some way to be sure that, if all
streams that would have used a circuit die before the circuit is
done, the circuit can still get used. But I worry that this
approach could also lead to us launching too many circuits. Careful
thought needed here.
Diffstat (limited to 'src/or/rendclient.h')
0 files changed, 0 insertions, 0 deletions