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 ...).
Regards,
Rainer
