directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <elecha...@gmail.com>
Subject Re: Incompatible HostAddressType with RFCs
Date Mon, 02 Jul 2007 09:38:50 GMT
Hi,


On 7/2/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
> On 6/26/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> > Oh, ok.
> >
> > I was also thinking about switching from Class to Enum for those types.
>
> I like the way the current Class enumerators allow for a descriptive
> toString(), which is useful during logging.  I didn't think you could
> replicate that with enums.

Enum are just wrappers for classes, but with special syntaxes. Here is
an example of conversion, where you can see that we also have the
toString() method :

package org.apache.directory.server.kerberos.shared.messages.value.types;

import java.util.Arrays;

public enum TransitedEncodingType
{
    /**
     * Constant for the "null" transited encoding type.
     */
    NULL( 0 ),

    /**
     * Constant for the "Domain X500 compress" transited encoding type.
     */
    DOMAIN_X500_COMPRESS( 1 );

    /**
     * Array for building a List of VALUES.
     */
    private static final TransitedEncodingType[] values =
        { NULL, DOMAIN_X500_COMPRESS };

    /**
     * A List of all the transited encoding type constants.
     */
    public static final List VALUES = Collections.unmodifiableList(
Arrays.asList( values ) );

    /**
     * The value/code for the transited encoding type.
     */
    private final int ordinal;

    /**
     * Private constructor prevents construction outside of this class.
     */
    private TransitedEncodingType( int ordinal )
    {
        this.ordinal = ordinal;
    }

    /**
     * Returns the transited encoding type when specified by its ordinal.
     *
     * @param type
     * @return The transited encoding type.
     */
    public static TransitedEncodingType getTypeByOrdinal( int type )
    {
    	switch ( type )
    	{
    		case 1 	: return DOMAIN_X500_COMPRESS;
    		default : return NULL;
    	}
    }

    /**
     * Returns the number associated with this transited encoding type.
     *
     * @return The transited encoding type ordinal.
     */
    public int getOrdinal()
    {
        return ordinal;
    }

    /**
     * @see Object#toString()
     */
    public String toString()
    {
    	switch ( this )
    	{
    		case DOMAIN_X500_COMPRESS :	return "Domain X500 compress (1)";
    		default : 					return "null (0)";
    	}
    }
}


>
> > FYI, I have started to write some encoders for simple Kerberos
> > constructs (like PrincipalName, EncryptionKey,etc) and it works pretty
> > well. The idea is to extend the existing classes by adding a couple of
> > methods, so that you ask them to 'encode' themselves :
>
> OK, so it sounds like the message class and its codecs are combined,
> similar to how JAAS KerberosTicket works.
>
> Sounds good, especially the speed boost.

I will soon commit some code. It's really faster.

FYI, the most important
> class, which directs the heavy lifting, is CipherTextHandler.

Yes, I noticed it's the place where we have huge CPU consumption while
running some tests. There may be some ways to improve this class, but
I want to finish the codec stuff before, because it's the easiest way
for me to get a grip on the whole thing, learning all the vocabulary
and interns of Kerberos from the low level layer.

> CipherTextHandler contains the static hashed adapters that actually
> make use of the Encoder/Decoder interfaces, so this is where
> compatibility with the new codecs is key.  This is for the "one-shot"
> codec use.

I see. It should not be a pb at all.

>
> >                 PrincipalName principal = new PrincipalName(
> > PrincipalNameType.KRB_NT_PRINCIPAL, "Test" );
> >
> >                 ByteBuffer encoded = ByteBuffer.allocate( principal.computeLength()
);
> >
> >                 principal.encode( encoded );
>
> Is this for the "one-shot" use or also how the codecs are used in the
> codec filters?  I ask because all of the JCE crypto works with byte[]
> so anytime one of the current Encoder-using Kerberos objects is
> "one-shot" encoded it is immediately encrypted using the byte[] form.
> If this is a no cost operation than it is OK but I thought you should
> be aware.  It may be slightly nicer for the API to use a byte[].

I have used ByteBuffer just to be in synch with MINA, as MINA is using
ByteBuffers.  The overhead is almost unnoticeable. Switching from
ByteBuffer to byte[] is barely the same operation then switching from
String to char[] : an access to the intern array.

>
> Enrique
>


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com

Mime
View raw message