mechglue registration of gss_buffer_t pointers

[Nicolas Williams]

I spoke to Sam and he explained why he thinks having a single buffer
allocator could cause problems for mechs written in languages other than
C -- namely, how to use externally allocated memory in a higher level
language's string/buffer abstractions --, but he's not entirely certain
that it can't be done.  I suppose similar objections could be raised for
the idea that the buffers allocated by mechanisms must be preceded by a
header that can help the mechglue route gss_release_buffer() calls.

Sam has anecdotal evidence of folks wanting to use third party
mechanisms with MIT's mechglue, which would argue for having the
GSS-API's C bindings as the SPI, replete with per-mechanism buffer
allocators.  Of course, the fact that there is no standard GSS-API C ABI
makes it difficult (but not impossible) to support such third-party
mechanisms, but perhaps agreeing on an ABI is simpler than agreeing that
mechanisms must use a common allocator.

So what are the requirements?

Performance-wise I think the main requirement is scalability w.r.t.
number of threads, with scalability w.r.t. the number of live buffers
(per-thread) being a secondary requirement.  That is, buffer management
in the mechglue must be thread-hot.  For correctness we must allow
buffers to be de-allocated in different threads than where they were
allocated, but a small performance penatly for this should be OK.
Implied is a requirement for thread-safety, of course.

Sam would like to be able to use the API as the SPI.  I support this
wholeheartedly.  Implied in the API-is-the-SPI requirement is a
requirement that we agree on an ABI, or at least that the mechglue be
able to know and adapt to the ABI used by each plugin (ouch).

So, to sum it up:

Architectural requirements:

 - The GSS-API C library must export the GSS-API v2u1 C bindings.

 - The GSS-API v2u1 C bindings pose a buffer management problem for any
   mechglue with dynamic linking and loading of mechanisms.
   
   (The gss_buffer_desc struct is insufficiently rich and the
   gss_release_buffer() function lacks arguments that could make up for
   the other problem).

 - Yet we'd like the GSS-API v2u1 C bindings to be used as the SPI (the
   interface between the GSS library and its mechanism plugins.

Performance requirements:

 - Any buffer management services provided by the mechglue must scale
   with the number of threads, and quite possibly the number of in-use
   buffers.

   Implied is an architectural requirement for thread-safety that we all
   already agree should apply to MIT's GSS-API C library and mechanisms.
   As with the ABI requirement this means that supporting random third-
   party GSS-API mechanisms developed and deployed before MIT's
   mechglue's ABI requirement is harder (not impossible, just harder).

   (GSS-API tokens are generally short-lived, since they are intended to
   be sent to the peer, but some applications might have, say, re-
   transmission strategies that cause the lifetime of a GSS token to be
   significantly longer than one might expect otherwise.)


Are there other requirements that others would like to see here?  Are
there any that I've missed?

I would be happy with a thread-safe and thread-hot implementation of the
mechglue buffer registration scheme that Sam and Tom propose.  I would
prefer one of the lighter-weight alternatives that I proposed (because
simpler to implement and understand).

Nico
--