InputStream can't handle 2016 bytes

I recently wrote a program in Java that automatically creates encrypted connections and transmits data about them. Now I have the problem that the input stream no longer reacts if a lot of data is transferred at once. (I tried to transfer 2016 bytes at once)

But i think the problem is about the low an high byte transmission.

Server:

    public byte[] read() throws IOException {
        byte[] bytes = new byte[2];
        this.inputStream.read(bytes);
        int length = ((bytes[0] & 0xff) << 8) | (bytes[1] & 0xff);
        byte[] buffer = new byte[length];
        this.inputStream.read(buffer);
        return this.encryption.decryptAES(buffer);
    }

Client:

    public void write(byte[] message) throws IOException {
        byte[] bytes = new byte[2];
        message = this.encryption.encryptAES(message);
        bytes[1] = (byte) (message.length & 0xFF);
        bytes[0] = (byte) ((message.length >> 8) & 0xFF);
        this.outputStream.write(bytes);
        this.outputStream.write(message);
    }

InputStreams aren't closed or null.
No exception was thrown either.

The programm hangs up at reading the bytes for the length of the byte array on serverside. On Client side the bytes are successfully send.

The read call is working as designed; you're just confused about how it is designed (which is admittedly a little bizarre).

The read(byteArray) method is guaranteed to read at least 1 byte; it will only read none if an exception occurs, or the stream is closed.

It is not, however, guaranteed to fill the provided byte array. It's perfectly fine for it to read only 1 byte (the spec says this is okay, thus, your code must be written to deal with it). Even if there's more to be sent.

So, how many bytes do you actually end up getting? ¯_(ツ)_/¯ Depends on your network card, the OS, the VM, and the phase of the moon.

Therefore, a 'lone' read call like this is always a bug. It must occur in some sort of loop.

Fortunately, you don't have to program any of that unless you're on a rather old version of java; these days the InputStream type has the readNBytes method, which will guarantee that it will fill the entire provided byte array, giving you fewer bytes only if an exception occurs or if the stream ends before the full byte array is filled.

So, instead of: in.read(buffer), the right call is in.readNBytes(buffer, 0, buffer.length).

NB: The design of read is like this because it meshes with how I/O actually works: I can give you 2016 bytes right now; if you want more, it would take longer (another round trip to the card, or possibly waiting for IP packets to make their way across an ocean, who knows how long that might take); and often it is not really possible for you to know that the magic size to make your byte array so that you get the fastest possible response without making unwieldily many requests to read() which would also be slow – thus, you can't solve this dilemma by saying: "Well, just give a small byte array if you want fast responses!". Now you know why it is designed like this