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() /
put().
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 ?

Michael


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
>

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