Re: [libmicrohttpd] Why MHD latency is so high on Windows?

[Evgeny Grin]

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" <address@hidden>:

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 <address@hidden> 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