In protocols like SMTP when there are simple line-based commands
intermixed with raw data (mail data) there are also great opportunities
for optimization if you write your own codec filter. I've implemented my
own DecoderFilter which can operate in "data mode". When not in data
mode the filter will act more or less like an ordinary ProtocolDecoder,
copying the received buffer to an autoexpanding buffer, decode SMTP
commands and pass them on to the next filter. When in data mode however
the filter will simply forward the buffers as they are received without
any copying (in most cases).
I guess this could be achieved with the MINA codec package but not
without some tweaking and not as efficiently. Please let me know if I'm
wrong.
I wouldn't mind adding this filter to MINA if anyone is interested.
/Niklas
Trustin Lee wrote:
On 3/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Yes, this is a good idea - we have done this and found it gave a small
performance increase.
We also found that while the DemuxingProtocolCodecFactory is useful since
it is easy to use, it is worthwhile writing your own custom codec if you are
wanting to maximise performance. This is because you can often take
advantage of state information so that you "know" which types of frame you
are going to receive (or are more likely to receive) rather than going
through a list of codecs in a particular order every time.
A nice advice, indeed!
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
