Re: [libmicrohttpd] MHD_CONNECTION_OPTION_TIMEOUT seems not to work with MHD_create_response_from_callback

[Christian Grothoff]

Hi Nicolas,

You are right to use the timeout option here. Beyond that, there is
nothing you can do. If the connection of the client is merely bad (but
not closed), TCP will keep retrying and eventually succeed, possibly
preventing the timeout from being effective. That not enough data
arrives in a timely fashion for the Web radio to work is outside of the
scope of HTTP -- IMO your best shot is to increase the buffer size on
the client side in that case.

On the server side, make sure you use EPOLL, in that case even a few
hundred thousand 'open' connections should not be a huge issue for the
server.

My 2 cents

Christian

On 1/31/19 7:58 PM, Nicolas Mora wrote:
> Hello,
> 
> Although it's not easy to reproduce, it seems that using connection
> option MHD_CONNECTION_OPTION_TIMEOUT when streaming data with
> MHD_create_response_from_callback seems not to work, although.
> 
> In my application with MHD underneath where the problem occurs, I
> provide a webradio, which is a http stream with unlimited size.
> 
> The problem I have is when the client uses a bad wifi connection, or
> when the client moves too far from the wifi antenna, then the client
> device detects the connection is wrong, therefore closes it, but on the
> server side, the connection remains open and never closes, leading to
> phantom connections.
> 
> If I use MHD_OPTION_CONNECTION_TIMEOUT in MHD_start_daemon, this
> partially fixes the problem, the server automatically closes the
> connection after the mentionned seconds of total inactivity from the
> client (i.e. the client is not reading the stream anymore but keeps the
> connection open), but it doesn't fix the problem for bad connections.
> 
> I'm attaching a simple example that I used to be able to reproduce the
> problem, but I couldn't find a way to reproduce it with a client
> program. Maybe by using netem but I'm not familiar with this command.
> 
> /Nicolas