Detecting socket closure

Is there a way of telling from a java.net.Socket object if it is no longer connected to another socket? I have tried isBound, isConnected, and isClosed.
Say my socket has connected, done some processing, and the other end disconnects on me - is there a way of telling at a point in the future if this is the case?isBound, isConnected, and isClosed all seem to return previous state, i.e. isConnected always returns true if the socket has been connected, not if it is currently connected.
Any ideas?
D
p.s. I know I could catch some sort of exception but in my particular scenario I would prefer to avoid using that approach

I've got the same problem.
I've developed a java based HTTP client which can access a variety of web servers - most of which I can happily access. For some reason IIS sends a FIN TCP packet in certain situations. I need to detect in my client that the socket has been closed by the server. However trying all 3 methods - always gives the result that it believes the connection is still open. So when I next send a HTTP request to the server (on the socket I believe is still open) I get back a RST TCP packet. The result being that the BufferedReader.readline() method return NULL to my application.
Any ideas of a fix?
John

Similar Messages

Java 1.3.1 and Detecting Socket Closure (A Popular Question, I Know)

Hi, all. I've been skimming the web looking at various commentary on how it is impossible to detect whether or not a Socket has closed without calling the read of Socket.getInputStream() or the write of Socket.getOutputStream(). I wrote a networking package some months ago that would spawn one Thread for each Socket so I could spare the Threads to block on the I/O, thus following this suggestion. I also understand that Java 1.4 contains various elements of the java.nio package that are supposed to take care of nonblocking I/O. I think, however, that this is entirely possible with Sockets in Java 1.3.1.
I wrote a program that calls Socket.setSoTimeout(), setting the timeout of the socket to 1 millisecond. I then have one Thread looking at a series of open Sockets. The Thread calls the read method on each of the Sockets' InputStream objects and does one of three things based upon the result:
If the result is a successful read, the data is handled as is appropriate.
If the result is a -1, the Socket has been closed and is formally shut down on this side.
If the result is an InterruptedIOException, the Socket is open but has no available data.
The Socket is then ignored until the next pass.
I've tested this idea on an Athalon XP 2100+ and not seen a significant use of processing power.
Therefore, my question is as follows: what's wrong with this idea? We've looked at it and it seems to be an appropriate solution to the problem. Yet, I've seen little mention of this way to work around blocking Socket I/O in Java 1.3.1. It seems appropriate and certainly cuts back on Thread overhead... but does anyone see a catch?
Thanks! Best of luck!

This approach to multiplexing seems to not work under the 1.3.1 release for Windows. I have found I still get a -1 on my input stream read, instead of the InterruptedIOException. It's pretty frustrating.
The axact same code appears to work fine on Linux . So this may be dependent on the native code layer for the sockets implementation, or we may be encountering a bug in our or Sun's code. I haven't found documentation of the expected behaviour of the SocketInputStream (the actual class returned by Socket.getInputStream) or the socket implementation in general for each platform.
Note that in general, your approach is not really scalable for the kind of situations the Non-blocking IO package was introduced for. Your approach means that 500 sockets will have a 1/2 second intrinsic delay. You would have to start thread-pooling, etc. You can see why something like an internet audio streaming application would benefit from lower level support in the java libraries.
Neil

How to detect the closure of browser window at the client side?

Hi,
Does anyone know how I can detect the closure of the browser window at the client side from the server side?
Please advise.
Damien

Basically you can't. People will suggest various Javascript things you could try, but they don't work reliably. So don't try, just make a design that doesn't require knowing that.

Detecting socket disconnections

Hi!
Im using a ServerSocket to enable clients to connect to my
application. The communication over the returned Socket works
fine, but I cannot detect when the client disconnects. The
socket is put on a CLOSE_WAIT state, and according to socket
sources this means that the client is expecting the final last
ack (LAST_ACK) from me. The LAST_ACK is sent if I close() the
socket.
The problem is that I cannot detect disconnection in my app without
actually trying to send some "garbage" data on the socket.
I then get an exception, of course. Is there any clean way
to implement this?
Thanks!
Regards,
Lars Ove Claesson

Hi!
Im using a ServerSocket to enable clients to connect to my
application. The communication over the returned Socket works
fine, but I cannot detect when the client disconnects.
The socket is put on a CLOSE_WAIT state, and according to
socket sources this means that the client is expecting the
final last ack (LAST_ACK) from me. The LAST_ACK is sent if I
close() the socket.Not exactly although the result is the same.
The server is in the CLOSE_WAIT state. That means that the application is supposed to close the socket. Once it does it sends a FIN to the client and then moves to the LAST_ACK state (waiting for the client to ACK the FIN.) The client of course would be waiting for the FIN.
>
The problem is that I cannot detect disconnection in
my app without
actually trying to send some "garbage" data on the socket.
I then get an exception, of course. Is there any clean
way to implement this?As mentioned the blocking read should do this.
Myself I always prefer to explicitly send a "end" message from the client (or server.) That way I handle it explicitly rather that relying on something else.

Intermittent socket closure

Hello,
I have implemented a simple client program that receives a continual stream of data from a TCP socket. Very simple. During time spans when traffic is high, I receive a -1 (negative one) return value from socket.inputstream.read( byte[] ) nearly every half hour. Initially I assumed that the server was closing the socket, but later I realized that simultanious sockets I'd established to the same server process via netcat and telnet would happily exist for several days at a time.
Additionally, I implemented a proxy process in python that distributes the data from a single socket to several clients at once. As before, netcat sub-clients received the data continually without errors while the code below eventually returned -1 from read(). This suggests to me that something about the data in this stream is causing the java client to think the socket has been closed, when it hasn't, or that the java client is electing to shutdown the socket without explicit instruction.
I cannot determine what is different between the java socket and the sockets used by netcat/telnet that would account for this. Any corrections to my code snippet or suggestions for debugging the problem would be greatly appreciated. Particularly I'd like to know how I could determine "where" the decision is being made that the end-of-stream has been reached (libc vs java vs OS, for instance).
Code snippet follows.
Thanks
Michael
int BUFFER_SIZE = 20000;
Socket socket = new Socket( server, port );
socket.setKeepAlive( true );
InputStream stream = socket.getInputStream();
byte[] bbuffer = new byte[ BUFFER_SIZE ];
while( true )
int bytesRead = stream.read( bbuffer );
if( bytesRead == -1 )
/* close, re-open socket */
else
/* handle bytes */
}

It definitely isn't a firewall or bandwidth issue. The stream comes over a T1, which is more than enough to handle the data. Plus, there are simultanious clients being feed off of the same python proxy I implemented that do not have this problem. The data transfered is bit for bit the same for every client, with the exception of the bytes missed by the java client when the socket closes. The key thing to note is that the data can pass through python into netcat without incident, but the java client is affected the same as if it were connected directly.
I reduced the BUFFER size significantly and that does seem to help alleviate the problem. The number of "-1 == read()" occurances is roughly half with the same data. Still, since read() should block, there shouldn't be any problem with running out of data in the stream. It's very perplexing.
The sniffer suggestion is a great one. I think that I'll do that today and see if I can widdle out something reproducible.
One thing I noticed is that the problem increases when the code is run as an app-server mbean (jboss). I am confident that my code is thread safe, but I'm worried that perhaps the underlying java implementation isn't. Working against this is the fact that I was able to reproduce it will 1.3.1, 1.4.1, and 1.4.2 vm's. The same bug would have to exist in all version, but I was under the impression that with 1.4.* the socket code was significantly changed. Also of note is that this is reproducable on Solaris and Linux.

Best way to repaint/refresh JFrame classes.

Hello everyone,
I am developing a small application for my studies. I have several classes many representing a user form allowing interaction with my system.
One of my first class instances is a Menu Screen from which the user can for example update their details. When the Update Details frame is closed by the user I invoke
frameName.setVisible(false);
frameName.dispose();This removes the Update Details frame and the Menu Screen is now fully visible.
However this screen does not get refreshed and remains partially obscured by the background color of the JFrame, even if I bring say a browser to the foreground and then click the original Menu Screen to the foreground it does not refresh the Menu Screen and remains half painted.
I was wondering about a few things.
1. Is there a way of detecting when the current JFrame has just received the focus, at which point I could repaint the screen.
2. Is there a way of Menu Screen discussed above being able to detect the closure of the Update Details JFrame (a separate class) and then take appropriate steps to repaint/refresh itself.
3. Ideally what I would like to do is Hide the Menu Screen then allow the user to interact with their menu selection and then Un-hide the Meun Screen when the user is done interacting with their menu selection.
4. Are there any tutorials on this type of thing, that anynone could direct me to.
Thank you for your consideration.
Cheers
Mark

Hello everyone,
I am developing a small application for my studies. I
have several classes many representing a user form
allowing interaction with my system.
One of my first class instances is a Menu Screen from
which the user can for example update their details.
When the Update Details frame is closed by the user I
invoke
frameName.setVisible(false);
frameName.dispose();This removes the Update Details frame and the Menu
Screen is now fully visible.
However this screen does not get refreshed and remains
partially obscured by the background color of the
JFrame, even if I bring say a browser to the
foreground and then click the original Menu Screen to
the foreground it does not refresh the Menu Screen and
remains half painted.
I was wondering about a few things.
1. Is there a way of detecting when the current JFrame
has just received the focus, at which point I could
repaint the screen.
2. Is there a way of Menu Screen discussed above being
able to detect the closure of the Update Details
JFrame (a separate class) and then take appropriate
steps to repaint/refresh itself.
3. Ideally what I would like to do is Hide the Menu
Screen then allow the user to interact with their menu
selection and then Un-hide the Meun Screen when the
user is done interacting with their menu selection.
4. Are there any tutorials on this type of thing, that
anynone could direct me to.
Thank you for your consideration.
Cheers
Mark

Authetication problem in client/server app

I am presently developing a client/server program, and I'm wondering what will be the best form of authentication. I plan to develop a protocol for the programs, any deviation leading to socket closure. I thought about signatures, but I don't think any body's ready to vouch for me(ie I don't know how to go about signatures). Is there any help?

Learn about JAAS

Sockets: How can server detect that client is no longer connected?

Hi,
I really need help and advice with the following problem:
I have a Client - Server socket program.
The server listens on port 30000 using a server socket on one machine
The client connects to localhost on port 20000, previously creating an ssh port forward connection using the Jsch package from www.jcraft.com with
"session.setPortForwardingL(20000, addr, 30000);"
Then the client sends Strings to the server using a PrintWriter.
Both are connected to each other through the internet and the server uses a dynamic dns service.
This all works well until the IP address of the Server changes, The client successfully reconnects to the server using the dynamic dns domain name, but the server keeps listening on the old socket from the previous connection, while opening a new one for the new client connection. The server doesn't seem to notice that Client has disconnected because of this IP address change.
looks like the server is stuck inside the while loop. If i cut the connection manually on the client side, the server seems to notice that the client has disconnected, and jumps out of the while look (see code below)
this is the code I'm using for the server:
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.Socket;
import java.util.logging.Logger ;
public class SocketHandler extends Thread {
    static Logger logger = Logger.getLogger("Server.SocketHandler");
    private Socket clientSocket = null;
    private BufferedReader in = null;
    private InputStreamReader inReader = null;
    public SocketHandler(Socket clientSocket) throws IOException {
        this.clientSocket = clientSocket;
        inReader = new InputStreamReader(clientSocket.getInputStream ());
        in = new BufferedReader(inReader);
    public void run() {
        try {
            String clientMessage = null;
            while ((clientMessage = in.readLine()) != null) {
                logger.info("client says: " + clientMessage);
        } catch (IOException e) {
            logger.severe(e.getMessage());
            e.printStackTrace();
        } finally {
            try {
                logger.info("closing client Socket: " + clientSocket);
                clientSocket.close();
                in.close();
                ServerRunner.list.remove(clientSocket);
                logger.info("currently "+ServerRunner.list.size()+" clients connected");
            } catch (IOException e) {
                logger.severe (e.getMessage());
                e.printStackTrace();
}I've tried making the server create some artificial traffing by writing some byte every few seconds into the clients OutputStream. However I get no exceptions when the IP address changes. The server doesn't detect a disconnected socket connection.
I'd really appreciate help and advice

If a TCP/IP peer is shut down "uncleanly", the other end of the connection doesn't get the final end of connection packet, and read() will wait forever. close() sends the final packet, as will killing the peer process (the OS does the close()). But if the OS crashes or for some other reason can't send the final packet, the server never gets notification that the peer has gone away.
Like you say, one way is timeout, if the protocol is such that there always is something coming in at regular intervals.
The other way is a heartbeat. Write something to the other end periodically, just some kind of "hello, I'm here, ignore this message". The other end doesn't even have to answer. If the peer has gone away, TCP will retransmit your heartbeat message a few times. After about a minute it will give up, and mark the socket as broken. read() will then throw an IOException. You could send heartbeats from the client too, so that the client detects if the server computer dies.
TCP/IP also has a TCP-level heartbeat; see Socket.setKeepAlive(). The heartbeat interval is about two hours, so it takes it a while to detect broken connections.

How can I detect arrival of data on socket?

I have written a bean which uses a (client) socket to send data to a socket server program. This works fine.
My problem is that I also want the bean to be able to detect the arrival of data on its socket without going into a read loop.
From what I have read, I think I need to set up some sort of a listener to trap this. Unfortunately, I have been unable to find a code example that I can figure out or looks useable.
Please bear in mind that my server program is written in another language.
Any suggestions?
Thanks in advance!

Well in Java you do something like this:
-create the serverSocket:
ServerSocket serverSocket = new ServerSocket(PORTNR);
- usually you put this line in a while(listening) loop:
Socket clientSocket = serverSocket.accept();
Once someone tries to connect to the socket the accept() method returns a Socket to the client. Usually you create a thread to take care of the client and then reloop and go back waiting at the accept() metod.
If you want help to do this in a different language, I guess you should specify which language, or perhaps find a forum for that language to ask.... (or do both)
Sjur

Using a selector to detect closed socket channel.

Basically our app uses one thread to perform a select on multiple socket channels. When a socket is closed (either remotely or locally) the server app needs to unregister the client (so we need to detect closed channels). We've been using blocking IO previously (no dramas), but now we're dealing with many connections/clients we need to rework it as we're getting excessive amounts of threads. Anyway, that's just background.
Here's the problem we're getting, I have boiled it down to the following.
SocketChannel channel = SocketChannel.open();
channel.connect(socketAddress); // for the test this is localhost.
// this make sure socket is open, remote end just echos, waits 3 seconds and closes the socket.
channel.write(ByteBuffer.wrap("testLocalSocketClose\n".getBytes()));
channel.configureBlocking(false);
Selector selector = Selector.open();
LOG.fine("registering channel");
channel.register(selector, SelectionKey.OP_READ, channel);
LOG.fine("closing channel");
channel.close();
LOG.fine("waiting...");
int i = selector.select();
// this never happens (or it does very rarely)
LOG.fine("selector woke with " + i + " selected");I would have expected the selector to return the selection key of the dead channel. Given that it doesn't and this scenario is possible (channel closing just after a read operation but before another select is called - in separate threads obviously). How can we reliably detect/be informed that the channel has been closed?
(I saw somewhere someone mention adding the OP_WRITE to the key, I have tried this as well and it makes no difference).
Many Thanks.
Bob.

May I suggest you look at your application and reassess; either it's wrong or it's your understanding of what our issue is.
Please try the simple test below.
WSADATA ws;
WSAStartup(0x0101, &ws);
SOCKET sock = socket(PF_INET, SOCK_STREAM, 0);
struct sockaddr_in server;
server.sin_family = AF_INET;
server.sin_addr.s_addr = htonl(INADDR_ANY);
server.sin_port = htons(9000);
cout << "binding" << endl;
bind(sock, (struct sockaddr *)&server, sizeof(server));
cout << "listening" << endl;
listen(sock, SOMAXCONN);
struct sockaddr_in client;
int client_size = sizeof(client);
memset(&client, 0, client_size);
cout << "accepting" << endl;
SOCKET clientSock = accept(sock, (struct sockaddr*)&client, &client_size);
// shutdown socket.
cout << "shutting down client socket" << endl;
shutdown(clientSock, SD_BOTH);
// setup select
FD_SET fd;
TIMEVAL tv;
FD_ZERO(&fd);
tv.tv_sec = static_cast<int>(6000);
tv.tv_usec = 0;
FD_SET(clientSock, &fd);
cout << "selecting" << endl;
int rc = select(0, &fd, NULL, NULL, &tv);
cout << rc << ", " << FD_ISSET(clientSock, &fd) << endl;
char msg[500];
if (FD_ISSET(clientSock, &fd)) {
     cout << recv(clientSock, msg, 500, 0) << endl;
     cout << WSAGetLastError() << endl;
cout << "closing" << endl;
closesocket(clientSock);Telnet to port 9000, you get the following output immediately:
binding
listening
accepting
shutting down client socket
selecting
1, 1
-1
10058
closing
The solution I posted previously re calling shutdownInput/Output in Java isn't correct however, I left OP_WRITE on by mistake, which always returns ready, my fault. Apologies.
Whatever the behaviour, it will be the same for Selector.select() as it is for select().
Clearly not.
Edited by: Bawb on 29-Jul-2011 07:01, I had left OP_WRITE on which was returning ready each time, when I realised and took it out I removed the shutdown code which made me think I hadn't sorted this. Apologies again.
Still reckon an RFE for OP_SHUTDOWN should be added to Java.
Thanks.

How to detect client socket shutdowns in server socket

Hi,
Hoping to get some help with this. I am writing this program that implements a socket server that accepts a single client socket (from a third-party system). This server receives messages from another program and writes them to the client socket. It does not read anything back from the client. However, the client (which I have no control over) disconnects and reconnects to my server at random intervals. My issue is I cannot detect when the client has disconnected (normally or due to a network failure), hence am unable to accept a fresh connection from the client. Here's my code for the server.
ServerSocket serverSocket = null;
Socket clientSocket = null;
PrintWriter out = null;
BufferedReader in = null;
try{
          if (serverSocket == null){
                serverSocket = new ServerSocket(4511);
     clientSocket = serverSocket.accept();
     System.out.println("Accepted client request ... ");
     out = new PrintWriter(clientSocket.getOutputStream(), true);
     in = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));
     System.out.println("Input / Output streams intialized ...");
     while (true){
          System.out.println("Is Client Socket Closed : " + clientSocket.isClosed());
          System.out.println("Is Client Socket Connected : " + clientSocket.isConnected());
          System.out.println("Is Client Socket Bound : " + clientSocket.isBound());
          System.out.println("Is Client Socket Input Shutdown : " + clientSocket.isInputShutdown());
          System.out.println("Is Client Socket Output Shutdown : " + clientSocket.isOutputShutdown());
          System.out.println("Is Server Socket Bound : " + serverSocket.isBound());
          System.out.println("Is Server Socket Closed : " + serverSocket.isClosed());
          messageQueue = new MessageQueue(messageQueueDir+"/"+messageQueueFile);
          //get Message from Queue Head (also removes it)
          message = getQueueMessage(messageQueue);
          //format and send to Third Party System
          if (message != null){
                         out.println(formatMessage(message));
               System.out.println("Sent to Client... ");
          //sleep
          System.out.println("Going to sleep 5 sec");
          Thread.sleep(5000);
          System.out.println("Wake up ...");
}catch(IOException ioe){
     System.out.println("initSocketServer::IOException : " + ioe.getMessage());
}catch(Exception e){
     System.out.println("initSocketServer::Exception : " + e.getMessage());
}I never use the client's inputstream to read, although I have declared it here. After the client is connected (it enters the while loop), it prints the following. These values stay the same even after the client disconnects.
Is Client Socket Closed : false
Is Client Socket Connected : true
Is Client Socket Bound : true
Is Client Socket Input Shutdown : false
Is Client Socket Output Shutdown : false
Is Server Socket Bound : true
Is Server Socket Closed : false
So, basically I am looking for a condition that detects that the client is no longer connected, so that I can bring serverSocket.accept() and in and out initializations within the while loop.
Appreciate much, thanks.

Crossposted and answered.

Data socket buffer overflow detection

Hello,
I plan to use data socket to access SharedVariables. I started with the example Buffering.vi from the Shared_Variable_Buffering.lvproj shipped with LabVIEW 2009 SP1 (DSC-Module).
This example leads to a read buffer overflow caused by the high speed write loop and low speed read loops. The interesting part is, that reading the SharedVariable values using a SharedVariable-Node delivers a warning for that buffer overflow situation. But, the DataSocket-Read doesn't deliver any warning or error and I didn't find a way to detect the overflow. Does someone know how to get this done?
Thanks for your help.
Thomas

Hello Maria,
thank you for your reply.
It took a while, but today I checked out the Variable Client - Server.lvproj example shipped with the newest LabVIEW. And I was surprised to find even another possibility to interact with Shared-Variables: the new VI's contained in the DataComunication/SharedVariables palette (used by the Variable Refnum API Client.vi in the example).
And with the DSC-Module, another possibility is available: the also new VI's contained in the DSC Module/Tags palette (try the DSC Tag API.lvproj example, but don't forget to manually deploy the libs before starting the VI's).
So, plenty of possibilities available. It will take some time to realize the advantages (or disadvantages) of each one, especially for the new VI's.
Let's see what possibilities we gain with LabVIEW 2010...
Regards,
Thomas

How to detect email, http SOCKETS! HELP!

I've been exploring socket programming for about 2 weeks now and i'm baffled by the problem of detecting when the SMTP POP3 and HTTP sockets are open... I've have been running all of these port scanners in java and none of these detect these ports when they are open and yes i have ran all of these services to open the ports and then checked to scanner... I know that there is two different types of protocl TCP and UDP... udp being the more basic one... but all of those services run on TCP atleast according to IANA

try using the JavaMail API
Using that you can get rid of socket programming and with its APIs you can actually open the inbox as a folder and check for the mails, check if there are new mails, unread mails etc.
something like
Folder folder =store.getFolder("inbox");
folder.open(Folder.READ_WRITE);
System.out.println("Total messages are : "+folder.getMessageCount());

Detecting When a Non-Blocking Socket Is Closed by the Remote Host

Hi,
Using NIO non blocked sockets how do I detect when a Non-Blocking Socket Is Closed by the Remote Host?
What I have read is:
The only way to detect that the remote host has closed the connection is to attempt to read or write from the connection. If the remote host properly closed the connection, read() will return -1. If the connection was not terminated normally, read() and write() will throw an exception.
I have written a server test program using NIO and an applet connecting to the server program via sockets.
When I after a successful connection shuts down the browser following happens: The code below comes in an endless loop though mySelector.select returns 0 every time. (The selector is registered for OP_READ). size = 1.
while (true) {
int n = mySelector.select();
int size = mySelector.keys().size();
if (n == 0) continue;
Is this an expected result?
How do I get to know what client has lost connection?
My environment:
W2000
java 1.4.1 build 1.4.1_01-b01
Browser used: IE 5.0
Many thanks for your help on this matter!
Regards Magnus Wistr�m

What you're doing looks OK to me.
I wonder whether your thread is being interrupted by Thread.intterupt() somewhere. Try putting a Thread.interrupted() before the select call.
Sylvia.

Detecting unsent data when closing a socket

I'm currently using a non-blocking socket to send data to a remote server. Whenever the application detects that the connection has been closed remotely, it will close the local connection, however netstat reports that there is unsent data still in the TCP/IP buffers.
What I'd like to do is check within the application whether there is any unsent data at the time the socket is closed. I've read that SO_LINGER can be used in such circumstances and then checking the return code on closing the socket, but it's unclear whether this will work in non-blocking mode.

Instead of closing the PrintWriter just flush it. Then do shutdownOutput, then close either the PrintWriter or the socket - you don't need to do both.

Detecting socket closure

Similar Messages

Maybe you are looking for