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, Regards, Raphaël On Mon, Jun 17, 2013 at 2:50 PM, Emmanuel Lécharny <[email protected]> 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 >
