InputStream in.read（）的行为与预期不同

Question

I am trying to transfer a text file to another server using TCP and it is behaving differently than expected. The code sending the data is:

        System.out.println("sending file name...");
        String outputFileNameWithDelimiter = outputFileName + "\r\n"; //These 4 lines send the fileName with the delimiter
        byte[] fileNameData = outputFileNameWithDelimiter.getBytes("US-ASCII");
        outToCompression.write(fileNameData, 0, fileNameData.length);
        outToCompression.flush();

        System.out.println("sending content...");
        System.out.println(new String(buffer, dataBegin, dataEnd-dataBegin));
        outToCompression.write(buffer, dataBegin, dataEnd-dataBegin); //send the content
        outToCompression.flush();

        System.out.println("sending magic String...");
        byte[] magicStringData = "--------MagicStringCSE283Miami".getBytes("US-ASCII"); //sends the magic string to tell Compression server the data being sent is done
        outToCompression.write(magicStringData, 0, magicStringData.length);
        outToCompression.flush();

Because this is TCP and you can't send discrete packets like in UDP, I expected all of the data to be in the input stream and I could just use delimiters to separate the file name, content, and ending string and then each in.read() would just give me the next subsequent amount of data.

Instead this is the data I am getting on each read:

On the first in.read() byteBuffer appears to only have "fileName\r\n". 
On the second in.read() byteBuffer still has the same information. 
On the third in.read() byteBuffer now holds the content I sent. 
On the fourth in.read() byteBuffer holds the content I sent minus a few letters.
On the fifth in.read() I get the magicString + part of  the message.

I am flushing on every send from the Webserver, but input streams don't seem to implement flushable.

Can anyone explain why this is happening?

EDIT: This is how I am reading things in. Basically this in a loop then writing to a file.

 in.read(byteBuffer, 0, BUFSIZE);

Answer 1

If your expectation is that read will fill the buffer, or receive exactly what was sent by a single write() by the peer, it is your expectation that is at fault here, not read(). it isn't specified to transfer more than one byte at a time, and there is no guarantee about preserving write boundaries.

It is quite impossible to write correct code without storing the result of read() into a variable.

Answer 2

When you read from an InputStream , you're giving it a byte array to write into (and optionally an offset and a maximum amount to read). InputStream makes no guarantees that the array will be filled with fresh data. The return value is the number of bytes that was actually read into it.

What's happening in your example is this:

• The first TCP packet comes in with "fileName\\r\\n" , gets written into your buffer, everything fine so far.
• You call read() again, but the next packet hasn't arrived yet. read() will have returned 0 , because it didn't want to block until data arrived. So the buffer still contains "fileName\\r\\n" . Edit: as pointed out, read() always blocks until it reads at least one byte. Don't really know why the buffer didn't change then.
• On the third read, the content has arrived.
• The first bit of the content gets overwritten with the second part of the message, the last bit still contains part of the old message (I think that's what you meant).
• etc., you get the idea

You need to check the return value, wait for the data to arrive, and only use as much of the buffer as was written by the last read() .