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. 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. This looks to me as if you always get the same buffer again. I assume, just a guess, that the buffer is enlarged if new data comes in and your doDecode() is called. If your position is at the end of the buffer you might end up with a buffer twice of size of the largest message. I wonder what happens if the doDecode() always leaves a few bytes in the buffer. I'm not sure if this is the right solution because the buffers are IO buffers. On the other hand this is the only solution to avoid copying data around, if you want the whole message in a byte array. > 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. > > and > http://mina.apache.org/handling-packet-fragementation.html This shows why you message might be split into several doDecode() calls. Thanks Haug
