mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raphaël Barazzutti <raphael.barazzu...@gmail.com>
Subject Re: Codecs and CumulativeByteBuffer
Date Mon, 17 Jun 2013 14:54:38 GMT
Hi Emmanuel,

Thanks for your helpful comments,

I think that I've now a better picture of how you expect things to
work with IoBuffer.

For sure IoBuffer is per session and not shared. But more
specifically, I see that a the context should be an object pointing to
IoBuffer and not an IoBuffer directly.

Thanks again and have a nice afternoon,



On Mon, Jun 17, 2013 at 2:50 PM, Emmanuel Lécharny <elecharny@gmail.com> wrote:
> Le 6/17/13 1:47 PM, Emmanuel Lécharny a écrit :
>> 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
>> fragmented.
>> 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 ?
> Forgot to mention that the IoBuffer *must* be stored in the Session
> context, and not shared.
> Also note that we are using one single ByteBuffer to read data from the
> Channel, so this ByteBuffer must be copied into the IoBuffer. You need
> to dup it, in other words.
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com

View raw message