directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wes McKean" <>
Subject Re: Re: [asn.1] Decoder service design ( was: Paper on original SNACC)
Date Fri, 23 Jan 2004 19:22:24 GMT
Amen!  I was honestly very worried about the start and the stops...  Not now...


---------- Original Message ----------------------------------
From: Alex Karasulu <>
Reply-To: "Apache Directory Developers List" <>
Date:  Fri, 23 Jan 2004 14:04:30 -0500

>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
>> > >> >request.  One thread to deliver the event, and another to read
>> > >> >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
>> > >> >I don't know how complex that would be.  And when processing a
>> > >> >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