libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] MHD_CONNECTION_OPTION_TIMEOUT seems not to work with


From: Christian Grothoff
Subject: Re: [libmicrohttpd] MHD_CONNECTION_OPTION_TIMEOUT seems not to work with MHD_create_response_from_callback
Date: Sat, 2 Feb 2019 11:29:59 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]