Is there a defined timeout for the TOR control protocol? How long should a control port client wait around for socket data when reading? Or writing? The only references to timeouts that I find in control-spec.txt are about circuit and stream timeouts reported back through the control port.
Is there a defined timeout for the TOR control protocol? How long should a control port client wait around for socket data when reading? Or writing? The only references to timeouts that I find in control-spec.txt are about circuit and stream timeouts reported back through the control port.
I'm not aware of one (though that certainly doesn't mean there isn't any). What in particular are you trying to solve? -Damian
On Sun, Jun 19, 2011 at 9:55 AM, Damian Johnson atagar1@gmail.com wrote:
Is there a defined timeout for the TOR control protocol? How long should a control port client wait around for socket data when reading? Or writing? The only references to timeouts that I find in control-spec.txt are about circuit and stream timeouts reported back through the control port.
I'm not aware of one (though that certainly doesn't mean there isn't any). What in particular are you trying to solve? -Damian
I've been looking at TorUtil.BufSock.readline() and the problems atagar has found. I have found similar problems and I would like to solve this issue.
The recent merges mikeperry did from you and atagar do not really fix the problem (as I see it). atagar's timeout was way too short in my testing. And your commits returned the tree to a blocking socket mode.
I would like to have readline() detect when a socket error has occurred. My research indicates that timeouts are the only reliable method to decide a problem has occurred with a socket. But, there seems there is no guidance from the TOR docs about how long a client should wait for a reply from the TOR daemon.
you and atagar...
I am atagar.
atagar's timeout was way too short in my testing.
I picked 20 ms because that's the runtime for fast queries, like 'GETINFO version'. There was a tradeoff in picking the timeout duration, but since it was within a loop it didn't impact correctness. Lowering meant more work (looping rather than sleeping on input) and higher meant a raised shutdown time.
This said, a later change to shut down the socket unblocked the recv call when closing, so this timeout was removed.
I have found similar problems and I would like to solve this issue.
All the concurrency issues for shutting down should have been addressed. What sort of problems are you encountering? Do you have a use case for reproducing the issue?
I would like to have readline() detect when a socket error has occurred.
A socket error should result in a None return value that shuts down _thread.
Cheers! -Damian
On Sun, Jun 19, 2011 at 11:18 AM, Damian Johnson atagar1@gmail.com wrote:
you and atagar...
I am atagar.
LOL! It's a small world, eh?
All the concurrency issues for shutting down should have been addressed. What sort of problems are you encountering? Do you have a use case for reproducing the issue?
I had not done more testing since the socket.shutdown() was added. Now I have tested and I no longer have TOR connections hanging. Thank you.
I would like to have readline() detect when a socket error has occurred.
A socket error should result in a None return value that shuts down _thread.
As long as the socket error is local, then None is returned. I was concerned about remote (silent) errors going undetected. But, further tests (e.g. 10 minute timeout) also did not work on a long-running client listening for TOR events. I now believe that absent a defined keep-alive framework in the control protocol, it is best for any client which cares to check the connection status to periodically run a small query (i.e. "GETINFO version") and check for a response.
-
Damian Johnson -
Sean Robinson