I have odd protocol where responses to commands are of the form case 1: <STX><ASCII DATA><ETX><Checksum> case 2: <0x06> case 3: <0x15>
which is proving to be a bit challenging to do with Netty without doing a bunch of byte by byte copying. I have my naive ByteToMessageDecoder read one byte and upon inspection of the byte decide how to progress. My 'frame' that I send up to the next layer in the pipeline is a nio buffer which either contains a single byte (cases 2 or 3) or the entirety of the message (<STX>....<Checksum>) for case 1. This works fine and since I a dealing with a serial transport with a single connection that kind of highly iterative copying is probably of no real concern. However, this doesn't feel like it is idiomatic Netty and I was looking for other interesting solutions. I suppose one solution would be dynamically add a handler to the pipeline in the event that the first byte in a message was an <STX> and then removing that handler once it had consumed <checksum>. I could also see, if such a thing is possible, a pair of sibling (same order in the pipeline) decoders: a LineBasedFrameDecoder that terminates with <ACK> or <NACK>, and a subclass of LineBasedFrameDecoder that terminates on <ETX> but also consumes and extra byte. So I am curious what approaches folks with more experience with Netty than I would come up with. -- You received this message because you are subscribed to the Google Groups "Netty discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/netty/d4fd5a50-88c0-4684-8f5a-31de50d1bd01n%40googlegroups.com.
