Basically am a newbie to socket programing. i would like to know about how to close a socket if stays idle for a specified time interval. i searched on net about this ,i found that function which is used to close the socket after the specified interval. but here in my case , i would like to close the socket only when it is stays Idle for more than the specified interval
I searched on net about this
Why? The Javadoc exists. No searching necessary.
I found that function which is used to close the socket after the specified interval
There is no such method.
I saw about setSoTimeOut(2000) function which closes the socket after the specifed time interval
No it doesn't. It doesn't close the socket at all, and it causes read methods to throw a SocketTimeoutException if no data arrives within the timeout period.
but I would like to close only if the socket remains idle for the specified interval
Socket.setSoTimeout() is exactly what you need.
the client establishes the connection with the server and then later after sometime it the client close the socket connection at its side after performing the required task and creates a new connection the next time when it pings, where as my server does not close the connection and it keeps on listening to that client
In other words your server is ignoring end of stream on the socket. Don't do that. Close the socket if you get end of stream from a read method.
Related
Im developing a TCP socket in Java, and I want to make the connection between server and client open all the time until it has passed some time, and then the connection close and wait for a new accept, how can I implement it by a while with a timer? Also, can I make that if the client or the server has not made any coomunication after passing some time, then the connection close?
I try to do it by setSoTimeout, but it only works with the accept, so is there any method that allows you to close the connection after some time?
Try using socket.settimeout(time).
Alternatively, get the system time when the socket was opened, and the current system time, and if the difference is a specific amount of time, close the socket.
My SocketServer first listens for at least 4 Socket connections before creating a WorkerThread where all four connections are served. And in the same thread, all 4 sockets will be opened to perform communication with connected clients.
Now, consider a situation where server has already accepted two socket connections, but listening to remaining 2 clients, before it can proceed with creating thread.
And while that listening phase, the connected clients are shown "Waiting..." message (since server has not yet opened the sockets to send any response back to clients, and socket.readObject() is blocking at client-end), till the server gets all 4 clients to work with. And in the meantime, one of the "already-connected" client kills that "Waiting..." thing, and closes the client app. In such a case, my WorkerThread will fire an exception due to dead socket supplied, when it attempts to open it.
How can I know if a socket is pointing to nothing (since client is lost) without having to open the socket? (since if I open it from main thread, I'll not be able to open it again from WorkerThread, where it is actually supposed to be used).
If I get to know if Socket is dead, I can get server back to listening and attempt to get 4 connections, before it proceeds creating a thread.
I know my SocketServer will be stuck at accept() so even if its possible to check what I asked above, I'll have to create another thread that monitors liveliness of already "accepted" socket connections.
Update
I mean by not opening the socket is something like below.
Socket s = ss.accept();
/* I'll not be doing as below, since once I close InputStream and OutputStream in main Thread, I can't open in WorkerThread.
But I still want to know if Socket s is connected to client, before I start WorkerThread.
ObjectInputStream in = new ObjectInputStream(s.getInputStream());
ObjectOutputStream out = new ObjectOutputStream(s.getOutputStream());
String msg = in.readObject().toString();
System.out.println("Client Says:");
out.writeObject("success");
in.close();
out.close();
*/
new WorkerThread(s).start();
And note that my server is accepting 4 such connections, and when 4 sockets are accept()ed, it passes all 4 in WorkerThread's constructor, and gets back to accept() another 4 clients.
I think you just need to handle your acceptions better. You should handle the IOException correctly whenever you try to read or write to the socket.
One option is to have the accepting code send a "still waiting" message to the client and get an acknowledge every so often while you are waiting for the other connections. The socket and associated streams have already been created by the accept() so you can do this, call flush() on the OutputStream, and then hand off to the handler.
As long as you don't call close() on the streams, you should be able to re-use them without a problem. You just can't have two different threads using the streams at the same time.
I have a thread for each connection on the server-side. When the client is not sending commands, the server thread is blocking:
while ((commandHeader = fromNode.readLine()) != null) {
which internally calls readLine() on an OutputStream obtained from the TCP socket.
When I call socket.close() from another thread, this calls wakes up with a SocketException and the thread can be terminated.
However, if a client than wakes up and decide to issue a command, it executes
stream.writeBytes("something\n");
which blocks indefinitely. I understand this is probably fine for TCP (it's just an half-close.)
I should probably send something to the client upon quitting, like "QUIT\n"; it could also just read an EOF. But if I call readLine() or other read operations on the client before sending the command, they block waiting for data when the connection is not closed.
How can the client detect that the connection has been half-closed before trying to write to it?
When socket.close() is called on server the underlying TCP connection is closed with the typical FIN/FIN-ACK sequence plus RST packets, so the client will know. When the client calls stream.writeBytes() afterwards it should fail. If it doesn't it means there has been some missing packets and the connection eventually will fail anyhow.
First i think your application logic should be such that to avoid Half Open TCP connection. You can think of adding timer on client side so that if nothing received it starts polling the server again.
From server point of view, another option is to set timer on the readLine. Make another method for readLine where you set a timer and if it excedes certain time, simply return some default value to the while loop.
EDIT:
You might want to read this article specially the section: What about threads blocked on IO?
I'm having a problem with a library that I am using. It might be the library or it might be me using it wrong!
Basically, when I do this (Timeout in milliseconds)
_ignitedHttp.setConnectionTimeout(1); // v short
_ignitedHttp.setSocketTimeout(60000); // 60 seconds
No timeout exception is generated and it works ok, however, when I do the following,
_ignitedHttp.setConnectionTimeout(60000); // 60 seconds
_ignitedHttp.setSocketTimeout(1); // v short
I get a Socket Exception.
So, my question is why can I not simulate a Connection Exception? Am I misunderstanding the difference between a socket and a connection time-out? The library is here (not officially released yet).
A connection timeout occurs only upon starting the TCP connection. This usually happens if the remote machine does not answer. This means that the server has been shut down, you used the wrong IP/DNS name, wrong port or the network connection to the server is down.
A socket timeout is dedicated to monitor the continuous incoming data flow. If the data flow is interrupted for the specified timeout the connection is regarded as stalled/broken. Of course this only works with connections where data is received all the time.
By setting socket timeout to 1 this would require that every millisecond new data is received (assuming that you read the data block wise and the block is large enough)!
If only the incoming stream stalls for more than a millisecond you are running into a timeout.
A connection timeout is the maximum amount of time that the program is willing to wait to setup a connection to another process. You aren't getting or posting any application data at this point, just establishing the connection, itself.
A socket timeout is the timeout when waiting for individual packets. It's a common misconception that a socket timeout is the timeout to receive the full response. So if you have a socket timeout of 1 second, and a response comprised of 3 IP packets, where each response packet takes 0.9 seconds to arrive, for a total response time of 2.7 seconds, then there will be no timeout.
We are doing FTP connection through our applicaion which is a JAVA aplication.
We have set timeout for connection using Socket.connect(Adreess,timeout) method before calling FTPClient.connect() method.
During retriving files from the FTP site under same connection we havent set any timeout. Is it mandatory to call method FTPClient.setSoTimeOut(timeout) method to set individual time out for each such interaction under same connection or Socket.connect(Adreess,timeout) method will set timeout for each interaction with FTP site under one connection?
I would also like to know What is the difference between these two methods?
The timeout in Socket.connect() is connect timeout, which is the time to wait for TCP handshake to finish. This timeout only occurs once per connection.
setSoTimeout() is called socket read timeout, which is how long you wait to read pending bytes from socket. This occurs on every socket read throughout the TCP session.
It's good practice to set both timeout value so you don't rely on system defaults, which may vary. However, the timeout may not work sometimes when the call is stuck in native code. For example, the connect timeout is not honored if firewall silently drops packet.