On Thu, 5 Feb 2004, Robert Collins wrote:
> It was only ever needed for challenge reuse. I haven't looked at the
> patch you've done yet - have you eliminated the challenge reuse option
> too?
No, but it has been restricted to not have more than one concurrent client
per challenge so it is kind of worthless at the moment.
> (You need to). The reason for the deferring was to ensure that the
> helper didn't change the challenge unexpectedly
And I can tell you this failed totally. Helpers were rechallenged randomly
with no apparent pattern.
> the early helpers didn't have enough protocol control to choose their
> own challenge. With Samba3 thats fixed. However, the only reason for
> reuse was to avoid saturating the old compatability mode interface to
> the PDC with expensive calls, which invariable dropped the link to the
> helper. Thus - get rid of reuse and it will be a lot simpler.
Correct. With the winbind helpers the only reason to use challenge reuse
is to not have to run as many helpers, but the complexity involved for
doing this is not worth the effort.
> > management. Implementing overlapped requests for stateful helpers is
> > significantly with the deferred layer ripped out.
>
> ^easier^ ?
Yes ;-)
> Yes, rip it out. We can't quite eliminate stateful helpers completely,
> until we can get a challenge from helper 1 and submit it to helper 2.
> But we can certainly (with Samba3 & Guido's helper) have multiple
> parallel challenges in use.
The stateful helper design should not be eleminated in my opinion. That
part is good for this purpose. Making the helper challenge neutral puts
too much requirements on the helper design.
The overlapping requests design solves all of these problems quite nicely
by allowing a single helper to maintain multiple states. The helper
protocol only needs very minimal changes to support this, and with a
threaded helper or similar the exact same net effect as if the stateful
helpers was eleminated completely.
Regards
Henrik
Received on Thu Feb 05 2004 - 02:49:08 MST
This archive was generated by hypermail pre-2.1.9 : Mon Mar 01 2004 - 12:00:04 MST