I think the answer to your question depends to a certain extent on your protocol. Note that the number of message classes you have does not need to equal the number of decoders.
If you have an explosion of protocol decoders then you will impact performance since for a given byte stream you will have to run through all the decoders asking them in turn if they can decode the byte stream.
If however you have a more elegant protocol where all the frames follow a particular format then it is much easier to do it efficiently. For example if you have a common frame header with a byte that indicates the frame type then you can create a common superclass and have the decoder instantiate the appropriate subclass, delegating to it to decode the payload of the individual frame.
For the AMQP messaging protocol, which I implemented with MINA, we only have two decoders. One for the protocol initiation which is the first frame sent by a client and never used thereafter, and another to handle all other frames. I have arranged that the protocol initiation decoder is effectively removed after connection.
For supporting different protocol versions, you raise an interesting point. For performance you probably want to switch in a different set of decoders on a per-connection basis (assuming that you know on connection whether a given client is using version 1 or 2 of your protocol). This could be an area where you might like to enhance MINA itself.
RG
| [EMAIL PROTECTED]
31/07/2006 19:42
|
To: [email protected] cc: Subject: Codecs & Messages Question |
Hello MINA users,
I am implementing a fairly complex protocol - complex enough to make a
switch statement in my subclassed ProtocolHander very ugly. And so I'd
like to use MINA's org.apache.mina.filter.codec.demux package. I've
googled through the message archives & looked through the sumup example, &
I have a general idea about how it works, but I still have some questions.
1. Should there be a separate Message class for every subtype of
message, or for each general category of messages? For instance, there is
a broad category of "LOGIN" messages, which can be broken up into
"LOGIN_RQST," "LOGIN_ACK," and "LOGIN_NAK." Should I have a simple
LoginMessage class or a LoginRqstMessage, LoginAckMessage, and
LoginNakMessage? I am conflicted because while it seems like overkill to
have an Encoder/Decoder pair for each of LoginRqstMessage,
LoginAckMessage, and LoginNakMessage, it doesn't seem to me that all of
the functionality provided by LOGIN_RQST, LOGIN_ACK, and LOGIN_NAK fits
comfortably into one class (namely LoginMessage).
2. How have people dealt with supporting multiple versions of
protocols? My first instinct is to subclass further by having
LoginMessageV1 & LoginMessageV2 which extend LoginMessage which extends
AbstractMessage. The only thing is that the decoder/encoder pairs for
LoginMessageV1 & LoginMessageV2 will be very different, so that's even
more classes. And I don't want to fragment my code into too many classes,
for both readability's sake and performance.
If anyone could point me to specific threads dealing with demuxing &
codecs, or any other resources they think would be helpful, I would
greatly appreciate it.
Best regards,
Elizabeth Clause
Email: [EMAIL PROTECTED]
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
