Haug Bürger wrote:
Emmanuel Lecharny schrieb:
[email protected] wrote:
If I understand MINA right I need to implement my own protocol
encoder and decoder to support my protocol. The encoder looks quite
simple but the decoder looks a bit strange.
If I understand it right the decoder should be aware that a message
might be split to multiple doDecode() calls. The examples I found
save some state in the session. I'm ok so far.
But I do nut understand the buffer handling. If I'm right, I'm
allowed to read from position() to limit(). But what happens if I
read to limit() and have no message complete? Do I get the same
buffer next time again and can store the position where I stopped? If
I set a mark() is it stored over multiple doDecode() calls? How much
buffer is available? How do I mark the read part of the buffer as read?
Is there an example that explains how to handle the multiple
doDecode() messages and the buffer handling?
Tt's really having the same behavior than the standard ByteBuffer.
If you have to read more than one buffer to decode your message (ie
your decoder will be called more than once), then either you store the
read bytes up to the limit (if there are not enough bytes to decode
your message) and store them in the session, or you have to
concatenate the buffer into another one waiting to have read all the
needed bytes. Then call the decoder.
I found an example in the CumulativeProtocolDecoder class. This example
covers the case that
you have multiple messages in your buffer. It explains why the
doDecode() returns a boolean.
The CumulativeProtocolDecoder calls doDecode() with the same buffer
again if you return
true. You have to set position and limit in this case to consume the bytes.
This leaves the case where a message does not fit into the buffer.
No. In this case, the decode() method won't be called.
As
far as I can see from the documentation the IoBuffer is dynamic in size
if autoExpand = true. The example above does not store the remaining
data in the session.
In fact, it does, but you don't have any clue about the key used to
retrieve the buffer.
This looks to me as if you always get the same
buffer again.
True. And this is what we want.
I assume, just a guess, that the buffer is enlarged if new
data comes in and your doDecode() is called.
When the tag that indicates you have received a full message, the the
decode() method is called. Until this happens, the incoming new data are
just added into the current buffer (stored in the session).
If your position is at the
end of the buffer you might end up with a buffer twice of size of the
largest message.
Why would you do that ? Do you really care about the buffer size? Then
do'nt use the cumulativeProtocolDecoder, and handle the incoming bytes
in your decoder. It works pretty well, this is what we do on Apache
Directory Server, built on top of MINA. Now, that leads to some more
complexity you may not want to deal with...
I wonder what happens if the doDecode() always leaves a
few bytes in the buffer.
If you are using a cumulativeXXX, and if there is another complete
message, the the decoder() method will be called again. Otherwise, the
remaining bytes will be kept into a buffer, waiting for the missing data.
I'm not sure if this is the right solution because the buffers are IO
buffers.
They are not. We use a special class which encapsulates ByteBuffer.
They may not even be Direct buffer. I don't see what is the probelm you
try to address here.
On the other hand this is the only solution to avoid copying
data around, if you want the whole message in a byte array.
Is this a real problem for you to copy data around? I mean, compared to
the processing time and network latency, do you really think that
copying a buffer will affect the performance of your system by something
higher than a few 1/1000% ? Make it works first, you'll have plenty of
time to improve it !
In any case, just have a look at :
http://mina.apache.org/tutorial-on-protocolcodecfilter-for-mina-2x.html
I think this example does not cover this topic very well.
It covers the encoding/decoding problems. Starts there, and then move to
something more complex.
Look, from the theorical POV, your questions are really intersting. But
at some point, you should start writing code, and see what *really*
happens. It's pretty hard to explain the whole MINA stack inside out
without knowing nothing about what you are trying to do.
Questions are welcomed, and we are pleased to answer, but it'as also
easier for us to base the discussion on real lofe case ! (at least for me ;)
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
