Re: KITTEN: IETF 75 - 76
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: KITTEN: IETF 75 - 76
On Tue, Sep 01, 2009 at 02:27:04PM -0700, Love Hörnquist Åstrand wrote:
> >Here's another based on background threads and a completion callback
> >instead of an event notification:
> >
> > major = gss_init_sec_context_async_cb(&minor,
> > cred, &ctx, target, mech, req_flags,
> > GSS_C_INDEFINITE, cb, &input_token, &output_token,
> > &ret_flags, NULL, cb_func, &cb_data);
>
> The callback should take all output variables, for example:
As I imagined it the callback would only be to indicate that GISCACB()
must get called again to complete its work. (And it might well need
fail to complete at that point.
Think of krb5_gisc: it may need to do multiple DNS lookups, and multiple
TGS exchanges; each time that some I/O is ready that it needs it could
call the callback, the app then calls back into GISCACB(), krb5_gisc
makes some progress, and if it'd block then it returns continue-needed
without an output token. Lather, rinse, repeat.
I like it better that way. If we add a new version of GISC with new
outputs we'll need not only a new GISC_async, but also a new callback
function prototype. Having the callback lead to the application calling
GISCACB() again seems reasonable and simple enough to me. I'm not
wedded to this, but it does seem simpler.
The callback in the credential iterator can be the way you propose.
That's because it doesn't need every output of gss_inquire_cred*(), just
a cred handle and mechanism OID, and it can find the rest from that.
Nico
--
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.