Re: KITTEN: IETF 75 - 76

[Nicolas Williams <Nicolas.Williams at sun.com>]

On Wed, Sep 02, 2009 at 09:46:33AM +0200, Stefan (metze) Metzmacher wrote:
> Michael B Allen schrieb:
> > When you call the function with the flag GSS_C_NOWAIT, the
> > implementation transmits the network request [1] and then checks to
> > see if data can be read (such as by using select(2)). If data is not
> > available, the function simply returns a status of EAGAIN. Now the
> > caller is free to perform other work (and thus it is async). But the
> > caller now knows that the function needs to be called again to
> > complete the operation. So later, it calls the function again. If
> > the network response has been received, it returns success.
> > Otherwise, if GSS_C_NOWAIT was supplied, it again returns EAGAIN. If
> > GSS_C_NOWAIT was not supplied, it waits for the operation to
> > complete (e.g. for a network response to be received) just like the
> > non-async call. In fact async and non-async uses the same function -
> > the GSS_C_NOWAIT flag alone controls async behavior.
> 
> That is true for system calls like send() and recv(), where the caller
> is supposed to call select. But for gssapi the caller would have to poll
> like this:
> 
> while (1) {
> 
> 	ret = gss_call(&minor, ...);
> 	if (ret != 0 && minor == EAGAIN) {
> 		continue;
> 	}
> 	...
> 	break;
> }
> 
> Or the application needs to try every few milli seconds...

Absolutely no polling.

Async I/O is not rocket science.  We can quibble over details, but we've
only got so many workable models.  And we have to be mindful that not
one model will result in fully portable application code.

Here are some reasonable models:

 - Completion callback (or, rather, a callback indicating that there's
   work to do, not necessarily completion)

   This implies either a threaded process model or an async I/O process
   model with one common event loop provided by the OS.

   This model is the simplest for apps to use, and it will be portable
   to Linux, *BSD, Solaris, Windows.  But not necessarily to embedded
   devices, real-time OSes, etc...

 - Return handles to I/O resources that the app can feed into its event
   loop.

   This is much more OS-specific.  On Unix/Unix-like OSes this means
   returning an array of file descriptors.  On Windows it means
   returning and array of file handles.  This too may not be terribly
   portable.  And it requires that the application plug the returned
   resources into its event loop, and take them out, on every call to
   these GSS functions.

I much prefer the callback model.  It will yield the most portable and
simplest code, even if it does not yield universally portable code.

> If the gss_init_sec_context implementation has finished the work
> it notifies the callback that it's done. But to get the actual results
> the caller needs to call the gss_init_sec_context_async() function again
> (or the gss_init_sec_context_output() function) and pass the same async
> cookie.

The partially established context argument is suitable for use as a
"cookie", therefore we don't need an extra cookie.

Callers of GISC and GASC today already have to ensure they're using all
the same input arguments (except for input tokens, of course), on every
call related to one security context establishement.  Therefore it seems
to me that it's not much to ask that async callers do the same.  That
means we can keep the callback prototype simple: it should take one, at
most two, arguments: a void * private data argument, and possibly the
"cookie" that you mention, which in this case would be the partially
established security context.

> I think something like this would make the api at least useful for Samba.

Anything that will actually work will, indeed, be useful to Samba.

Note that Samba can implement such a thing _now_ by using a worker
thread.