Re: Status on NTLM in Squid3?

From: Henrik Nordstrom <hno@dont-contact.us>
Date: Sat, 6 Nov 2004 00:06:45 +0100 (CET)

On Fri, 5 Nov 2004, Andrew Bartlett wrote:

> So, on EOF on the input, we should look at the outstanding requests (say
> off at the DC, awaiting a response) and wait for them to complete before
> shutting down the helper?

Correct. The EOF on input currently just says there won't be any
additional requests send by Squid, but any yet unanswered requests already
received by the helper still need to be answered.

Thinking about it we could just as well define EOF to mean "quit now", and
make Squid delay the EOF signal until it has seen responses to all pending
requests. Both approaches have their pros and cons, but the delayed EOF
should make life considerably easier in the helper implementations which
is a real good thing. For Squid it is trivial.

Opinions?

If not I'll redefine the protocol to have EOF to the helper mean "shut
down immediately" to simplify the helper implementations and provide
quicker shutdown causing pending helper requests to be aborted on
shutdown.

Or in other words, if a helper sees EOF it should exit unconditionally.

>> a) For stateful helpers it allows the same helper instance to maintain a
>> large number of sessions. In case of NTLM it allows the same helper to
>> have multiple pending challenges.
>
> Simply avoiding all those processes will make this a big saving.

Indeed, and was the primary reason why we got to thinking about a protocol
like this in the first place.

>> b) In all helpers it allows batching of several operations, reducing the
>> amount of context switching required.
>
> So squid could well ask for 4 challenges, one after the other?

Yes. Or 2 challenges and 2 authentication request, or any combination.

In reality Squid sends the requests immediately to the helper connection,
but the context switch may happen later and at that point Squid may
already have sent additional requests to the same helper, each with a
different identifier. So when the helper finally reads it's input there
can be any number of requests available. And similarily in the return to
Squid, if the helper answers the pending requests quicker than Squid can
read the responses multiple responses become available in one read call to
Squid.

In most helpers reading one request at a time using fgets then this is
hidden by the libc, but advanced (or in some cases stupid) helpers reading
their requests by other methods need to be careful to do it correctly or
they may risk corrupting the request stream.

Regards
Henrik
Received on Fri Nov 05 2004 - 16:06:48 MST

This archive was generated by hypermail pre-2.1.9 : Tue Nov 30 2004 - 12:00:03 MST