mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michaël Figuière <michael.figui...@gmail.com>
Subject Re: [MINA 3.0] Buffer Design
Date Mon, 10 May 2010 14:52:48 GMT
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

Now, if we consider these Stream objects as blocking queues, then the Stream
interface bring us a convenient first step of the SEDA design which is in
the Mina 3.0 wish list (http://mina.apache.org/mina-30-design.html). The
other part of the SEDA stage design would be a thread pool which could be
optionally put in front of filters to make their execution asynchronous.

Following this idea Stream interface would, in its simplest form, look like

public interface Stream<K> {
   void write(K item);
   K read();

Maybe in this context read() / write() would confuse the user about what is
actually done, so it may make sense to expose methods such as getNext() /
The underlying implementation could be a blocking queue, a priority queue
(if we want to enable some easy to implement QoS filters), a synchronous
invokation of the next filter in chain, ...

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.

Here, Stream would actually become a extended remplacement for IoBuffer.

Comments about all this ? Does it make sense ?


On Mon, May 10, 2010 at 2:11 PM, Ashish <paliwalashish@gmail.com> wrote:

> Time to be back to 3.0 :)
> We had couple of discussions around Filter Chain, Selectors etc.
> Meanwhile, I just took a step back and was wondring how would we pass
> on data around aka buffer design.
> From our 3.0 design page we have these two bullets
> - We should not wrap ByteBuffer into our own IoBuffer class. We should
> have a list of ByteBuffers instead, containing all the ByteBuffers..
> - The chain API should be modified to expose Streams of generic types
> (Stream<K>) instead of IoBuffer, allowing us to add more than one
> codec filter in the chain (each Filter being aware of the kind of
> Object it can manipulate)
> I think it would be a good idea to have some brain storming around
> this and have something concrete for this. Since it will be one of the
> core constructs, we would need it at most of the places.
> Thoughts?
> thanks
> ashish

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message