setsockopt/getsockopt not working correctly on Intel processors

[nicmichael]

Integer values passed to setsockopt calls and retrieved from getsockopt calls are converted between Java and native code using ByteOrder.BIG_ENDIAN in Native.java, which results in incorrect values being passed for little-endian CPU architectures such as Intel processors.

For example, we were invoking
UnixSocketChannel.setOption(UnixSocketOptions.SO_SNDBUF, 262144);
... which ends up calling
Native.setsockopt.(fd, SocketLevel.SOL_SOCKET, UnixSocketOptions.SO_SNDBUF, 262144);

In Native.java, it converts the send buffer size using big endianness (regardless of the platform architecture):

ByteBuffer buf = ByteBuffer.allocate(4); buf.order(ByteOrder.BIG_ENDIAN); buf.putInt(optval).flip(); return libsocket().setsockopt(s, level.intValue(), optname.intValue(), buf, buf.remaining());

Running this on Intel/Linux ends up setting the send buffer size to 1024 byte (instead of 262144), as can be seen with strace:
18:31:15.483698 setsockopt(226, SOL_SOCKET, SO_SNDBUF, [1024], 4) = 0 <0.000032>
Obviously this undersized buffer could lead to severe performance degradation.

The same hard-coded endianness is found in getsockopt calls.

A simple fix is to replace
buf.order(ByteOrder.BIG_ENDIAN);
with
buf.order(ByteOrder.nativeOrder());
which works fine on any architecture (confirmed with strace on Intel/Linux).