How to Identify End of Inputstream in Java

Getting end of Inputstream in java

-1 denotes the end of the stream, and is received when the connection is closed. If you want to keep the connection open and send multiple messages, you need some sort of protocol (kind of like agreement between both ends) that tells where the message ends. The are many ways to do this, but in your example you're writing a line terminator (\n) to the end of the message, so you could check for that at the other end. Another way is to write the amount of bytes you're about to send before the actual message contents.

How to detect end of Input Stream from Socket using BufferedInputStream?

You are conflating 'end of request' with 'end of stream'.

'End of stream' on a socket means the peer has closed the connection. No end of stream, no peer close. If you plan to write a response back down this socket, it is therefore incorrect to try to read it to end of stream first.

You are trying to read a single request, in which case you need something in your application protocol to tell you when you have it all: lines; a length word prefix; a self-describing protocol like XML; STX/ETX; type-length-value; ...

In this case if the protocol is HTTP you need to implement the Content-length header: recognise it, read to the end of the headers, then read exactly that many bytes from the stream, e.g. with DataInputStream.readFully().

how to detect end of socket InputStream?

The API and the previous answer on such question states that -1 should mean that there are no characters to be read

I can't comment on what some uncited answer might say, but the API documentation says no such thing. It says -1 is returned at end of stream. End of stream on a socket occurs when the peer closes the connection, or shuts it down for output, and not before.

-1 is not an end of message indicator.

How to detect end of a file while receiving it through InputStream

You're using two different kinds of copy loop. In this one:

is.read(bytesToRead, 0, bytesToRead.length);

you're completely ignoring the return value. It could be -1 indicating end of file, or it could be a read count. So you're also assuming that read() fills the buffer. It isn't specified to do that. You don't need two different loops to do the same thing. Use the same code at both ends:

while ((count = in.read(buffer)) > 0)
{
    out.write(buffer, 0, count);
}

This works with any buffer size greater than zero. I usually use 8192 but you can use more if you wish.

If you want to keep the socket open for more sends, you need to:

• send the length of the file ahead of the file, with DataOutputStream.writeLong()
• read it at the receiver, with DataInputStream.readLong()

• modify the copy loop to read exactly that many bytes:

  long runningTotal = 0;
  while (runningTotal < total && (count = in.read(buffer, 0, (int)Math.min(buffer.length, total-runningTotal)) > 0)
  {
      out.write(buffer, 0, count);
      runningTotal += count;
  }
  

E&OE

JAVA what causes end of stream on network sockets?

How does the ObjectInputStream decide that it's the end of a stream

It happens when ObjectInputStream attempts to read from the underlying stream, and that stream returns -1 ... which means that the end-of-stream has been reached.

and what causes it?

In this case, the most likely explanation is that the remote end (the sender) has closed its socket, or it has crashed ... which will cause the socket to close.

(It is theoretically possible that the connection has been broken, but that is only likely to happen in obscure circumstances, so lets ignore that.)

And how can I solve this problem?

You need to understand why the sending end has closed the socket. Unfortunately, we cannot tell why that is because the code you have provided is not an MCVE.

---

Related Topics