mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-12-06 19:41:15 +01:00
20c0581a7935369fecb6c62b7cf5c7c244cdb533
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.
Tor protects your privacy on the internet by hiding the connection
between your Internet address and the services you use. We believe Tor
is reasonably secure, but please ensure you read the instructions and
configure it properly.
To build Tor from source:
./configure && make && make install
Home page:
https://www.torproject.org/
Download new versions:
https://www.torproject.org/download.html
Documentation, including links to installation and setup instructions:
https://www.torproject.org/documentation.html
Making applications work with Tor:
https://wiki.torproject.org/noreply/TheOnionRouter/TorifyHOWTO
Frequently Asked Questions:
https://www.torproject.org/faq.html
https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ
Languages
C
94.4%
Python
1.5%
C++
1.1%
Shell
1.1%
M4
0.9%
Other
0.8%