Suggestions

[Hoyt, David]

Hello,



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



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. 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.



How should I approach this? What classes should I look at? 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.



Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/netty-users/attachments/20090921/73f72523/attachment.html