Hello Wilfried, Here are some other infos that may help/explain
TcpMaxDataRetransmissions Key: Tcpip\Parameters Value Type: REG_DWORD-Number Valid Range: 0-0xFFFFFFFF Default: 5 Description: This parameter controls the number of times TCP will retransmit an individual data segment (not connection request segments) before aborting the connection. The retransmission time-out is doubled with each successive retransmission on a connection. It is reset when responses resume. The base time-out value is dynamically determined by the measured round-trip time on the connection. KeepAliveInterval Key: Tcpip\Parameters Value Type: REG_DWORD-Time in milliseconds Valid Range: 1-0xFFFFFFFF Default: 1000 (one second) Description: This parameter determines the interval between keep-alive retransmissions until a response is received. Once a response is received, the delay until the next keep-alive transmission is again controlled by the value of KeepAliveTime. The connection will be aborted after the number of retransmissions specified by TcpMaxDataRetransmissions have gone unanswered. KeepAliveTime Key: Tcpip\Parameters Value Type: REG_DWORD-Time in milliseconds Valid Range: 1-0xFFFFFFFF Default: 7,200,000 (two hours) Description: The parameter controls how often TCP attempts to verify that an idle connection is still intact by sending a keep-alive packet. If the remote system is still reachable and functioning, it will acknowledge the keep-alive transmission. Keep-alive packets are not sent by default. This feature may be enabled on a connection by an application. Dead Gateway Detection Dead gateway detection is used to allow TCP to detect failure of the default gateway and to make an adjustment to the IP routing table to use another default gateway. The Microsoft TCP/IP stack uses the TRIGGERED RESELECTION method described in RFC 816, with some slight modifications based upon customer experiences and feedback. When any TCP connection that is routed through the default gateway has attempted to send a TCP packet to the destination a number of times equal to one-half of the registry value TcpMaxDataRetransmissions, without receiving a response, the algorithm changes the Route Cache Entry (RCE) for that one remote IP address to use the next default gateway in the list. When 25 percent of the TCP connections have moved to the next default gateway, the algorithm advises IP to change the computer's default gateway to the one that the connections are now using. For example, assume that there are currently TCP connections to 11 different IP addresses that are being routed through the default gateway. Now assume that the default gateway fails, that there is a second default gateway configured, and that the value for TcpMaxDataRetransmissions is at the default of 5. When the first TCP connection tries to send data, it will not receive any acknowledgments. After the third retransmission, the RCE for that remote IP address will be switched to use the next default gateway in the list. At this point, any TCP connections to that one remote IP address will have switched over, but the remaining connections will still try to use the original default gateway. When the second TCP connection tries to send data, the same thing will happen. Now, two of the 11 RCEs will point to the new gateway. When the third TCP connection tries to send data, after the third retransmission, three of 11 RCEs will have been switched to the second default gateway. Because, at this point, over 25 percent of the RCEs have been moved, the default gateway for the whole computer will be moved to the new one. At this point, that default gateway remains the primary one for the computer until it experiences problems (causing the dead gateway algorithm to try the next one in the list again) or until the computer is restarted. When the search reaches the last default gateway, it returns to the beginning of the list. TCP Retransmission Behavior TCP starts a retransmission timer when each outbound segment is handed down to IP. If no acknowledgment has been received for the data in a given segment before the timer expires, then the segment is retransmitted. For new connection requests, the retransmission timer is initialized to 3 seconds, and the request (SYN) is resent up to TcpMaxConnectRetransmissions times (the default for Windows NT 5.0 is 2 times, down from 3 in Windows NT 4.0). On existing connections, the number of retransmissions is controlled by the TcpMaxDataRetransmissions registry parameter (5 by default). The retransmission time-out is adjusted "on the fly" to match the characteristics of the connection using Smoothed Round Trip Time (SRTT) calculations as described in RFC 793. The timer for a given segment is doubled after each retransmission of that segment. Using this algorithm, TCP tunes itself to the "normal" delay of a connection. TCP connections over high-delay links will take much longer to time out than those over low-delay links. The following trace clip shows the retransmission algorithm for two hosts connected over Ethernet on the same subnet. An FTP file transfer was in progress when the receiving host was disconnected from the network. Because the SRTT for this connection was very small, the first retransmission was sent after about one-half second. The timer was then doubled for each of the retransmissions that followed. After the fifth retransmission, the timer was once again doubled, and if no acknowledgment was received before it expired, the connection was aborted. delta source ip dest ip pro flags description 0.000 10.57.10.32 10.57.9.138 TCP .A.., len: 1460, seq: 8043781, ack: 8153124, win: 8760 0.521 10.57.10.32 10.57.9.138 TCP .A.., len: 1460, seq: 8043781, ack: 8153124, win: 8760 1.001 10.57.10.32 10.57.9.138 TCP .A.., len: 1460, seq: 8043781, ack: 8153124, win: 8760 2.003 10.57.10.32 10.57.9.138 TCP .A.., len: 1460, seq: 8043781, ack: 8153124, win: 8760 4.007 10.57.10.32 10.57.9.138 TCP .A.., len: 1460, seq: 8043781, ack: 8153124, win: 8760 8.130 10.57.10.32 10.57.9.138 TCP .A.., len: 1460, seq: 8043781, ack: 8153124, win: 8760 There are some circumstances under which TCP will retransmit data prior to the retransmission timer expiring. The most common of these occurs due to a feature known as fast retransmit. When a receiver that supports fast retransmit receives data with a sequence number beyond the current expected one, then it is likely that some data was dropped. To help make the sender aware of this event, the receiver immediately sends an ACK, with the ACK number set to the sequence number that it was expecting. It will continue to do this for each additional TCP segment that arrives containing data subsequent to the missing data in the incoming stream. When the sender starts to receive a stream of ACKs that are acknowledging the same sequence number, and that sequence number is earlier than the current sequence number being sent, it can infer that a segment (or more) must have been dropped. Senders that support the fast retransmit algorithm will immediately resend the segment that the receiver is expecting to fill in the gap in the data, without waiting for the retransmission timer to expire for that segment. This optimization greatly improves performance in a lossy network environment. By default, Windows NT 5.0 resends a segment if it receives three ACKs for the same sequence number, and that sequence number lags the current one. This is controllable with the TcpMaxDupAcks registry parameter. See also the section in this paper on Selective Acknowledgements. TCP Keep-alive Messages A TCP keep-alive packet is simply an ACK with the sequence number set to one less than the current sequence number for the connection. A host receiving one of these ACKs will respond with an ACK for the current sequence number. Keep-alives can be used to verify that the computer at the remote end of a connection is still available. TCP keep-alives can be sent once every KeepAliveTime (defaults to 7,200,000 milliseconds or two hours), if no other data or higher level keep-alives have been carried over the TCP connection. If there is no response to a keep-alive, it is repeated once every KeepAliveInterval seconds. KeepAliveInterval defaults to 1 second. NetBT connections, such as those used by many Microsoft networking components, send NetBIOS keep-alives more frequently, so normally no TCP keep-alives will be sent on a NetBIOS connection. TCP keep-alives are disabled by default, but Windows Sockets applications can use the SetSockOpt function to enable them. Regards. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
