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
