DelimiterBasedFrameDecoder Help

[Trustin Lee (이희승)]

Hi David,

Actually, your message got through the mailing list.  It just took a
while for me to answer your question.  Thanks for your patience.

On Fri, Sep 25, 2009 at 2:33 AM, Hoyt, David <hoyt6 at llnl.gov> wrote:
> I'm not sure if my original post made it or not because I had a few failed attempts - but I'm hoping this one makes it through...
>
> I’m still learning netty and I need to find the best classes to do what I need or find out if I need to code it myself – we have our own protocol that’s very, very simple – a header used to synchronize where we’re at in the stream and then some int’s, long’s, etc. in a known order. The entire length of the packet is known ahead of time (it's a fixed-length packet). We intend to maintain this connection for days, weeks, months, and years. So an example of a stream is (just the bytes -- "Packet #", "Header", and "Payload" don't actually appear in the data):
>
> Packet 1
> Header: 0xdeadbeef
> Payload: 0x00000000, 0x00000001, 0x00000002
>
> Packet 2
> Header: 0xdeadbeef
> Payload: 0x00000000, 0x00000001, 0x00000002

If the length of the packet is fixed, it is dead simple - use
FixedLengthFrameDecoder.  You never need DelimiterBasedFrameDecoder.

> We use the header (delimiter) in case (for whatever reason – a particle from space flips a bit on the server producing these messages) we lose where we’re at and need to synchronize with the next packet. So say we got the following sequence:
>
> Packet 1: 0xdeadbeef 0x0x00000000 0x00000000 0x00000000
> Packet 2: 0xabcdabcd 0x0x00000000 0x00000000 0x00000000
> Packet 3: 0xdeadbeef 0x0x00000000 0x00000000 0x00000000
>
> We would want to skip packet 2 and continue on with packet 3. We would like to know if we found a problem with packet 2, but it's not a requirement.

Once the FixedLengthFrameDecoder splits the incoming data as you want,
you can inspect the header of the message to determine if the message
is what you were expecting.

> We also need to know if there's a significant delay between messages (e.g. a read timeout of, say, 30 seconds or more). We only need to ever read and never write to this stream.

You could use ReadTimeoutHandler or IdleStateHandler (in
org.jboss.netty.handler.timeout).

> Does DelimiterBasedFrameDecoder allow me to recover from a bad packet? Can I recover without having to catch an exception? I'm not sure where to begin. I know how I would do it using old IO, but I'd prefer to take advantage of netty's power and expressiveness and I'm sure netty can handle this. I just don't want to reinvent the wheel.

DelimiterBasedFrameDecoder is used only when there is an explicit
delimiter defined in the protocol.  For example, a pipe (|), NUL
(0x00), or newline character is the case - mostly text protocols.
Your protocol does not have a delimiter, so DelimiterBasedFrameDecoder
cannot be used.

HTH

— Trustin Lee, http://gleamynode.net/