directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <>
Subject Re: Kerberos PDU decoder performances
Date Sat, 16 Jun 2007 04:04:45 GMT
On 6/15/07, Emmanuel Lecharny <> wrote:
> ...
> Some possible improvement :
> - switch to the LDAP decoder should be possible without a lot of
> effort. DER and BER are very closed, and we can modify easily the LDAP
> decoder to support DER

I'm 100% behind this.  If you can at least jumpstart the conversion, I
can commit to finishing it.  By jumpstart I'm picturing you might add
DER support and write some examples of codecs so I can see how it
would work.  I could then convert the rest of the codecs and make sure
everything works and do final troubleshooting.  I will be adding
better unit tests, hopefully this weekend, so the timing is good to
make a big change like this.

There are 2 things we'll need for Kerberos that may not have come up in LDAP:

1)  In addition to decoding PDUs there are a couple message objects
that we need the raw undecoded bytes for.  Examples would be the
KdcRequest and the Ticket.  The KdcRequest bytes need to be saved in
the session for later validation of a (keyed) checksum.  The Ticket
bytes are needed to pass undecoded as credentials for cases where
decoding might strip proprietary or unsupported extensions.

2)  As you saw, the EncryptedData structure carries data that requires
decryption/encryption outside of the codecs.  So in addition to codecs
in the filter chain, we'll need "one-shot" codecs for these message
parts, to be used in the handler.  There are ~10 of these in use so

> - switching to shared-ldap decoder would improve a lot the
> performance. For a similar PDU size (less than 255 bytes), and
> complexity, we can decode around 200 000 PDUs in shared-ldap (it
> depends on which kind of treatment we do with the data, of course).

W.r.t. 200 000 do you mean "per second"?  That would be a lot better.


View raw message