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 >> (http://support.microsoft.com/default.aspx/kb/314053) >> >> 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. Regards Rüdiger
