mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: Codecs and CumulativeByteBuffer
Date Mon, 17 Jun 2013 11:47:05 GMT
Le 6/17/13 1:32 PM, Raphaël Barazzutti a écrit :
> Hi Emmanuel,
> Thanks for your comments!
> I imagine that slice() method would have a behaviour similar to the
> one of ByteBuffer. As in ByteBuffer, position based values (position,
> limit and mark) of the slice would be independent copies of the
> original IoBuffer ones, but the buffer content itself would be shared.
> Then, the position based values would logically be consistent between
> the original and the new slice.
Absolutely. Is this a problem, assuming that once the decoding is done,
the IoBuffer will be discarded ?
> In decoders, IoBuffer would be used as a kind of sliding window,
> consequently position based values would be monotonically growing
> series (and thus limited to Integer.MAX_INT). What do you think?
This is not exactly what I have in mind.

The need, as I understand it, is to keep a track of incoming data, up to
the point you can consider the full data has been decoded. This can be
done through many calls to the channel.read() method, as the data may be

In any case, either you consider that what have been decoded can be
discarded, or must be kept up to the end.

Let's consider the first case : you need to write a stateful decoder to
'remember' where you stopped, so that you can start again when some more
data are received. This is the best possible solution, but this is also
the more complex one. One of the constraint is that you must keep a data
structure in memory to hold the partially decoded structure.

In the second case, you have to keep all the incoming bytes until you
know that you can decode them. This is typically the case whan you know
the size of the data you will get (iether because the PDU has a fixed
size, or because you were able to decode the data length from the
incoming data). In this case, you don't really care to have a specific
system that keep a track of the current position : either the total
length of data in your IoBuffer is what you expect, or you need to read
more bytes.
One small thing to consider though : the length might be split, too...

So all in all, whatever use case, it seems to me that IoBuffer covers
all the needs. Do I missed something ?

Emmanuel Lécharny

View raw message