On 6/15/07, Emmanuel Lecharny <[EMAIL PROTECTED]> 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 far.
- 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. Enrique
