Is there a difference in Java's writeInt when executed on Windows vs an Intel based Mac

I currently writing a Java TCP server to handle the communication with a client (which I didn't write). When the server, hosted on windows, responds to the client with the number of records received the client doesn't read the integer correctly, and instead reads it as an empty packet. When the same server code, hosted on my Mac, responds to the client with the number of records received the client reads the packet and responds correctly. Through my research I haven't found an explanation that seems to solve the issue. I have tried reversing the bytes (Integer.reverseBytes) before calling the writeInt method and that didn't seem to resolve the issue. Any ideas are appreciated.

Brian

After comparing the pcap files there are no obvious differences in how they are sent. The first byte is sent followed by the last 3. Both systems send the correct number of records.

Yes I'm referring to the DataOutputStream.writeInt() method. //Code added

 public void run() {
try {
        InputStream in = socket.getInputStream();
        DataOutputStream datOut = new DataOutputStream(socket.getOutputStream());

        datOut.writeByte(1); //sends correctly and read correctly by client
        datOut.flush();

        //below is used to read bytes to determine length of message

        int bytesRead=0;
        int bytesToRead=25;
        byte[] input = new byte[bytesToRead];
        while (bytesRead < bytesToRead) {
            int result = in.read(input, bytesRead, bytesToRead - bytesRead);
            if (result == -1) break;
            bytesRead += result;
       }
        try {
                inputLine = getHexString(input);
                String hexLength = inputLine.substring(46, 50);
                System.out.println("hexLength: " + hexLength);
                System.out.println(inputLine);

                //used to read entire sent message

                bytesRead = 0;
                bytesToRead = Integer.parseInt(hexLength, 16);
                System.out.println("bytes to read " + bytesToRead);
                byte[] dataInput = new byte[bytesToRead];
                while (bytesRead < bytesToRead) {
                    int result = in.read(dataInput, bytesRead, bytesToRead - byt开发者_开发问答esRead);
                    if (result == -1) break;
                    bytesRead += result;
                }

                String data = getHexString(dataInput);
                System.out.println(data);

                //Sends received data to class to process

                ProcessTel dataValues= new ProcessTel(data);
                String[] dataArray = new String[10];
                dataArray = dataValues.dataArray();

                //assigns returned number of records to be written to client

                int towrite = Integer.parseInt(dataArray[0].trim());

                //Same write method on Windows & Mac...works on Mac but not Windows

                datOut.writeInt(towrite);

                System.out.println("Returned number of records: " + Integer.parseInt(dataArray[0].trim()) );
                datOut.flush();
            } catch (Exception ex) {
                Logger.getLogger(ServerThread.class.getName()).log(Level.SEVERE, null, ex);
            }
    datOut.close();
    in.close();
    socket.close();

} catch (IOException e) {
    e.printStackTrace();
}

}

As described in its Javadoc, DataOutputStream.writeInt() uses network byte order as per the TCP/IP RFCs. Is that the method you are referring to?

No, x86 processors only support little-endian byte order, it doesn't vary with the OS. Something else is wrong.

I suggest using wireshark to capture the stream from a working Mac server and a non-working Windows server and compare.

Some general comments on your code:

int bytesRead=0;
int bytesToRead=25;
byte[] input = new byte[bytesToRead];
while (bytesRead < bytesToRead) {
    int result = in.read(input, bytesRead, bytesToRead - bytesRead);
    if (result == -1) break;
    bytesRead += result;
}

This EOF handling is hokey. It means that you don't know whether or not you've actually read the full 25 bytes. And if you don't, you'll assume that the bytes-to-send is 0.

Worse, you copy-and-paste this code lower down, relying on proper initialization of the same variables. If there's a typo, you'll never know it. You could refactor it into its own method (with tests), or you could call DataInputStream.readFully().

inputLine = getHexString(input);
String hexLength = inputLine.substring(46, 50);

You're converting to hex in order to extract an integer? Why? And more important, if you have any endianness issues this is probably the reason

I was originally going to recommend using a ByteBuffer to extract values, but on a second look I think you should wrap your input stream with a DataInputStream. That would allow you to read complete byte[] buffers without the need for a loop, and it would let you get rid of the byte-to-hex-to-integer conversions: you'd simply call readInt().

But, continuing on:

String[] dataArray = new String[10];
dataArray = dataValues.dataArray();

Do you realize that the new String[10] is being thrown away by the very next line? Is that what you want?

int towrite = Integer.parseInt(dataArray[0].trim());

datOut.writeInt(towrite);

System.out.println("Returned number of records: " + Integer.parseInt(dataArray[0].trim()) );

If you're using logging statements, print what you're actually using (towrite). Don't recalculate it. There's too much of a chance to make a mistake.

} catch (Exception ex) {
    Logger.getLogger(ServerThread.class.getName()).log(Level.SEVERE, null, ex);
}

// ...

} catch (IOException e) {
    e.printStackTrace();
}

Do either or both of these catch blocks get invoked? And why do they send their output to different places? For that matter, if you have a logger, why are you inserting System.out.println() statements?