Re: [libmicrohttpd] a strange thing when send call returns -1 in send_cls()

[Christian Grothoff]

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?

0x48426C7E.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature