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
