[Top][All Lists]

[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 19:51:29 +0900

2014-11-03 17:50 GMT+09:00 Christian Grothoff <address@hidden>:
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?

I'm going to add my codes to capture the client IP(or domain) and the request's byte stream.
From the capture, I can tell in more detail.


reply via email to

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