Hi!
(ok not really a Re: since i dont have the original message, but i
copy-pasted somewhat from archives to get some context, hope noone
minds :) http://www.nabble.com/relayd:-does-timeout-directive-limits-time-for-SSL-handshake--td19698613.html)
Just want to bring this back up, since I just had this problem as
well. And I had to bring it up more than 2s (running at 15s now) due
to slow (mobile among others) clients.
Didn't see anything in CVS, any chances of changes?
A SSL handshake could very well take a few seconds on slow clients (as
shown), but if my service is taking 2-3s to respond, something is
wrong and I'd want to throw it out of rotation earlier than that.
A separate connection_setup_timeout directive or something might be on
order?
Btw, would there be any problems running CURRENT relayd/relayctl on a
4.4 kernel/system?
Thanks
Johan
On Monday, September 29, 2008 - 5:49 pm, Reyk Floeter wrote:
> Hi!
>
> On Sat, Sep 27, 2008 at 02:01:09AM +0200, Till Neudecker wrote:
> > I have a pretty normal loadbalancing setup (2 relayd-
loadbalancer, 2 backend
> > hosts). The loadbalancer accepts ssl-encrypted sessions and
forwards them
> > unencrypted to the backend-hosts.
> > Because all the hosts are on the same LAN
> > I set the global timeout-directive to 200ms.
>
> 200ms is a really brave timeout even for host checks in a LAN. I
> almost always increase it in my configurations, but I think pyr@
liked
> the really short timeout ;). But we should probably bump up the
> default to prevent failures in common configurations.
> When now connecting from a slow internet-connection to my service,
I often
> receive a "SSL accept timeout". After changing the global timeout
to 2000ms
> the problem disappears. The man-pages only says timeout limits the
time for
> the checks of the backend-hosts but nothing about the SSL-
handshake from
> clients
> > Can someone agree or disgree to my guess that timeout also limits
the time
> > for the SSL-handshake?
> >
>
> Yes, this is right. The global timeout is a "connection timeout"
> which is used by the health checks but also by the initial
> connect/accept of the relays in TCP and SSL mode. This means that
> this timeout will be used for the time to establish the stateful TCP
> or SSL connection. The established connection will switch to the
> per-relay "session timeout" which defaults to 600s (10min) for idle
> TCP/SSL sessions.
>
> Thanks for your hint, I will think about adding another timeout and/
or
> improving the manpage here.
>
> Reyk
