directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Re: [asn.1] Decoder service design ( was: Paper on original SNACC)
Date Fri, 23 Jan 2004 19:04:30 GMT

Oh and furthermore since you are using TLVs you don't care about the
content or datatype.  Just focusing on the TLVs keeps the picture
simple and allows you to manage state easier with starts and stops.

That sounds good to me Wes - I'm liking it the more I think about it.


> From: Alex Karasulu <>
> Date: 2004/01/23 Fri PM 01:36:10 EST
> To: "Apache Directory Developers List" <>
> Subject: Re: Re: [asn.1] Decoder service design ( was: Paper on original SNACC)
> > From: "Wes McKean" <>
> > >How many threads are used while decoding a message in toto?
> > That's a good question.  My guess is that there would be a pool of 
> > threads doing the decoding, like the current architecture.  Is it 
> > safe to assume that it is OK for a thread to block while waiting for a
> > complete ASN.1 messaeg?  I think so.
> You see that's the whole point to this.  We can't have one thread sitting
> blocking.  That means two threads are needed during the times you're in 
> the act of decoding.  One thread reads from the buffer feeding it into 
> the mouth of you're decoder which is driven by that blocking thread.  That's
> what I referred to over here:
> > >> >Ok we want to basically not block or rather dedicate a thread while

> > >> >processing an entire message.  That would mean two threads used per
> > >> >request.  One thread to deliver the event, and another to read and

> > >> >decode it.  So this is the main problem.
> > I've been giving this alot of thought.  It would be easy to parse the 
> > incomming message into a TLV tree.  The parser could do this without having 
> > to know *what* the message is.  This might make it a lot easier to encode a 
> > state driven parser/decoder.  Once the complete message is parsed, it could 
> > then be passed off to something that would try to understand.  I think this 
> > approach will work fine, and it would fulfill our desire to have a non-
> > blocking decoder.
> >
> > What do you think?
> Ok so you are thinking about using a state machine after all? Without 
> blocking to decode I think ...
> So basically the tree you are talking about represents the nesting of
> ASN.1 data structures right in a generalized format but the message
> envelope boundries are known: meaning when it starts and when it ends
> right?
> Ok this sounds sort of like what we were talking about earlier here:
> > >> >The state machine based decoder could read from the 
> > >> >direct buffer and between chunks freeze its state until the next
> > >> >chunk appears.  That would be the best approach as you mentioned but
> > >> >I don't know how complex that would be.  And when processing a chunk
> > >> >the state machine should return even when it has not reached a 
> > >> >terminal state.
> So you basically have a pointer to where you are in the tree of TLVs and
> where in the current TLV you are when you complete reading a chunck out 
> of the buffer handed to you.  Is that what you're hinting at?
> Alex

View raw message