directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Questions about ASN.1 codec
Date Mon, 31 Jan 2005 16:32:14 GMT
Thanks Alex.

Some remarks :

1) As much of the Ls will be one or two bytes long, isn't it a good idea
to create 3 subclass to handle those case ? 
- a ByteConstructedTuble for every tuple which length is < 127 bytes
- a ShortConstructedTuble for every tuple which length is 1 < L < 256
- a LongConstructedTuble for every tuple which length is 255 < bytes

2) Do we really need an ASN.1 compiler? LDAP protocol is not that
big ...

3) Encoder could be something like a pipeline :
Java classes (representing LDAP operation and responses) + a toNode()
method -> serialization to PDU (special NodeToPDU utility class) ->
dumping the result to a Channel

3) Decoder is much more a complex issue, because we have to deal with
badly formated PDUs (specially crafted PDUs that are written to broke
the decoder). Is a callback system rubust enough to handle a
TLTLTLTLTLTLTLTLTL..(many recursives TLV)... TLV? (could it happen?). I
buy the idea of removing the Digester concept. This is not a generic
ASN.1 decoder, is it?

4) Channels could be a plus. It can deal with ByteBuffer[], so we don't
have to build a byte array before sending it through the socket. You
have a MemoryMapped mech., so it may be used for hudge PDUs (not sure
actually, I'm checking)

Le lundi 31 janvier 2005 à 09:35 -0500, Alex Karasulu a écrit : 
> Emmanuel Lecharny wrote:
> >Hi,
> >
> >I read something about the ASN.1 compiler that is on its way, but is
> >actually hand crafted, but I don't remember were. Could somebody give me
> >the pointer?
> >  
> >
> Yeah everything in ASN.1 runtime for LDAP has been hand crafted.  The 
> stub compiler is not fully operational just yet.  This is something Alan 
> Cabrera is working on.  All LDAP stubbs were hand woven within the LDAP 
> common jar as interfaces with classes implementing them.  They are 
> filled up by this attrocious peice of code that works like the XML 
> digester in commons.  A bad move on my part.  I will redo this garbage 
> when I have the chance to use a better mech than firing rules to 
> populate LDAP stubbs based on tag sequences encountered within the ASN.1 
> tag stream.  What works for XML SAX processing does not necessarily lead 
> to a fast ASN.1 runtime heh.
> I have a page where I describe what needs to be done to make the ASN.1 
> RT really fast.  Here's that doc...
> I should get to this around next month if someone does not beat me to it.
> Cheers,
> Alex

View raw message