On 11/03/2014 05:45 AM, Taehwan Weon wrote: > Hi, > > 2014-11-01 21:19 GMT+09:00 Christian Grothoff <[email protected] > <mailto:[email protected]>>: > > 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
