directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wes McKean" <wmck...@logictrends.com>
Subject Re: [asn.1] BER codec design
Date Sat, 24 Jan 2004 14:48:47 GMT
I am a very very strong component of the KISS principle.  The easier it is to understand, the
less likelyhood something has to break, and the easier it is to get more or other people to
work on it.  With that in mind, I believe the encoding and decoding should continue to use
an event based architecture.

Given that it is highly unlikely that the thread passing objects to the encoder needs to care
about what's done with them after they are encoded, we can simply register a sink with the
encoder, and every time it fills up a ByteBuffer, it simply fires an event off to the sink
which processes it.  I assume this sink would place the ByteBuffer on the output queue for
the socket, given that the object writing to the socket should be in its own thread.  (Hell,
since the sink is just an interface, it could be implemented by the same object utilizing
the encoder, so it would *know*).  Using this method, the code feeding the encoder only has
only one thing to worry about.

Now, as far as decoding goes...  I see the thread reading the ByteBuffers, and the thread
doing the decoding as two separate entities.  The reader thread reads a ByteBuffer, puts in
the queue of the decoder.  Now, here's the trick.  The decoder may or may not be currently
decoding.  If a thread is running the decoder, then the buffer will be picked up by this thread.
 If the decoder is not currently running, then a thread is picked from the pool, and started
on the decoder.  Once the decoder has a complete PDU, ASN stub, or whatever, it fires an event
on its own sink for a process to handle the TLV tree.

I don't think this process is overly complicated.  If you can keep a clear picture of how
many threads there are doing the recieving, decoding, encoding, and sending...

Wes

---------- Original Message ----------------------------------
From: Alex Karasulu <aok123@bellsouth.net>
Reply-To: "Apache Directory Developers List" <directory-dev@incubator.apache.org>
Date:  Fri, 23 Jan 2004 23:30:13 -0500

>Hi all,
>
>It seems to me like Wes' breaking down the BER encoding/decoding into two
>steps with an intermediate structure.  This intermediate structure is the
>(BER specific) TLV tree Wes mentioned before.  
>
>1). The first is to go from the binary encoding to a binary encoded TLV 
>    tree and vice versa.  The TLV tree is just a structure reflecting the
>    containment tree of the ASN.1 datatype.  Each leaf in the tree is a
>    simple (non-composite) ASN.1 type with label and value.  I'm very
>    interested in your ideas for representing this TLV tree BTW.
>
>2). The second takes you from a TLV tree to a populated instance of a
>    data structure stub (an Object of the stub class) and vice versa.
>
>Question is do we design this process into the server with non-blocking
>staged processing in mind or do you generate stuff conforming to what 
>works best for this BER codec?  I think we design for the BER codec
>but keep in mind we perform chunk wise operations.  So when encoding
>we ask for the first chunk and keep going back for more until we're
>told all has been transferred for that encoding.  Likewise for decoding
>we give chunks one chunk at a time until we're told we have enough for
>a single decoding session.
>
>Also I think we might have to define multiple sub-codecs composing the
>stages of a larger ASN.1 BER codec like so:
>
>          codec A           codec B
>              
>--------- decoder --------- decoder ---------
>-       - ------> -       - ------> -       -
>-Encoded-         -TLVTree-         -Decoded-
>-       - <------ -       - <------ -       -
>--------- encoder --------- encoder ---------
>
>Let's just look at codec A.  Here we of course need to know what our
>tree classes are to build the right args but for now presume we are
>working with Objects.  
>
>interface EncoderA
>{
>    SessionKey encode( ByteBuffer a_buf, Object a_inTree ) 
>        throws EncodingException ;
>
>    boolean encode( ByteBuffer a_buf, SessionKey a_key ) ;
>}
>
>The encoder encodes binary data into an NIO byte buffer.  Both
>methods reflect this.  However notice that the first returns a
>SessionKey and actually takes the TLVTree as an Object type.
>The first method returns null if it can fit all of the encoded
>image of the TLVTree into the buffer.  If it cannot it saves its
>state in the encoding process initializing a session for the
>encoding and returns a key to access that state once again to
>continue the process.  So for the most part small response PDUs 
>should only require one call to the first encode overloaded 
>method without incurring any session and key obj creation 
>overheads.
>
>If however the encoded image cannot fit into the buffer then
>the session objects are created and a non-null key is returned.
>The buffer btw should be completely full.  Calls to the second
>method get the next chunk of encoded data which is again deposited 
>into the provided ByteBuffer.  This method unlike the first 
>requires the session key to continue the process.
>
>I'll come back to the rest later but this is how we get an encoder
>to return chunk wise data that is conducive to the SEDA architecture.
>I think we could use this interface as the interface for the entire
>BER encoder and not just for this phase of the encoding within codec 
>A.
>
>I'll come back to this again later.
>
>Alex
>
>

Mime
View raw message