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
