threading best practices?

[Chris Hecker]

> krb5_mk_req*() should not require any DNS lookups.
> krb5_sname_to_principal() can do blocking network I/O for principal
> canonicalization (let's not get started on that) and
> krb5_get_credentials() can do blocking network I/O (TGS exchange(s)
> to get the desired service ticket).

Cool, thanks for the pointers.  I'll keep track of any issues I run into 
and document them on the wiki or something.

>> I'm building a test program so I can figure out exactly what needs
>> to be where for my use-case.
> Great!

I'd be happy to contribute it back, but sadly I'm not sure how to do the 
threading stuff in a cross platform way.  Speaking of which, I've ported 
some of the samples to work on Win32, I'll try to clean those up and 
contribute them back.

I may also try to get kadmin running on Win32 at some point, since it 
looks like a bunch of people have asked about it in the past, and it 
would be handy for me to have.

Chris

On 2011/07/22 15:10, Nico Williams wrote:
> On Fri, Jul 22, 2011 at 4:46 PM, Chris Hecker<checker at d6.com>  wrote:
>>>> Okay, so if I krb5_get_credentials on the KDC thread, I can then
>>>> use them in the main thread with a different context...
>>> Yes, pretty much.
>>
>> So, I should create the auth_context in the thread that's doing the
>> actual communication with each other machine, right?  There seem to be
>
> Yes, but that's not a requirement.
>
>> some calls to DNS in various functions, so I'm going to need to be
>> careful to make sure everything's cached in the KDC thread so nothing
>> blocks on the other threads...
>
> krb5_mk_req*() should not require any DNS lookups.
> krb5_sname_to_principal() can do blocking network I/O for principal
> canonicalization (let's not get started on that) and
> krb5_get_credentials() can do blocking network I/O (TGS exchange(s) to
> get the desired service ticket).
>
> Why are you not using the GSS-API?
>
>> I'm building a test program so I can figure out exactly what needs to be
>> where for my use-case.
>
> Great!
>
>> I assume I can have multiple auth_contexts in a single thread, as long
>> as I keep straight which one is talking to which other client or server
>> and pass them to mk_safe/mk_priv appropriately...
>
> Right.
>
> Nico
> --
>