Re: clitimeout and srvtimeout for POP & SMTP question

Hi Rob,

On Wed, Dec 05, 2007 at 11:21:38PM +0100, Willy Tarreau wrote:
> Hi Rob,
>
> On Wed, Dec 05, 2007 at 10:34:30AM -0500, Rob wrote:
> > Hello all, hope everyone is doing fine.....
> >
> > If i do not give any or do not have the srv & clitimeout options in the
> > config, does haproxy default to anything, or there is simply no time
> > outs at all?
>
> You will get an infinite timeout with a warning at startup.
>
> > As a setting of 750000 still gives errors to dialup clients that have
> > large emails for sending or receiving...
>
> Hmmm. I have an idea on the subject, I must check the code. Since haproxy
> intially was only HTTP-oriented, communications were mostly half-duplex
> with known states where the client was not expected to talk while retrieving
> data for instance. However, in TCP mode, communications are often full-duplex
> (eg: SSH or remote displays), so data which passes in each direction freshens
> the expiration timers. But it is fairly normal to expect the client to be able
> to talk after retrieving 30 minutes of data, so both the read and write
> timeouts should be updated when it speaks. I have to check the code because
> I must admit I'm not sure what is done in this specific case.

I've just checked and I can confirm that the read timeout is updated as well as the write timeout :

stream_sock.c:

        if (b->flags & BF_PARTIAL_WRITE) {
                if (tv_add_ifset(&b->wex, &now, &b->wto)) {
                        /* FIXME: to prevent the client from expiring read timeouts during writes,
                         * we refresh it. A solution would be to merge read+write timeouts into a
                         * unique one, although that needs some study particularly on full-duplex
                         * TCP connections. */
                        if (!(b->flags & BF_SHUTR_STATUS))
                                b->rex = b->wex;
                        goto out_wakeup;
                }
        out_eternity:
                tv_eternity(&b->wex);
        }

What version are you using ? 1.2 also has this trick, but it appears to me that if the timeout was infinite on the read socket (eg: due to a shutdown from the other end), then it could be rearmed due to the lack of check of BF_SHUTR_STATUS, causing the session to prematurely end in the middle of a transfer (at least as I analyze it).

In 1.3, this has been fixed since 2007/04/15 (1.3.9).

Regards,
Willy Received on 2007/12/10 19:04