directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From directory-...@incubator.apache.org
Subject [Apache Directory Project Wiki] Updated: TLVPageInfo
Date Fri, 18 Feb 2005 06:21:23 GMT
   Date: 2005-02-17T22:21:22
   Editor: AlexKarasulu
   Wiki: Apache Directory Project Wiki
   Page: TLVPageInfo
   URL: http://wiki.apache.org/directory/TLVPageInfo

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -19,11 +19,13 @@
 
 Labels are numbers used to identify elements in a '''SET''' (see Asn.1 grammar), for instance.
Generally, we don't have to deal with label above 30, which can be encoded in 5 bits (so this
kind of '''Tag''' will be 1 byte long), and never above 1024. In the LDAP ASN.1 grammar, no
label exceed 19 (in ''LdapMessage'', the ''ExtendedResponse'' label is 19), so we can focus
on 1 byte tags. Whatever, it could be interesting to accept longer labels to be able to support
any LDAP evolution (or other protocols, as this '''Tag''' decoder is not specifically written
for LDAP)
 
-''In the current setup we use a Java primitive int to store a maximum of 4 Tag field bytes.
 The Tags within a protocol can be pre-fabricated.  An enumeration constant can be reused.
 This way all we need is a 4 byte reference to the constant to represent the tag value.  This
works well especially for using the enumeration type's value for switch statments.  Today
here's how we pack Tag bytes into a Java primitive int:''
+''In the current setup we use a Java primitive int to store a maximum of 4 Tag field bytes.
 The Tags within a protocol can be pre-fabricated.  An enumeration constant can be reused.
 This way all we need is a 4 byte reference to the constant to represent the tag value.  This
works well especially for using the enumeration type's value for switch statments.  Today
here's how we pack Tag bytes into a Java primitive int.''
 
 [http://incubator.apache.org/directory/subprojects/asn1/images/tag-integer-encoding.png]
 
-''Looking at the automaton below it occurred to me that we can create two different Tag decoders.
 A stateless one for protocols that only requires a single byte Tag.  You get whole bytes
delivered in buffers so no need to keep state right?  The stateless Tag really simplifies
the automaton ;).  For multibyte protocols we do collect bytes in a TagOctetCollector which
is just a wrapper around a Java int.  Do you think this needs to be revamped?''
+''Looking at the automaton below it occurred to me that we can create two different Tag decoders.
 A stateless one for protocols that only requires a single byte Tag.  You get whole bytes
delivered in buffers so no need to keep state right?  The stateless Tag really simplifies
the automaton ;).  For multibyte protocols we do collect bytes in a TagOctetCollector which
is just a wrapper around a Java int.  Do you think this needs to be revamped?  In the case
of a protocol where the number of Tag octets can be greater than 1 we can use a less efficient
stateful Tag decoder which needs the full logic of the automaton.  I know this is just some
extra if-then-else logic but that adds up for every byte.  So we can swap out the Tag decoder
used based on the protocol.  Most hopefully will take the simple tag decoder and not pay too
much of a penalty.''
+
+''BTW note that if we have a protocol with more that 30 tags we only need one multibyte tag
decoder per stream.  This is a per connection setup cost paid once and not for every Tag that
comes through.''
 
 Decoding a Tag has to follow the finite state automaton showed on this picture :
 

Mime
View raw message