libmicrohttpd
[Top][All Lists]
Advanced

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

Re: [libmicrohttpd] a strange thing when send call returns -1 in send_cl


From: Taehwan Weon
Subject: Re: [libmicrohttpd] a strange thing when send call returns -1 in send_cls()
Date: Mon, 3 Nov 2014 13:45:18 +0900

Hi,

2014-11-01 21:19 GMT+09:00 Christian Grothoff <address@hidden>:
On 11/01/2014 07:04 AM, Taehwan Weon wrote:
> I am testing reliability of my caching proxy based on MHD, which opens 80
> port.
> It means anyone can use it to reach any web server.
> Most of incoming requests seems either incomplete or odd.

Most!? Or do you mean "some"?


Sorry, 'some' is correct.
 
> (I found a client opened a HTTP session and sent only a part of headers,
> but no body data.)
>
> 1. To avoid spurious EAGAIN, I add a counter into MHD_Connection, which
> counts continuous errors. If a threshold reaches, ECONNRESET set. EAGAIN
> seems caused by buffer full on client side. I am not sure what is the
> client's purpose.

That's odd, TCP flow control should take care of that and simply not
present the (busy) connection as writable to the server userspace.
Still, if you are right, this suggests an easy way to
test for that condition -- by implementing a client that doens't
read the response and by sending a 'large' reply that won't fit
into the buffers. Have you tried this to reproduce the issue?

I tested with my simple socket program where I changed the SO_RCVBUF to a small vaue). But I could not find any spurious EAGAINs from my test.
But my proxy is still reporting the spurious EAGAINs. 


 
> 2, To avoid infinite wait to receive remaining part of a client's data, I
> need timeout mechanism.
>     I am not sure where is the best location to handle timeout. MHD or my
> caching proxy would be the candidate.

I would say that virtually every MHD production site should set 'some'
timeout for MHD.  Note that you can set a custom timeout for a
particular connection, i.e. when you know that a specific connection
will take way longer than usual.

Ok. Thanks. Will be tried. :-)

 
-------
weon

reply via email to

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