Hi!
I am reading 16 bit values from a Buffer I get passed to a class that
extends AbstractTransformer<Buffer, GWMessage>. (GWMessage is a class
of mine.)
The protocol I am reading is binary over UDP and uses little endian
encoding. Therefore the first thing I do in .transformImpl(…) is to call
.order(ByteOrder.LITTLE_ENDIAN) on the Buffer I get.
Afterwards I am calling .getShort() on the Buffer. Sometimes I get the
result I am expecting, sometimes I get the wrong data.
Example:
The data the Buffer starts with might be: 50 49 4E 47
When I call .getShort() on it sometimes I get 0x4950 (correct) but
sometimes I get 0x5049 instead (bytes in incorrect order).
I have checked the actual class implementing the Buffer I get. It's
BuffersBuffer. If I understand this class right, the call of
.order(ByteOrder.LITTLE_ENDIAN) will set byteOrder to LITTLE_ENDIAN and
bigEndian to false.
The call to .getShort() will call .getShort(position) which will call
activeBuffer.getShort(other_position).
activeBuffer is the underlaying buffer, that is wrapped by
BuffersBuffer, right? If this activeBuffer has a different byte order
than my instance of BuffersBuffer I will get the data in the wrong byte
order. I don't see where the changed byte order would be respected.
Am I just doing something, that is not allowed to do? Or is this a bug
in the implementation of Grizzly?
Regards,
Matthias
Some more information about what I am doing:
- I am reading UDP packets from the network.
- The code I am using looks like this. (Sure, there are more methods I
had to implement:
public class ScomboxDecoder extends AbstractTransformer<Buffer, GWMessage> {
protected TransformationResult<Buffer, GWMessage> transformImpl(
final AttributeStorage storage, final Buffer input)
throws TransformationException {
input.order(ByteOrder.LITTLE_ENDIAN);
final short firstTwoBytes = input.getShort();
System.out.format("%04x\n", firstTwoBytes & 0xFFFF);
[…]
}
}
--
Matthias Wimmer
Contact details: http://matthias.wimmer.tel/