I'm running SilverTunnel-NG to do some requests on a Google API which first works fine. I could use a little help with an unexpected behaviour that i get. After several dozen requests, the log shows a SocketTimeoutException. After this, the request ist not executed, nor does anything else happen except of the log message "TorBackgroundMgmtThread.spawnIdleCircuits: Spawn 0 new circuits" and again SocketTimeoutExceptions. Maybe this STE's are not even the root of all evil - they occur also earlier and don't stop the program flow.
I'm running SilverTunnel-NG 0.0.1 under JDK 1.8.0 ea b118 64Bit on a Windows 7 Machine.
Here's the log(excerpt):
P.S. Good job - i didn't think it could be so easy to use Tor within a Java Application :)
Best regards,
David
Edit : (by Tobias) for better readability I've copy&pasted the log parts into a txt file and attached it to the thread.
Your problem could also be that google is blocking your used Exitnode. (the identity currently is only changing after the used circuit is closed or not useable anymore)
An other possibility is that if you are using the standard configuration, the circuit buildup could take too much time because of the circuit lenght.
You could try to set the route length to something smaller (default is 3 - 5).
When you just need to obfuscate your IP and dont need the full security/anonymity you could set the min and max route length to 2. This would speed up your Circuit creation and also the processing while using Tor.
regards Tobi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the quick reply, i'll try out your proposed configuration changes today. For your test, i've got a remark: In my case, the error occurs mostly in betweeen the 70th and 150th request. I can only remember a single time that the behaviour occurred after less than 50 requests.
I'll keep you up to date ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Okay, i tried it but i had no success. I also tried with your snapshot from yesterday, which actually seems to make the situation better - i can now do around 250 request until the crash comes - but it doesn't fix it. I would find it helpful to get an exception thrown which i can handle. I would just build up another connection in that case as a workaround.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the updates.
I think I've found the problem which you are currently facing.
It seems to connection to the first node in the circuit when building a new circuit.
This should normally not happen and should be handled by netlib so passing an Exception would not be good.
But creating 2 or more circuits in paralel and return the one which has been created succesfully would solve this issue.
I've also made some modifications which should also solve some of the Sockettimeout's.
In my test of 1000 iterations I only had 2 timeouts.
Could you rerun your code with the newest SNAPSHOT?
Thanks and regards,
Tobi
P.S.: sorry for answering this late but there's christmas everywhere ;)
Last edit: Tobias Boese 2013-12-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The new functionality is added to snapshot version 0.0.3
If you still have problems try using TorConfig.setParallelCircuitBuilds(2) (before making any calls to netlib)
This should solve your issue and always returns the fastest Circuit (using a higher value would use more resources but you could get faster circuits as a result)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks a lot! I was testing it - unfortunately with almost the same results as before. I'm suspicious now, so i'll test it on another machine in the next days and let you know about it.
Have a nice start of 2014!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My guess is that the TLS connection to the first router is not timing out as it should.
The first router in the chain doesnt seem to accept the connection, as the TCPIPNetLayer (which is used by the TLS connection) doesnt have a default timeout (yet) it could wait there forever.
Could you try to set the following property before executing any of the SilverTunnel-NG code?
property to set : TcpipNetLayer.timeoutInMs
value : 5000
i just wanted to try your new advise with the first Snapshot of this year. Doing so, i saw that i can't connect anymore. I'm trying to connect with this piece of code:
~~~~~
netLayer = NetFactory.getInstance().getNetLayerById(NetLayerIDs.TOR);
netLayer.waitUntilReady(); //error messages in log occur here
factory = new NetlibURLStreamHandlerFactory(false);
factory.setNetLayerForHttpHttpsFtp(netLayer);
~~~~~~
This results in the attached log output telling that there is some problem with an outdated DirectoryConsensus.
i tried again and deleted the tmp-files. Now the project itself works again, but with the suggested property change, it's hanging up even after a few requests (mostly <20)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi there!
I'm running SilverTunnel-NG to do some requests on a Google API which first works fine. I could use a little help with an unexpected behaviour that i get. After several dozen requests, the log shows a SocketTimeoutException. After this, the request ist not executed, nor does anything else happen except of the log message "TorBackgroundMgmtThread.spawnIdleCircuits: Spawn 0 new circuits" and again SocketTimeoutExceptions. Maybe this STE's are not even the root of all evil - they occur also earlier and don't stop the program flow.
I'm running SilverTunnel-NG 0.0.1 under JDK 1.8.0 ea b118 64Bit on a Windows 7 Machine.
Here's the log(excerpt):
P.S. Good job - i didn't think it could be so easy to use Tor within a Java Application :)
Best regards,
David
Edit : (by Tobias) for better readability I've copy&pasted the log parts into a txt file and attached it to the thread.
Last edit: Tobias Boese 2013-12-09
Hi David,
I did also ran once or twice into this issue :(
The sad thing is I didnt found the root cause yet, but I'm on it.
The good thing is that I created a new Unittest trying to connect to a site 50 times in a row and it worked flawlessly (with the latest snapshot).
Checkout : TorConnectionsRemoteTest.java
Your problem could also be that google is blocking your used Exitnode. (the identity currently is only changing after the used circuit is closed or not useable anymore)
An other possibility is that if you are using the standard configuration, the circuit buildup could take too much time because of the circuit lenght.
You could try to set the route length to something smaller (default is 3 - 5).
When you just need to obfuscate your IP and dont need the full security/anonymity you could set the min and max route length to 2. This would speed up your Circuit creation and also the processing while using Tor.
regards Tobi
Thanks for the quick reply, i'll try out your proposed configuration changes today. For your test, i've got a remark: In my case, the error occurs mostly in betweeen the 70th and 150th request. I can only remember a single time that the behaviour occurred after less than 50 requests.
I'll keep you up to date ;)
Okay, i tried it but i had no success. I also tried with your snapshot from yesterday, which actually seems to make the situation better - i can now do around 250 request until the crash comes - but it doesn't fix it. I would find it helpful to get an exception thrown which i can handle. I would just build up another connection in that case as a workaround.
Thanks for the updates.
I think I've found the problem which you are currently facing.
It seems to connection to the first node in the circuit when building a new circuit.
This should normally not happen and should be handled by netlib so passing an Exception would not be good.
But creating 2 or more circuits in paralel and return the one which has been created succesfully would solve this issue.
I've also made some modifications which should also solve some of the Sockettimeout's.
In my test of 1000 iterations I only had 2 timeouts.
Could you rerun your code with the newest SNAPSHOT?
Thanks and regards,
Tobi
P.S.: sorry for answering this late but there's christmas everywhere ;)
Last edit: Tobias Boese 2013-12-11
The new functionality is added to snapshot version 0.0.3
If you still have problems try using TorConfig.setParallelCircuitBuilds(2) (before making any calls to netlib)
This should solve your issue and always returns the fastest Circuit (using a higher value would use more resources but you could get faster circuits as a result)
Hi Tobi,
thanks a lot! I was testing it - unfortunately with almost the same results as before. I'm suspicious now, so i'll test it on another machine in the next days and let you know about it.
Have a nice start of 2014!
Hi David,
I maybe found the solution to your issue.
My guess is that the TLS connection to the first router is not timing out as it should.
The first router in the chain doesnt seem to accept the connection, as the TCPIPNetLayer (which is used by the TLS connection) doesnt have a default timeout (yet) it could wait there forever.
Could you try to set the following property before executing any of the SilverTunnel-NG code?
property to set : TcpipNetLayer.timeoutInMs
value : 5000
You could do this by just executing
Regards and
happy new year! ;)
Tobi
Hi Tobi,
i just wanted to try your new advise with the first Snapshot of this year. Doing so, i saw that i can't connect anymore. I'm trying to connect with this piece of code:
~~~~~
netLayer = NetFactory.getInstance().getNetLayerById(NetLayerIDs.TOR);
netLayer.waitUntilReady(); //error messages in log occur here
factory = new NetlibURLStreamHandlerFactory(false);
factory.setNetLayerForHttpHttpsFtp(netLayer);
~~~~~~
This results in the attached log output telling that there is some problem with an outdated DirectoryConsensus.
Last edit: kokyo 2014-01-31
Hi,
this is a known issue ive already created a ticket for that but didnt had time to fix it yet :(
As a workaround you can go to your temp-folder and delete everything which matches st-*
then it should work again.
regards Tobi
Thanks again, Tobi. I'll try that as soon as i'm in the office at monday. Enjoy your weekend!
Hi Tobi,
i tried again and deleted the tmp-files. Now the project itself works again, but with the suggested property change, it's hanging up even after a few requests (mostly <20)