boB, Based on what you've said, it sounds like I would need to have a " ThrowawayDecoder" as the last decoder in my ProtocolCodecFactory to consume or clear those packets in the protocol I'm not currently handling. I'll create one and give it a go.
Thanks for your response. Daryl ----- Original Message ---- From: boB Gage <[email protected]> To: [email protected] Sent: Tuesday, August 4, 2009 5:23:41 AM Subject: Re: Understanding DemuxingProtocolCodec Caveat: I'm not one of the Mina developers, but I have been working with it for awhile now. Anything I say could be wrong, just not intentionally so. :-) Far as I know, when you return NOT_OK, losing the second packet in a 2+ packet burst is the least of your problems. Returning NOT_OK from decodable() is going to tell Mina that this decoder object cannot process this data. Returning NOT_OK from all the possible decoders will break down the connection (IOW, it's a protocol failure to not be able to decode incoming data). The way I understand it, even for unsupported packets, you must decode at least enough to properly consume the data from the buffer and then return OK. *Then* you can start worrying about multiple packets within the data burst... :-) If you consumed the buffer properly, then you *should* see new decodable() and decode() calls for the unconsumed parts of the input buffer. Pretend like I repeated my caveat here. :-) I blindly pounded out a Mina app that works. But I know there's parts of it that don't match the developer's ideas, and probably a lot of things that I could have done better. boB Daryl Ayres wrote: > Hi, > > I've been evaluating Mina 2.x as a possible Io Framework for implementing a > TCP client I'm working on. The protocol I'll be using has various packet > types defined, and I'll only be interested in a few of them, but I could > potentially receive any packet type that is defined. My initial thought was > to use the DemuxingProtocol approach similar to what is shown in the SumUp > example. It looked like I'd be able to evaluate each packet type received > using the MessageDecoder.decodable(...) method, returning OK for the packet > types I'll be implementing and NOT_OK for all others, but after re-reading > the Tutorial on ProtocolCodecFilter for Mina 2.x and varioius emails, etc, I > started questioning if this approach will actually work. > > My concern is I will potentially be discarding messages I'm interested in > when I return NOT_OK from the decodable(...) method when the message buffer > being evaluated contains 2 or more messages; the first message in the buffer > is not one any decoder can handle, but the second (or 3rd) message in the > buffer is one that is handled. > > It seems there would be a similar issue if I attempted to continue to > evaluate the buffer after encountering a message the current decoder does not > handle, but then later returning OK when finding a message the current > decoder does handle; the buffer contains 2 messages, the first of which is > not handled by the current decoder, but the second one is; however, the first > message which will now be discarded could have been handled by one of my > other decoders. > > So, given my limited understanding of the Mina Framework at this point, my > question is, is this a valid concern, or is there something I'm missing or > should be doing to avoid this issue? > > Thanks for your time and feedback, > Daryl > > > >
