httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject Re: Speeding up mod_proxy_balancer on Windows
Date Mon, 13 Oct 2008 19:12:42 GMT

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
> 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:


"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.



View raw message