[tor-dev] Status report - Stream-RTT
r.a at posteo.net
Sat Aug 10 11:08:43 UTC 2013
On Saturday 10 August 2013 02:37:48 Damian Johnson wrote:
> Hi Robert. Here's the relevant part of the spec...
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the tor-dev