The idea is that in a protocol you know what a frame looks like. For example you might know that a frame consists of an integer id, a string command name and then depending on the particular command, a variable number of integers.
In that case you know that if you have only 4 bytes in the buffer that you cannot fully decode a frame so you "need data". If you have enough data to read the integer plus the string you could then look up how many integers you need following that and if you don't have enough bytes, return that you "need data".
In the decode method returning null does not mean you need data.
Note that this implies that for efficiency you should avoid designing your protocol so that you need to run through lots of data before you can determine whether you have enough data to decode an entire frame. So putting a size field right at the start is a good idea. In that case, the decodable() method can be pretty simple.
Robert
| "Andres Quijano" <[EMAIL PROTECTED]>
14/06/2006 21:00
|
To: [email protected] cc: Subject: ByteBuffer remaining and hasRemaining |
Hi
I'm new to MINA. I've been going through the examples and I'm not
quite understanding how the NEED_DATA and returning null in the
decoders work. Specifically, I do not understand the remaining and
hasRemaining method in ByteBuffer.
The example decoder goes like this:
if (in.remaining() < Constants.HEADER_LEN) {
return MessageDecoderResult.NEED_DATA;
}
I interpret it like "if there are less remaining bytes than the size
of the header, we need more data", which doesn't make sense.
Also, I tried to do something like this in a decoder:
if (in.hasRemaining()) {
return null; // Need more data.
}
On the beggining of the method. The method get's called three times,
and it never returns false on the hasRemaining method.
The question goes simply to: how to know if there's enough data when
decoding an object with many primitives and some strings (of variable
size)?
Thanks
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.
