2014-11-03 17:50 GMT+09:00 Christian Grothoff <[email protected]>: > 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? >
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. ------- weon
