httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject Re: Speeding up mod_proxy_balancer on Windows
Date Mon, 13 Oct 2008 14:38:08 GMT

On 10/13/2008 03:54 PM, Rainer Jung wrote:
> Mladen Turk wrote:
>> Ruediger Pluem wrote:
>>> Not exactly. I would prefer to fix the basic issue with Windows. If
>>> we need to
>>> support milliseconds for connection timeouts seems to be another
>>> story for me.
>>> Can some of the Windows gurus come to the rescue to either confirm
>>> and explain
>>> why it takes that long for connect to return after trying to connect
>>> to a closed
>>> port (on the same machine !!!) or if this must be a local issue on a
>>> specific machine.
>> According to the Microsoft
>> (
>> TcpMaxConnectRetransmissions
>> Key: Tcpip\Parameters
>> Value Type: REG_DWORD - Number
>> Valid Range: 0 - 0xFFFFFFFF
>> Default: 2
>> Description: This parameter determines the number of times that TCP
>> retransmits a connect request (SYN) before aborting the attempt. The
>> retransmission timeout is doubled with each successive retransmission
>> in a particular connect attempt. The initial timeout value is three
>> seconds.
>> So, looks like with default of 2 retransmits there is at least 9
>> second delay.
> I thought the problem was with local connects to a port, to which no
> process listens to. In this case the OS should immediately sending a RST
> (reset) and the client should not resend the SYN. I expect this
> TcpMaxConnectRetransmissions to be used in the case, were the remote
> server doesn't send any answer (neither RST nor SYN/ACK) and the client
> needs to retry the connection establishment after some timeout. That
> shouldn't be the case here, because the local system should always be
> able to send a RST if nothing is listening on the port.
> Except there's a local firewall with packet drop coming into the game
> (or name resolution timeouts, or ...).

Exactly my understanding of the problem. So I see no use in TcpMaxConnectRetransmissions
for this case.



View raw message