On 2/15/11 12:38 AM, Tim Mottershead wrote:
Hi,
The 'MINA In Real Life' ApacheCon EU 2009 conference slides say that only
one codec filter should be used. Is this for performance reasons or is it
technically impossible to use more than one?
My bad. In fact, you can have more than one codec filter. I guess that I
was just trying to tell "keep it simple, stupid" !
The reason I ask is that I am looking at the feasibility of implementing a
MINA TDS (http://en.wikipedia.org/wiki/Tabular_Data_Stream) server. TDS
uses PDUs with an 8 byte header including type, status, length. The maximum
size of the PDU is negotiated between client& server at the start of their
dialog. The payload of the PDU usually contains one or more tokens (e.g. a
SQL command). A token can be of various types, can be fixed, variable or
zero length and can span multiple PDUs.
So this is a two level (or nested) protocol and I my first thought would be
to implement 2 codecs - one to handle the lower level PDU and the other to
handle the payload(token). What would be wrong with taking this approach,
in the light of the advice extended in 'MINA In Real Life'? Would there be
a better way of approaching this?
The way we implemented the LDAP decoding is similar : it's a two level
codec, the first layer is a TLV decoder (Type/Length/Value), the second
layer decode the messages itself. The decoder was handling both layers,
but in order to do that, the message is constructed on the fly, and
stored into the session, so that if the PDU is transmitted in pieces, we
can restore the message.
I must admit that it could have been done differently (ie, with two
codecs) but as the TLV have a recursive structure (ie the Value part can
itself be a TLV), that would have meant we have to aggregate all the
bytes before passing the data to the next codec.
This is one of the reason one single decoder is also better : you don't
have to load a long list of bytes in memory until all the necessary
bytes have been received.
This is a choice, both solution are valid.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
