Re: How many hidden service circuits built?
On Thursday 11 December 2008, Roger Dingledine wrote: On Thu, Dec 11, 2008 at 11:25:40PM +0100, Bernhard Fischer wrote: If I connect through the SOCKS interface several times at the same time to the same hidden service, does TOR open a bunch of circuits in parallel to the designated hidden service or does it just open a single one and then reuse it for every of the incoming SOCKS request? It should try to reuse the same circuit. (You will see a bunch of circuits going to make the rendezvous happen, but only one of them will be the one that all your streams get connected to.) --Roger Is it possible to change this behavior (maybe by a slight modification of the source)? Best regards, Bernhard signature.asc Description: This is a digitally signed message part.
Re: How many hidden service circuits built?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernhard Fischer wrote: On Thursday 11 December 2008, Roger Dingledine wrote: On Thu, Dec 11, 2008 at 11:25:40PM +0100, Bernhard Fischer wrote: If I connect through the SOCKS interface several times at the same time to the same hidden service, does TOR open a bunch of circuits in parallel to the designated hidden service or does it just open a single one and then reuse it for every of the incoming SOCKS request? It should try to reuse the same circuit. (You will see a bunch of circuits going to make the rendezvous happen, but only one of them will be the one that all your streams get connected to.) --Roger Is it possible to change this behavior (maybe by a slight modification of the source)? I'm not sure what you are up to, so I'm guessing. Are you asking for a) parallelizing connection establishment in order to reduce delay, b) having a separate circuit to the hidden server for every application-level stream, or something else? As for a), we are already working on improvements to reduce the delay in connection establishment. Did you have a look at this page?: https://www.torproject.org/projects/hidserv.html Part of the solution is to parallelize some of the substeps. One example are circuits to introduction points which are built in parallel after a delay of 15 seconds. Future ideas are to request hidden service descriptors from the directories in parallel. But making two (or even more) full connection establishments with all steps being performed twice (or more times) is a bit too brute-force, isn't it? The goal is to make hidden services faster, but in a way that doesn't put too much new load on the network. As for b), I don't know if this makes sense, either. Why separate the circuits when you can multiplex an arbitrary number of streams over them? Fault tolerance? Unlinkability of streams? But instead of guessing what you had in mind, I'll just ask: Why do you want to do this? - --Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJQkiP0M+WPffBEmURAsmuAJ4lf5aPZBg7IEXw0hzW4aCb0Ve2CgCfW37x ki2Nf2vTOF9Z+jRX8GevDfU= =1DHP -END PGP SIGNATURE-
Re: How many hidden service circuits built?
On Friday 12 December 2008, Karsten Loesing wrote: Bernhard Fischer wrote: On Thursday 11 December 2008, Roger Dingledine wrote: On Thu, Dec 11, 2008 at 11:25:40PM +0100, Bernhard Fischer wrote: If I connect through the SOCKS interface several times at the same time to the same hidden service, does TOR open a bunch of circuits in parallel to the designated hidden service or does it just open a single one and then reuse it for every of the incoming SOCKS request? It should try to reuse the same circuit. (You will see a bunch of circuits going to make the rendezvous happen, but only one of them will be the one that all your streams get connected to.) --Roger Is it possible to change this behavior (maybe by a slight modification of the source)? I'm not sure what you are up to, so I'm guessing. Are you asking for a) parallelizing connection establishment in order to reduce delay, b) having a separate circuit to the hidden server for every application-level stream, or something else? As for a), we are already working on improvements to reduce the delay in connection establishment. Did you have a look at this page?: https://www.torproject.org/projects/hidserv.html Sorry, I didn't see this before. I'll read your paper and I appreciate all improvements regarding hidden services. As for b), I don't know if this makes sense, either. Why separate the circuits when you can multiplex an arbitrary number of streams over them? Fault tolerance? Unlinkability of streams? But instead of guessing what you had in mind, I'll just ask: Why do you want to do this? You guessed pretty good ;) While TOR is building circuits there's always some kind of randomness involved. As far as I know TOR chooses nodes based on directory flags (like fast, stable, ...) and the randomizes those matching some criteria. Obviously the flag fast is somehow misleading because bandwidth is a local property and does not necessarily mean that it's also fast across the network to any other node. I'm interested in performance improvements of hidden services, but I'm talking about RTT once the connections are established and not so much on the connection setup time (which of course is also important but this time is only spent once) I did some RTT measurements and my observations are really ugly. It usually is never below 5s. What you can observe is that when the circuit is rotated the RTT also changes signifficant. My idea now was to open several circuits to the same hidden service. If they're connected through different nodes (because of the random selection) also the RTT will be different. Then I continuously do RTT measurements on all those circuits and always use that one with the lowest time for user data. Best regard, Bernhard signature.asc Description: This is a digitally signed message part.
Re: [Fwd: (Probably) a known problem?] - cant run a relay node
On Wed, Dec 03, 2008 at 11:52:50AM -0500, pho...@rootme.org wrote: [...] A few things, you probably haven't received a response because no one has a good idea how to fix it. You may have 2 issues, one is that libevent can't find nameservers, and the other is that the config options are broken. As for the dns issues: https://bugs.torproject.org/flyspray/index.php?do=detailsid=813 or https://bugs.torproject.org/flyspray/index.php?do=detailsid=868 These bugs are now fixed in svn trunk, I think. The fixes should be in 0.2.1.9-alpha, assuming that the fix was really a fix. -- Nick
Re: [Fwd: (Probably) a known problem?] - cant run a relay node
On Wed, Dec 03, 2008 at 06:35:19PM +0100, Fabian Keil wrote: [...] While we're talking about DNS issues, I recently got: Nov 30 06:25:02.803 [notice] Tor 0.2.1.6-alpha (r17011) opening new log file. Nov 30 06:25:02.818 [warn] eventdns: Unable to add nameserver 164.148.169.81: error 2 Nov 30 06:25:02.818 [warn] eventdns: Unable to add nameserver 34.148.169.81: error 2 Nov 30 06:25:02.818 [warn] Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (6) Nov 30 06:25:02.819 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. The nameservers were indeed unreachable at that time (the traffic limit was reached and the system offline), but earlier Tor versions continued to run and started working again once the system was back on the net. This was bug 691; it should be fixed in 0.2.1.9-alpha when it comes out. https://bugs.torproject.org/flyspray/index.php?id=691do=details This is probably a good time for me to encourage people to use the bugtracker at bugs.torproject.org to report and track bugs. It lets us do a better job of collecting and consolidating information about each bug, and of making sure that nobody forgets about it until it gets fixed. yrs, -- Nick
Re: Tor-Vidalia communication
Should I raise this as a bug at Flyspray? Vidalia can see relay status etc, and shut down Tor without the password being entered. They are both running as the same user however. GD On 8 Dec 2008, at 12:26, Geoff Down wrote: OSX10.3.9 , and yes, I was able to change identity, see the network map etc. GD On 8 Dec 2008, at 06:51, Jon wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Geoff Down wrote: Hi, previously, if I started Vidalia when Tor was already running, I would be asked for the password. Has this changed in 0.2.0.32 ? The torrc's I use for Vidalia or for the command line are different (and therefore the passwords are different). GD What operating system, and is vidalia successfully communicating with one instance or the other when you are *not* prompted for the pass? Jon- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk8w/EACgkQk8jp5ZVximL7DgCghwbh96IklKHHMOBRy6kTpZLU A7QAn2w5s0qkS8jBGPr+heSk4ZskVyl8 =5HLm -END PGP SIGNATURE-
Re: Tor-Vidalia communication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Geoff Down wrote: Should I raise this as a bug at Flyspray? Vidalia can see relay status etc, and shut down Tor without the password being entered. They are both running as the same user however. GD On 8 Dec 2008, at 12:26, Geoff Down wrote: OSX10.3.9 , and yes, I was able to change identity, see the network map etc. GD On 8 Dec 2008, at 06:51, Jon wrote: Geoff Down wrote: Hi, previously, if I started Vidalia when Tor was already running, I would be asked for the password. Has this changed in 0.2.0.32 ? The torrc's I use for Vidalia or for the command line are different (and therefore the passwords are different). GD What operating system, and is vidalia successfully communicating with one instance or the other when you are *not* prompted for the pass? Jon- It might do in the bug system yes, but I'm not actually sure if it goes into trac or flyspray actually. I wanted to help localize it first. Actually, I thought you were running two tor processes at the same time, and I was wondering which one it connected? Jon- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAklDF7EACgkQk8jp5ZVximLgFwCgjAoW7figucer0USMxS46mAPK PMoAmJbt0AvzrpmTSo09NnaeS8CS4BY= =0mgb -END PGP SIGNATURE-
