[tor-dev] Status report - Stream-RTT

[ra]

On Saturday 10 August 2013 02:37:48 Damian Johnson wrote:
> Hi Robert. Here's the relevant part of the spec...
> 
> https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l1738

Thanks. I will try to make that part more clear and open a ticket. 

> > If requests are sent to Tor to create more then a single circuit at once,
> > the mapping between circuit events and create-request is unknown because
> > the circuit ID is not known until the LAUNCHED-event has been received.
> > This is clearly an issue on Tor's side but one could argue that Stem
> > should stop me from using it that way.
> 
> Not sure that I follow. The extend_circuit() returns the circuit id
> (it's provided by the EXTENDCIRCUIT call). Are you saying that tor's
> EXTENDCIRCUIT response is wrong when done in parallel?

As far as I understand it it's not necessarily wrong but it might be the case 
that a response that does not belong to the call is received first: Assume a 
single program making two extend_circuit() calls within a short time. If the 
first EXTENDED response is delayed for some reason, both calls receive the 
EXTENDED response belonging to the second call -> both calls use the same 
circuit ID. Another case, again a single program making two extend_circuit() 
calls within a short time: if the second call has been made before the first 
EXTENDED response is received, the second call will use the EXTENDED response 
from the the first call when it arrives -> both calls use the same circuit ID. 
Therefore the await_build parameter should be True by default IMHO. Anyway it 
should be made clear that the await_build parameter doesn't work when 
extend_circuit() is used by two separate programs/threads that run 
concurrently. The user has to do the locking of (at least) the LAUNCHED event 
herself then. 

Besides I could not find any filtering of Tor-internal circuit events. If a Tor-
internal circuit EXTENDED event occurs during an extend_circuit() call, the 
wrong circuit ID will be used.

I hope, this is not too confusing.

Best,
Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130810/4dee8d8e/attachment-0001.sig>