• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Problems in isBound() and isClosed() methods in the Socket class

 
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm using a socket connection in one of my programs, which checks whether the socket is connected, inorder to continue the processing of data it receives through the socket. I tried using both the



methods in the Socket class to determine whether the connection continues to exist. But even when the socket connection is closed on the other side these methods still return true. I'm confused. Is there a guaranteed method to check whether the socket connectivity is alive?

My test platform is Windows XP and I'm using Java5.
 
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is taken from Java Network Programming, by Elliote Rusty Harold


Java 1.4 also adds an isConnected method:

The name is a little misleading. It does not tell you if the socket is currently connected to a remote host (that is, if it is unclosed). Instead it tells you whether the socket has even been conected to a remote host. If the socket was able to connect to a remote host at all, then this method returns true, even after the socket has been closed. To tell if the socket is currently open, you need to check that isConnected() returns true and isClosed() returns false.

boolean connected = socket.isConnected() && !socket.isClosed();

Java 1.4 also add an isBound() method.

Wheras isConnected() refers to the remote end of the socket, isBound() refers to the local end. It tells you whether the socket is successfully bound to the outgoing port on the local system.


[ May 25, 2006: Message edited by: Edwin Dalorzo ]
 
Isuru Sampath
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Edwin, but this does not solve my problem. It still returns true even when the remote party closes the socket. I'm yet to solve this delimma.
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Isuru, maybe you can explain us what exactly you are doing.

Typically, your client application asks for a service to server application. This latter does some work and return it using the socket's OutputStream. Then the server side closes the socket communication with the client.

The client then reads all the data using the socket's InputStream. As the client socket has been closed in the server side, the last read of the InputStream in client side will find the EOF instead of blocking.

Now, it appears to me that you are expecting one side of the communication might be closed unexpectedly and you want to check that the other side of the communication is still alive before trying any IO operation.

This would manifest as an IOException in the client or server side, when the socket tries to read or write from the underlying socket's InputStream or to the OutputStream while the other socket side has been closed.

Is it this that you are trying to accomplish, that's to say: you want to know when the other side of the socket is closed and not when this side of the socket is closed? Right?

I am not an expert in Sockets, actually I am just starting to understand the Java technology about it. Now please, somebody correct me if I am wrong. I had the idea that the communication is ended according to a mutual protocol. I mean, I know the scope of code within I can expect the other side of the Socket to be connected, and I would assume that. Nevertheless, if that is not always true, it should be because an error happened in one of the sides of the communication, and hence, I should perceive that error as an IOException, whenever I try to read from or write to an InputStream or OutputStream respectively.
[ May 26, 2006: Message edited by: Edwin Dalorzo ]
 
Isuru Sampath
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Edwin, you read my mind.

I'm working on a framework that acts as a platform for multiple services. Developers can write their own services and park them within this framework. One of the core policies of this platform is that it only serves clients who are alive, which means if the connection is broken while the server side is processing the request, it will halt the processing and initiate a rollback sequence. For this purpose I need to know that the client is active. So the processing thread tests the socket from time to time.

One of my colleagues also ran into a same type of problem and he devised a method which he reads the socket stream character by character and checks for null. It works fine. But I cannot use it as the framework I'm developing requires every CPU cycle to be used in the most effective manner. I use buffered streams to achieve the maximum efficiency (please correct me if I'm wrong on this).

I'm still stuck with this problem.
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As far as I know, Isuru comrade, in a typical scenario, if one of the ends of the socket communication falls down, the other side will not get acquainted until it tries to send or receive data from the underlying IO.

Hence, I can say that, if while trying to read or write a message, one of your sockets experiment an IOException, then you can conclude that the socket at the other side of the communication channel is dead, and based on that, initiate a rollback operation.

The only way to know if the socket at the other side is alive is by means of asking it if it is alive, and you have to send some message to it in order to accomplish this task. Obviously, if it responds is because it's alive, if an IOException happens, well it's not.

Maybe you could make sure before executing every transaction if the other's side socket is still alive by means of sending a short message to the client which it must respond accoring to your protocol to demonstrate that it is yet alive. Then, the server executes the transaction, and asks the socket again before the next one. Maybe you could use the sendUrgentData() method to implement this functionality?

Java also offers a platform dependent option in the Socket class, the setKeepAlive() which will check if a Socket is alive every certain amount of time. I think this interval is platform dependant, and not precisely a very short interval.

At least this is what I think. But as I told you, I am not expert on the field. I am just learning, like you.
[ May 29, 2006: Message edited by: Edwin Dalorzo ]
 
Isuru Sampath
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Edwin, in my case this is a bit difficult as there is a seperate request queue and a request dispatcher to take care of the requests and their processing. But I feel if I give some serious thinking in the lines that you have mentioned I would be able to crack the problem.
 
Could you hold this kitten for a sec? I need to adjust this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic