directory-dev mailing list archives

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

> From: "Wes McKean" <wmckean@logictrends.com>

> >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



Mime
View raw message