On all Win32 socket layers, when you enable APR_TCP_NODELAY on a listening socket that setting ___________ ("WILL" or "WILL NOT") then be enabled automatically for associated connected sockets.
On all Win32 socket layers, when you enable APR_SO_NOBLOCK on a listening socket that setting _____________ ("WILL" or "WILL NOT") then be enabled automatically for associated connected sockets.
MS doc for accept states that the accept socket "..has the same properties as.." the listen socket. An AcceptEx socket will inherit the properties of the listen socket when setsockopt(SO_UPATE_CONTEXT) is called (which we do).
Setting them to 1 when some Windows socket layers don't work that way it will break the application.
FIOBIO and TCP_NODELAY are part of the Winsock2 API so I see no reason to exclude them.
[snip]
As far as the ap_sock_disable_nagle() calls... That doesn't seem to be implemented in the most clear manner. The calls Apache makes are dependent on APR_TCP_NODELAY_INHERITED and AP_MPM_DISABLE_NAGLE_ACCEPTED_SOCK. I would think that it should work this way:
Agreed the original code is somewhat confusing.
a) when setting up listening socket, unconditionally call ap_sock_disable_nagle()
b) when setting up a newly-connected socket, unconditionally call ap_sock_disable_nagle()
Very little extra overhead will be incurred since the APR setting of APR_TCP_NODELAY_INHERITED will determine whether or not a syscall is used when ap_sock_disable_nagle() calls apr_socket_option_set(APR_TCP_NODELAY) on the newly-connected socket.
mmm, that's not what happens on Windows. The Accept apr_socket_t doesn't pick up APR_TCP_NODELAY from the Listen socket and we incur the extra syscall for every newly connected socket. At the moment I'm not sure how hard it would be to fix that.
