On 14 Jan 2003, [EMAIL PROTECTED] wrote: > get_mutex: > ServerReqChallenge > ServerAuthenticate2 > release_mutex:
Yes, that's what we meant. I hypothesized to ab that in NT there is some kind of table indexed by IP (or client name?) holding the challenges. I wonder why? <speculation> Perhaps there's no per-tcp-connection data area easily accessible from their RPC server, so when it sends out a challenge it can't easily be associated with that TCP socket. I'd guess that if it's a generalized RPC server then the challenge can't be stored on the stack either. The obvious thing, then, is to have a table shared between all threads in the RPC server process, indexed by IP and storing the currently-outstanding challenge. This suggests an alternative implementation for us: rather than using the mutex to make this a critical section, we instead have a machine-wide tdb storing the outstanding challenge from each server. Whoever gets around to authenticating next will remove the challenge from the tdb and use that. Mind you I can't see any way in which this is better than the current approach, and it's probably more fragile. :-) -- Martin
