OR_CONN_EVENT_NEW: we should probably handle that , should we not? Especially since 23:26 < phobos> nickm: grep -c "Unrecognized status code 4" tor.log

svn:r6752
This commit is contained in:
Nick Mathewson 2006-07-11 03:33:16 +00:00
parent 39344fc301
commit c32e19b4ed
2 changed files with 77 additions and 6 deletions

View File

@ -19,18 +19,82 @@ list. -NM
1. General operation
* We build some circuits preemptively, and some on-demand.
* We attach greedily, and expire after time.
Tor begins building circuits as soon as it has enough directory
information to do so (see section 5.1 of dir-spec.txt). Some circuits are
built preemptively because we expect to need them later (for user
traffic), and some are build because of immediate need (for user traffic
that no current circuit can handle, for testing the network or our
availability, and so on).
When a client application creates a new stream (by opening a SOCKS
connection or launching a resolve request), we attach it to an appropriate
open (or in-progress) circuit if one exists, and launch a new circuit only
if no current circuit can handle the request. We rotate circuits over
time to avoid some profiling attacks.
These processes are described in more detail below.
1b. Types of circuits.
* Stable / Ordinary
* Internal / Exit
1c. Terminology
A "path" is an ordered sequence of nodes, not yet built as a circuit.
A "clean" circuit is one that has not yet been used for any stream or
rendezvous traffic.
A "stable" node is one that we believe to have the 'Stable' flag set on
the basis of our current directory information. A "stable" circuit is one
that consists entirely of "stable" nodes.
A "persistent" stream is one that we predict will require a long uptime.
Currently, Tor does this by examining the stream's target port, and
comparing it to a list of "long-lived" ports. (Default: 21, 22, 706, 1863,
5050, 5190, 5222, 5223, 6667, 8300, 8888.)
An exit node "supports" a stream if the stream's target IP is known, and
the stream's IP and target Port are allowed by the exit node's declared
exit policy. A path "supports" a stream if:
* The last node in the path "supports" the stream, and
* If the stream is "persistent," all the nodes in the path are
"stable".
An exit node "might support" a stream if the stream's target IP is unknown
(because we haven't resolved it yet), and the exit node's declared exit
policy allows some IPs to exit at that port. ???
2. Building circuits
* Preemptive building
* On-demand building
* Cannibalizing circuits
2.1. When we build.
When running as a client, Tor tries to maintain at least 3 clean circuits,
so that new streams can be handled quickly. To increase the likelihood of
success, Tor tries to predict what exit nodes will be useful by choosing
from among nodes that support the ports we have used in the recent past.
If Tor needs to attach a stream that no current exit circuit can support,
it looks for an existing clean circuit to cannibalize. If we find one,
we try to extend it another hop to an exit node that might support the
stream. [Must be internal???]
If no circuit exists, or is currently being built, along a path that
might support a stream, we begin building a new circuit that might support
the stream.
2.2. Path selection
When we bui
2.3. Handling failure
2.4. Tracking "predicted" ports
* Choosing the path first, building second.
* Choosing the length of the circuit.
* Choosing entries, midpoints, exits.
@ -46,7 +110,6 @@ list. -NM
* Timeouts and when Tor autoretries.
* What stream-end-reasons are appropriate for retrying.
4. Rendezvous circuits
5. Guard nodes
@ -341,4 +404,11 @@ more than just let users ask for certain entry nodes.
============================================================
Some stuff that worries me about entry guards. 2006 Jun, Nickm.
1. It is unlikely for two users to have the same set of entry guards.
2. Observing a user is sufficient to learn its entry guards.
3. So, as we move around, we leak our

View File

@ -2735,6 +2735,7 @@ control_event_or_conn_status(connection_t *conn,or_conn_status_event_t tp)
case OR_CONN_EVENT_CONNECTED: status = "CONNECTED"; break;
case OR_CONN_EVENT_FAILED: status = "FAILED"; break;
case OR_CONN_EVENT_CLOSED: status = "CLOSED"; break;
case OR_CONN_EVENT_NEW: status = "NEW"; break;
default:
log_warn(LD_BUG, "Unrecognized status code %d", (int)tp);
return 0;