On 10/28/07, paul bryant <[EMAIL PROTECTED]> wrote: > > Hi > I have a very strange mixed up legacy protocol, where the message payload > can either be big or little endian depending on the payload type which is > contained in header (which is always big endian). > The header consists 4 16bit words as follows > 0xAA 0xAA Start Word > 0xXX 0xXX Total length in bytes > 0xXX 0xXX Payload Type > 0x00 0x0X Source ID > The paylaod size varies per Type but is 16bit word aligned. > > So I think I need to use a DemuxingProtocolCodecFactory with a set of > chained MessageDecoder's > Which will return MessageDecoderResult.NOT_OK if the payload type doesn't > match.
Right. > Right there's the background here are the questions: > > 1. If the first decoder in the chain returns > MessageDecoderResult.NEED_DATA will the other decoders be called or will the > IO handler keep calling the first decoder until the it returns OK or NOT_OK? If you are referring to decodable() method, it will also call other decoders. For decode(), it will keep calling the first decoder until it returns OK or NOT OK. > 2. Can I swap endianness on the bytebuffer in each decoder in isolation > or do I need to make sure the state of the bytebuffers endianness when I > return NEED_DATA or NOT_OK? You have to set the byte order of the buffer in every decode() method to make sure you are in the correct order. Please do not rely on the internal implementation detail of the DemuxingProtocolCodecFactory. > 3. Are there any examples of multiple chained decoders with binary data > and mixed endians (Well I gotta ask). Unfortunately not yet. I think we need to provide an example for a multi-layered protocol, but not sure about mixed endians. > 4. Is the latest 1.1.3 ok for this or would 2.x be a better starting > point? It depends on how brave you are. :) 1.1.3 is enough IMHO though. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
