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 12:50:51 GMT
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 


Mime
View raw message