[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Tame circuits

     On Mon, 12 Oct 2009 15:11:05 -0700 (PDT) "Mr. Blue" <trashdsfg@xxxxxxxxx>
>> On Sun, Oct 11, 2009 at 03:11:47PM -0700, Mr. Blue wrote:
>> > Is there a way to completely stop a Tor from building circuits?!
>> > __DisablePredictedCircuits isn't achiving that, as in a middle of some
>> >progress Tor will sometimes, arbitrally build 2 or more random circuits
>> >AND USE THEM for my stream.
>> > PS: I AM aware of stream control and it's __, but wana avoid using it,
>> >because of overhead.
>> Section 5.4 of control-spec.txt:
>>   __LeaveStreamsUnattached
>>     If true, Tor will not automatically attach new streams to circuits;
>>     instead, the controller must attach them with ATTACHSTREAM.  If the
>>     controller does not attach the streams, their data will never be routed.
>> Setting that to 1 will prevent Tor from building a circuit in response
>> to a socks request. (Setting __DisablePredictedCircuits will prevent
>> Tor from building circuits beforehand in anticipation of socks requests.)
>> As for overhead, if you want to control circuits, this is how you do it.
>> Unless you can suggest a better way.
>> --Roger
>That is how I already use it.
>If __DisablePredictedCircuits would obey it absolutelly, then I wouldn't have to resort to __LeaveStreamsUnattached

     If it did that, then its name would be inaccurate.  Please note the
word "Predicted" contained in the name.
>When __DisablePredictedCircuits = 1:
>If in target node's descriptor is written Exit and it rejects port 80 and it is STILL used to get web page from port 80,

     If you request an exit connection destined for port 80, then tor will
make sure that you have a circuit that ends at an exit that allows port 80
connections.  If you request a specific exit (e.g., by specifiying a domain
name ending in someexitnodename.exit, then tor will attempt to build a circuit
to that exit.  If the requested exit rejects the port number for which the
circuit was requested, then it should return a SOCKS failure of some sort, I
should think.  That's what I've seen in the past in that situation.

>Tor WILL arbitrarly build completely NEW CIRCUIT, and exit randomly!

     Uh...tor itself should not exit unless a critical error of some sort
has occurred.  If, OTOH, you mean that it will build a circuit to an exit node,
then it is doing what it is supposed to do.  If a node has changed its exit
policy since the last time your tor fetched the exit node's descriptor, then
your tor doesn't yet know that its request may no longer be valid, so it will
build a circuit to the exit node.  When the exit node rejects the exit
connection request, then your tor notices that the exit node is behaving in
a manner that differs from your tor's copy of the exit node's descriptor.
Ordinarily, that should cause tor to attempt to build a circuit to a different
exit node for the requested port number in an attempt to service your request.

>	Tor build circuits when (__DisablePredictedCircuits = 1) in this cases:
>	for user traffic that no current circuit can handle,
>	for testing the network 
>	and our reachability...

     Correct.  Those are not *predicted* circuits, but rather are *demanded*

>__DisablePredictedCircuits = 1, doesn't give absolute control over circuits!
>That is a problem. So I have no option but to pair it with strem-control-super-fun-time!

     That is most definitely *not* a problem.  That is what tor is supposed
to do.  Your confusion is in the difference between circuits that tor builds
in anticipation of your future requests and circuits that tor builds to meet
your currently outstanding requests.

                                  Scott Bennett, Comm. ASMELG, CFIAG
* Internet:       bennett at cs.niu.edu                              *
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/