Mailing-List: contact directory-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List"
 <directory-dev@incubator.apache.org>
From: Wes McKean <wmckean@logictrends.com>
Organization: Logic Trends
To: "Apache Directory Developers List" <directory-dev@incubator.apache.org>
Subject: Re: [snickers] Work on non-blocking ASN.1 BER API
Date: Mon, 15 Dec 2003 13:16:22 -0500
User-Agent: KMail/1.5.4
References: 
 <20031212192919.BSOZ1876.imf16aec.mail.bellsouth.net@mail.bellsouth.net>
In-Reply-To: 
 <20031212192919.BSOZ1876.imf16aec.mail.bellsouth.net@mail.bellsouth.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200312151316.22106.wmckean@logictrends.com>

> Here's what I have in mind.
>
> The InputEvent processing stage should really be a place where
> Decoders are managed one dedicated to each client.  A decoder is
> a simple object that takes a ByteBuffer and reads it partially
> populating a PDU Message.  The decoder must also track where it
> left off so it can continue to populate the Message envelope when
> new buffers with peices of the PDU arrive.

Let's bring some of the things I have learned to the table, as far as server 
side NIO goes.  The implementation in Windows definitely has some issues, as 
does the implementation  in Linux, I think.  You basically have to do all of 
your connect, event, read processing in the same thread.  Which is where I 
think that you got the above idea from.

This means that the input comes in from one thread, and the decoding takes 
place in another thread.  What I did to fix this, was I created a 
non-blocking, NIO input stream, that I fed to the decoder, so all it had to 
deal with was an InputStream.  Sure, it still returned 0 if nothing was read, 
but the decoder can handle that.  The thread doing the read events basically 
fed the ByteBuffers to the non-blocking NIO input stream.  This stream object 
was responsible for maintaining the different byte buffers, the next 
character read, EOF, etc.

Someday, when the NIO stuff is rock solid, we want the InputStream to be tied 
directly to a SocketChannel, I think, so the reading can be done in the 
thread that is doing the decoding.

>
> The DecoderManager can then be implemented as a Stage where
> workers processing InputEvents, use the payload buffer of the
> event to call decode( ByteBuffer ).  The worker adding the
> last InputEvent to complete a PDU also triggers the creation
> and publishing of a RequestEvent which carries the marshalled
> Message envelope object representing the PDU.
>
> I spoke to Wes about this stuff on IRC and he volunteered to
> work on it.  I will try to help as well but I'm spread thin.
> If others are interested please feel free to join the effort.
> Basically what will be come snickers for Java will be based
> on this code.  Also in the next few days lets try to discuss
> this and the design.

Wes