Java understanding I/O streams

Question

I/O streams in Java are the most misunderstood concept for me in programming.

Suppose, we get input stream from a socket connection:

DataInputStream in = new DataInputStream(clientSocket.getInputStream());

When I get data from a remote server, which of these describes things correctly?

1. Data stored in the in variable. When extra data comes from server, it appends to in, increasing its size. And then we can read data from in variable that way:

   byte[] messageByte = new byte[1000];
   boolean end = false;
   String dataString = "";
   while(!end)
   {
       bytesRead = in.read(messageByte);
       messageString += new String(messageByte, 0, bytesRead);
       if (messageString.length == 100)
       {
           end = true;
       }
   }
   

2. in is only a link to the source of data and doesn't contain data itself. When we call in.read(messageByte) 1000 bytes copy from the socket to bytesRead?

   Alternatively, instead of a socket let's say we have stream connected to file on HDD. When we call in.read(messageByte) we read 1000 bytes from HDD, yes?

Which approach is right? I tend to think it's #2, but if so where is data stored in the socket case? Is the remote server waiting when we read 1000 bytes, and then sends extra data again? Or is data from the server stored in some buffer in the operating system?

Answer 1

1. Data stored in in variable.

No.

When extra data comes from server, it appends to in, increase it size. And then we can read data from in variable that way:

byte[] messageByte = new byte[1000];
boolean end = false;
String dataString = "";
while(!end)
{
    bytesRead = in.read(messageByte);
    messageString += new String(messageByte, 0, bytesRead);
    if (messageString.length == 100)
    {
        end = true;
    }
}

No. See below.

2. in is only link to source of data, and don't contains data themselves.

Correct.

And when we call in.read(messageByte); 1000 bytes copy from socket to bytesRead?

No. It blocks until:

• at least one byte has been transferred, or
• end of stream has occurred, or
• an exception has been thrown,

whichever occurs first. See the Javadoc.

(Instead socket, we can have stream connected to file on HDD, and when we call in.read(messageByte) we read 1000 bytes from HDD. Yes?)

No. Same as above.

What approach right?

Neither of them. The correct way to read from an input stream is to loop until you have all the data you're expecting, or EOS or an exception occurs. You can't rely on read() filling the buffer. If you need that, use DataInputStream.readFully().

I tend to 2

That doesn't make sense. You don't have the choice. (1) and (2) aren't programming paradigms, they are questions about how the stream actually works. The question of how to write the code is distinct from that.

where data stored in socket?

Some of it is in the socket receive buffer in the kernel. Most of it hasn't arrived yet. None of it is 'in the socket'.

Or remote server waiting when we read 1000 bytes, and then send extra data again?

No. The server sends through its socket send buffer into your socket receive buffer. Your reads and the server's writes are very decoupled from each other.

Or data from server stored in any buffer in operating system?

Yes, the socket receive buffer.