What does setSoTimeout ( int timeout ) in Socket class do?
In the API, this method is describe as:
Enable/disable SO_TIMEOUT with the specified timeout, in milliseconds. With this option set to a non-zero timeout, a read() call on the InputStream associated with this Socket will block for only this amount of time. If the timeout expires, a java.net.SocketTimeoutException is raised, though the Socket is still valid. The option must be enabled prior to entering the blocking operation to have effect. The timeout must be > 0. A timeout of zero is interpreted as an infinite timeout.
I have problem understanding it. It say that the Socket will block for the amount of time set. What does 'block' means? Does it mean that the socket waits for the predefined time to receive data packet? Or just wait to receive data packet? Or both? Or I've got it wrong altogether?
Sorry but as you can see, I'm still clueless about many things regarding Java. Thank you for your time and patience.
Message was edited by:
Toc
[996 byte] By [
Toca] at [2007-10-3 8:56:56]
You got it correct. To block means that the read() method will wait until it actually receives something (the thread will pause its execution). With that timeout, it won't wait forever (in case nobody sends anything), but only until the timeout is reached and then throws an exception instead of returning a value.
Thanks. I have a couple more questions regarding this matter.
While the socket waits to receive a data packet, can we in the meantime use the socket to send out data packet?
We should use setSoTimeout whenever we are expecting to receive a data packet so that it doesn't wait indefinately?
Thanks once again.
null
Message was edited by:
Toc
Toca at 2007-7-15 4:07:16 >
Yes and yes.
ejpa at 2007-7-15 4:07:16 >
>We should use setSoTimeout whenever we are expecting to receive a data packet so that it doesn't wait indefinately?That depends. Most of the time, the answer is 'yes'. But for some applications (web servers, mail servers, etc) it's acceptable for a socket to wait
I think you've misunderstood the OP's question, but in any case I strongly disagree. I believe it is never acceptable for a socket read to wait indefinitely. TCP can fail in ways which can only be detected by a timeout when reading. And the examples you've given are precisely examples of applications that shouldn't tie up (i.e. leak) resources for arbitrarily long periods of time.
ejpa at 2007-7-15 4:07:16 >
> I believe it is
> never acceptable for a socket read to wait
> indefinitely. TCP can fail in ways which can only be
> detected by a timeout when reading.
I do telnet client kind of stuff and I do not use SO_TIMEOUT.
Could you elaborate on this? In my case, what kind of things can
happen and go undetected? If the user does not type anything for
10 minutes (out for a coffee), I feel that using a SO_TIMEOUT of,
let's say, 1 minute, amounts to polling, which I always try to avoid
as much as possible. If the connection fails somehow, wouldn't
my pending blocking read() always return -1 or throw an exception?
Thanks!
If your 1-minute timeout is too short, increase it!
For Telnet I would use something more like 30-60 minutes, and in fact most Telnet servers also enable TCP keepalive so they will detect outages after two hours anyway.
If you just disconnect the cable while doing a blocking read with infinite timeout the read may or may not return, and if it does it may or may not throw an exception.
This is all platform-dependent, and some of it depends on the peer platform, not your own. I've seen Novell servers crash in ways where the TCP/IP stack was still running even though the application I was talking to was certainly dead, and there was no way to tell, at least until the next keepalive, assuming the platform supports it.
ejpa at 2007-7-15 4:07:16 >
Thanks for the info!I will try the cable thing as soon as I get back to the office.
Thanks you all for the answering my questions and the extra information. This is great. Thank you.
Toca at 2007-7-15 4:07:16 >
Old thread, but now I face the problem.
My socket does not use SO_TIMEOUT and a cable disconnect is
not detected. Suppose I change my code to use SO_TIMEOUT,
can anyone tell me what is the reliable way to find if the
socket is still connected? I mean, what should I do in the
SocketTimeoutException handler, before returning to read().
isConnected()
isClosed()
Just do the next read(), it will fail
Thank you!
Message was edited by:
baftos
> I mean, what should I do in the
> SocketTimeoutException handler, before returning to
> read().
>
> isConnected()
No. This just tells you whether you have ever connected your end of the socket. As you've just done a read the answer will always be 'yes'.
> isClosed()
No. This just tells you whether you have ever closed your end of the socket. As you've just done a read without getting a closed-socket exception the answer will be 'no'.
> Just do the next read(), it will fail
It has already failed. What exactly is the problem here? You were expecting a response within N seconds. You didn't get it. So, proceed accordingly. If you choose N such that the peer has had twice the expected time to respond and hasn't responded you can probably assume that the connection is dead on a timeout, but what N is and exactly what timeout means to your application is strictly up to you.
The only reliable way of detecting a dead TCP connection is to try to write to it.
ejpa at 2007-7-15 4:07:16 >
