directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <aok...@bellsouth.net>
Subject RE: [snickers] BER Value chunking question
Date Tue, 30 Mar 2004 03:22:50 GMT

> -----Original Message-----
> From: Jeff Machols [mailto:jmachols@comcast.net]
> the logic more complicated.  Also, will it require an additional thread?

No we would not need an extra thread because the entire rig is a state
machine that eats bytes as you feed it.

> If you do it this way, will you still have the ability to have a "hard
> limit" on the size? Or will it depend on the particular TLV?  I like the

Yes we would need some threshold if we were to go with the approach of
breaking up a primitive tlv into a constructed tlv with several children
carrying fragments.  Basically if we hit this limit then we know that we
need to start breaking up the tlv for the string.  Again we only need to
have that small amount (our chunk handling size) in memory to still process
all of the input.

> idea being able enforce a strict limit as opposed to just making this more
> efficient in terms of memory footprint.  This will be a better selling
> point
> for embedding the decoder.
>
> I know this didn't really answer your question, just some thoughts

Yes it did but I'm thinking we might need both approaches.  First because I
already implemented the extra callback :-) and second because trying both
mechanisms together might be good to test the two against one another.

> > -----Original Message-----
> > From: Alex Karasulu [mailto:aok123@bellsouth.net]
> > Sent: Monday, March 29, 2004 5:39 PM
> > To: 'Apache Directory Developers List'
> > Subject: [snickers] BER Value chunking question
> >
> > Hi,
> >
> >
> > <background>
> >
> > For those that are not up to date with the conversation, we added
> > functionality to the BER decoder to chunk large LTV values so memory
> > utilization is kept low.  This is expressed externally by the addition
> of
> > an
> > extra partialValueDecoded(Tuple) method on the decoder callback for the
> > BERDecoder.  This method may be called zero or more times for an
> > encountered
> > TLV.
> >
> > </background>
> >
> >
> > BER allows certain string types whether they be BIT STRING, OCTET STRING
> > or
> > any of the character string types to be constructed TLV's when the size
> of
> > the string is large.  This way a massive string can be broken down into
> > palatable chunks instead of allocating memory for the entire value.
> This
> > helps systems that are memory deficient deal with large values.
> >
> > Instead of explicitly chunking a value I can have the decoder break up
> > these
> > string TLV's when it sees them.  This way the large value appears to
> have
> > been fragmented by the sender even though it was sent in one big chunk.
> >
> > So which way is better?
> >
> > 1). Explicitly chunk the value using an extra callback
> > 2). Implicitly chunk the value by making it appear as thought the sender
> > already fragmented the value before transmission
> >
> > Alex
> >
> >
> 




Mime
View raw message