|
From: | Taehwan Weon |
Subject: | Re: [libmicrohttpd] a strange thing when send call returns -1 in send_cls() |
Date: | Mon, 3 Nov 2014 19:51:29 +0900 |
On 11/03/2014 05:45 AM, Taehwan Weon wrote:
> Hi,
>
> 2014-11-01 21:19 GMT+09:00 Christian Grothoff <address@hidden
> <mailto: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.
Well, that suggests to me that we don't quite yet understand their
origin ;-).
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?
[Prev in Thread] | Current Thread | [Next in Thread] |