Jess Holle wrote:
I just set this parameter to 0 and the issue went away entirely.
And indeed
http://support.microsoft.com/kb/175523
confirms, that Microsoft has a different way of handling RST than Unixes.
Good catch, Ruediger! Thank you -- and all who helped on this thread!
I think it was Mladen ...
It would appear that Microsoft's documentation slipped a decimal place
somewhere as it would appear there is about 0.3 second delay on the
initial retry and about a 0.6 second on the second -- resulting in about
a 1 second overall delay when other overhead/latency is included.
I don't see a way to reduce this delay and overall concur with Andy that
this parameter should be 0 by all rights. Any thoughts?
--
Jess Holle
Andy Wang wrote:
Ruediger Pluem wrote:
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
Looks like it might be the retry issue:
3963 13.831213 source destination TCP 1230 >
2608 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
4087 14.280717 source destination TCP 2608 >
1230 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
4088 14.280735 source destination TCP 1230 >
2608 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
4238 14.827581 source destination TCP 2608 >
1230 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
4239 14.827603 source destination TCP 1230 >
2608 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
The RSTs occur remotely and Windows retries twice.
1428 4.025656 unixsource destination TCP 57864 > 1230
[SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=0
1429 4.025674 unixsource destination TCP 1230 > 57864
[RST, ACK] Seq=1 Ack=1 Win=0 Len=0
That's the same exchange from an HP-UX source to a linux destination.
I'm assuming that windows pulls the same crap for localhost traffic
even though we can't capture it to prove the case. Oh the joys of
TCP/IP troubleshooting on Windows :)
Andy
