0

I am working on socket programming and implementing custom request response protocol. For same I have used ObjectInputstream and ObjectOutputstream in java socket API.

The area where I have stucked is to check if data(in my case object) is available to read or not, for this I have tried to use the ObjectInputstream.available() but it is returning 0 even if data is available on stream.

Why is it so?

So I have come up with solution: using exception and handling them in infinitely running loop, so even if exception(Read time out) occurs it will try to read again.

I have doubt is it good practice to do so? Or if any other solution you might have do suggest.

while (true){
    try {
        request = rpcClient.getRequest();
        System.out.println(request);
        // use threads to handle request for faster response(make use of request IDs)
        rpcClient.sendResponse("test response");

    } catch (SocketException e)
    {// thrown when connection reset
        System.out.println("Connection reset :  Server is down.....");
        break;
    } catch (IOException e){
        // thrown when read time out
        System.out.println("read time out: listening again");
    } catch (ClassNotFoundException e){
        e.printStackTrace();
    }

}
jophab
  • 5,356
  • 14
  • 41
  • 60
  • I believe this answers your question: http://stackoverflow.com/questions/26769428/checking-for-an-available-object-from-socket-using-objectinputstream – dotvav Jul 09 '15 at 08:11

2 Answers2

0

That is not a good practice since an infinite loop eats away your CPU time.

I dont quite understand your statement

but it is returning 0 even if data is available on stream

since that isnt the case. If it returns 0, there is no data that can be read from the stream. What makes you so sure there actually is data?

Also: I cant see the code that is calling available(). Could you edit your question?

f1sh
  • 11,489
  • 3
  • 25
  • 51
  • Implementations of `InputStream.available()` are permitted to always return zero. See the Javadoc. – user207421 Apr 29 '17 at 01:26
  • They are permitted to and ``InputStream`` itself does so, yet subclasses are expected to do otherwise. The javadoc states: "[returns] an estimate of the number of bytes that can be read (or skipped over) from this input stream without blocking or 0 when it reaches the end of the input stream". So 0 has a very special meaning. – f1sh Apr 29 '17 at 09:15
0

You shouldn't be using available() in the first place. Disable the read timeout, so you can just let the thread wait until there's something to read (or the connection is broken).

I wouldn't recommend using ObjectStreams for network communications though. It's not very suitable in most cases, considering the header information and other things that gets transferred. You're better off designing your own protocol to use and just send bytes over the network.

Kayaman
  • 72,141
  • 5
  • 83
  • 121
  • Disabling read time out worked for me.Thanks.For Protocol implementation will it be good to convert these objects into bytes transfer them then at receiver side collect all these byte convert them back to object? Don't you think it will add over head of conversion at both end and affecting performance of system. – Chinmay Jaiswal Jul 09 '15 at 10:09
  • What do you think ObjectStreams do? Only bytes move over the network, not objects. I don't recommend using ObjectStreams if you're not familiar with how Serialization works. I also recommend not thinking about performance (yet), if you're a beginner. You'll just make wrong assumptions and decisions about what's good performance-wise. Concentrate on the correctness of your application first. – Kayaman Jul 09 '15 at 10:12