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
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev