In general, TCP_NODELAY is not a catastrophe if you use TCP_CORK to allow the accumulation of partial packets in the kernel. The good news is that MHD can use TCP_CORK; the bad news is that Windows doesn't support it :-).
However, this link: http://stackoverflow.com/questions/22117205/is-there-an-equivalent-to-tcp-cork-in-winsock appears to have a some sample code that achieves a similar effect. Now all we need is for somebody to create some patches to use that code on Windows, and for Christian to accept them. (Won't be me - I only care about linux on ARM.) Von: [email protected] [mailto:[email protected]] Im Auftrag von Evgeny Grin Gesendet: Mittwoch, 18. November 2015 14:21 An: libmicrohttpd development and user mailinglist <[email protected]> Betreff: Re: [libmicrohttpd] Why MHD latency is so high on Windows? Hi! libmicrohttpd was ported to use Windows API directly, so PlibC wrapper is not used anymore. According to MSDN docs there is no TCP_FASTOPEN flag on Windows: https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms738596(v=vs.85).aspx It also not present in any header file from VS 2010, 2012, 2013, 2015 and in MinGW-w64 headers. How did you compile MHD? MHD currently has no cmake files. Only autotools files for build on Linux/Unix/Darwin/MinGW/Cygwin and Visual Studio 2013 project for Windows builds. If you just add "#define TCP_FASTOPEN 1" to some header, this misled MHD. On Win32 option TCP_NODELAY has value of 1. So instead of enabling TCP_FASTOPEN, you forced MHD to disable Nagle's algorithm (disabling is not recommend according to MSDN). -- Best Wishes, Evgeny Grin 18.11.2015, 05:44, "silvioprog" <[email protected]<mailto:[email protected]>>: Hello Nils, I can't found any `select.c` file and PlibC entry. :-/ Is this file available in the latest MHD release? But, after your tip, I tried to debug the MHD sources, so I found a build flag called `TCP_FASTOPEN`, and after enable it in my cmake file, rebuilt the DLL and used the `MHD_USE_TCP_FASTOPEN` option in my app, the latency problem as solved, went down to about 3 and 5 ms. However, see this part of the MHD doc: MHD_USE_TCP_FASTOPEN Enable TCP_FASTOPEN on the listen socket. TCP_FASTOPEN is currently supported on Linux >= 3.6. On other systems using this option with cause MHD_start_daemon to fail. But when I enable this flag it works fine on Windows (7, 8 and 10). Is this doc topic outdate or is really wrong to enable this flag on Windows? I just did a cast at the line 4030 of the `daemon.c` file to avoid compiler hints: if (0 != setsockopt (socket_fd, IPPROTO_TCP, TCP_FASTOPEN, (const char *) &daemon->fastopen_queue_size, sizeof (daemon->fastopen_queue_size))) Does anyone have problem using this flag on Windows? If not, it should be interesting to update the *FASTOPEN doc topic. On Mon, Nov 16, 2015 at 5:23 PM, Nils Durner <[email protected]<mailto:[email protected]>> wrote: Hi Silvio, it's been a while since I have looked at the code last, but we used to have an event loop in the Windows implementation of select() (in PlibC) that switches between waiting on sockets and waiting on other handles (specifically, a shutdown signalling pipe handle) every 200ms. Just to see if this the source of the 250ms delay, you could remove the waiting-on-handles part from PlibC select.c. Hope this helps, Nils
