Re: read_timeout is not reset correctly in tunnel.cc

On 20/04/2012 8:27 p.m., Jean-Philippe Menil wrote:
> Hi,
>
> like disussed earlier on the squid-users mailing list
> (http://www.squid-cache.org/mail-archive/squid-users/201204/0280.html);
> i experiment problem due to read_timeout not reset correctly in
> tunnel.cc.
>
> Example:
> when i download a file on https site, the download stop on the
> read_timeout value.
> It can be esealy repeat:
>
> read_timeout 30 seconds
> (the defautl is 15 minutes, but it fail too)
>
> wget --no-check-certificate
> https://nzdis.org/projects/projects/perfnet/repository/revisions/4/raw/vendor/Vyatta/Vyatta/vyatta-livecd-vc5.0.2.iso
>
> -O /dev/null
>
> With the following (obvious) patch, i can't repeat the problem:
>
> 01-build64:/home/menil-jp/squid-3.2.0.17# diff src/tunnel.cc
> /tmp/squid-3.2.0.17/src/tunnel.cc
> 321,326d320
> < if (Comm::IsConnOpen(to.conn)) {
> < AsyncCall::Pointer timeoutCall = commCbCall(5, 4, "tunnelTimeout",
> < CommTimeoutCbPtrFun(tunnelTimeout, this));
> < commSetConnTimeout(to.conn, Config.Timeout.read, timeoutCall);
> < }
> <
> 333,336c327,330
> < /* Only close the remote end if we've finished queueing data to it */
> < if (from.len == 0 && Comm::IsConnOpen(to.conn) ) {
> < to.conn->close();
> < }
>
> Please, can anyone confirm this problem?

Sorry, finally found some spare time.
If I'm reading that function right this timeout is occuring on CONNECT
where the traffic flow is all one-way for the duration of the timeout right?

ie, tunnel gets setup. Request bytes sent down it from client->server,
then server sends response data for >N seconds with not one more byte
from client->server. N being the timeout value.

Which would make the timeout correct. Read has not occured on the client
connection for N seconds. But not suitable for two-way CONNECT tunnel.

The proper solution would probably be to bump read timeout when data is
successfully written to the connection
(writeClientDone/writeServerDone). So we did not keep bumping read
timout on a aborted connection.

Any other opinions?

Amos
Received on Fri Apr 20 2012 - 11:03:45 MDT