Re: [Ziproxy-devel] confirming ConnTimeout is functioning okay?
Brought to you by:
dmcabrita
|
From: Daniel M. C. <da...@gm...> - 2011-02-09 12:29:08
|
I'm transferring this discussion to ziproxy-users. Ziproxy should not timeout (by itself) before ConnTimeout elapses, but a remote HTTP server may do that and close its side of the connection and force Ziproxy to abort. It would be interesting to see some related logs. Is there a pattern for this problem you're aware of? Em Tuesday 08 February 2011, Andrew Leahy escreveu: > Hi - I'm getting a sense that ConnTimeout might be setting a > hard-upper limit on the amount of time a connection can take, > regardless of whether there is traffic on that connection or not. > Rather than "ConnTimeout" seconds since idle/stall. > > The description ConnTimeout in the ziproxy.conf is.. > > ## If processing of request exceeds specified time in seconds, > ## or connection is idle beyond that time (stalled) it will abort. > ## This avoids processes staying forever (or for a very long time) > ## in case of a stalled connection or software bug. > ## This will NOT necessarily abort the streaming of very big files, > ## it will ONLY if the connection stalls or there's a software bug. > > On my system it seems to have problems determing if the connection is > idle/stalled > > I use a 3G modem which sometimes runs down to GPRS (60kbps) type > speeds, with a pair of ziproxy's (one at each end). > > What I've noticed in the local ziproxy logs is repeated serial > requests all with time/duration at around ConnTimeout limit. > > It I tcpdump the outbound eth interface I can see traffic coming in > the interface. But then I can see a connection reset, and the download > appears to start again. This matches with a "PZ" in the ziproxy.log, > and repeated attempts to download some content. > > I can send some logs of this. But I just wanted to raise it in case it > was something other people had experienced? > > If you're on a fast link and not watching the logs you probably wouldn't > notice. On slow links the browser may eventually get's the file (after > repeated attempts) or a "blank" page with no content. > > With chained ziproxies is the ConnTimeout applied to both the upstream > download (typically fast), as well as the downstream 'send' to the > other ziproxy (typically slow link). > > > Cheers, > Andrew |