[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
Re: [libmicrohttpd] a strange thing when send call returns -1 in send_cls()
Mon, 03 Nov 2014 09:50:04 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.0
On 11/03/2014 05:45 AM, Taehwan Weon wrote:
> 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
> > 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.
Well, that suggests to me that we don't quite yet understand their
So is it the same connection over and over again that creates the
EAGAINs, at a rapid rate (each time the event loop goes around), or is
it different connections and rarely the same one repeatedly?
Description: OpenPGP digital signature