On 10/13/2008 07:46 PM, Rainer Jung wrote: > 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 ...
Correct and my statement didn't imply to set this registry value to 0. I think this is a dangerous road and could lead to other network problems. I wanted to say that the value Mladen mentioned is not really helping as it "normally" should deal with situations where the SYN packets get lost and retransmission is due. But as we all have to learn again Microsoft has their very own interpretation of RFCs: RFC793: "Reset Processing In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields. A reset is valid if its sequence number is in the window. In the SYN-SENT state (a RST received in response to an initial SYN), the RST is acceptable if the ACK field acknowledges the SYN. The receiver of a RST first validates it, then changes state. If the receiver was in the LISTEN state, it ignores it. If the receiver was in SYN-RECEIVED state and had previously been in the LISTEN state, then the receiver returns to the LISTEN state, otherwise the receiver aborts the connection and goes to the CLOSED state. If the receiver was in any other state, it aborts the connection and advises the user and goes to the CLOSED state." In particular the last sentence tells us what to do if a SYN is answered with a RST: "If the receiver [of the RST packet] was in any other state, it aborts the connection and advises the user and goes to the CLOSED state." So if noone finds a registry entry to stop this RFC violating behaviour I see only two options on Windows: 1. Fiddle around with GetTcpTable. 2. Allow connectiontimeout to somehow accept milliseconds. A possible idea for 2. would be to decide by the size of the value whether the value is in seconds or milliseconds: If the value is < 100 it is seconds, if it is > 100 it is milliseconds. I guess there is no sense in values < 100 ms and > 99 s for a *connection* timeout. Regards Rüdiger
