On 5/10/10 4:52 PM, Michaël Figuière wrote:
Here are some thoughts :
As you mentionned, buffer design is tightly linked to the codec filter and
stream API mina will offer to users. The current ProtocolEncoder/Decoder
interfaces :
void encode(IoSession session, Object message, ProtocolEncoderOutput out)
void decode(IoSession session, IoBuffer in, ProtocolDecoderOutput out)
would give, with Stream<K>, something like :
void encode(IoSession session, Stream<I> in, Stream<O> out)
void decode(IoSession session, Stream<I> in, Stream<O> out)
Note that this looks pretty clear at the first sight for the user. The K
parameter in Stream<K> would in practice be :
* a ByteBuffer or a ByteBuffer array for the in stream of decode() and out
stream of encode() for the outermost codec filter
* a Pojo for all the other streams
This is pretty much what is described here :
https://cwiki.apache.org/confluence/display/MINA2/MINA+3.0+Design
Now, if we consider these Stream objects as blocking queues,
That would be a problem in the decoder, if we are blocking while getting
a byte from the incoming Stream. We should be able to get data from the
stream until the point we have nothing more remaining, then we have a
way to quit the loop properly.
If we were blocking, we would consume a thread until the data is flowing
again, and we don't want threads to be waiting in MINA. Let's say that
this design works well when you have a 1-1 relation between a socket and
a thread, but not in our case.
In this scenorio, expecting ByteBuffer arrays and not just ByteBuffers as
parameter of Stream seems to be a prerequisite to allow message reordering
(once again for QoS, or just due to some protocol logic), as complex
messages may be written in several ByteBuffers.
yes, but the BB will be ordered in any case. We will read BB one by one
anyway, so I don't think we should allow an array of BB to be added in
such a Stream.
Here, Stream would actually become a extended remplacement for IoBuffer.
Yop.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
