"Lin Jen-Shin (godfat)" <god...@godfat.org> wrote: > On Sat, May 9, 2015 at 9:03 AM, Eric Wong <e...@80x24.org> wrote: > > Below, I'm choosing to both leave the socket open and keep the worker > > running to slow down a potentially malicious client if this happens and > > to hopefully prevent an evil client from taking others down with it. > > I am curious how this could slow down a malicious client? Because this > might somehow confuse them that the worker is still working?
Right, it might not know if the app server is throttling responses or if there's packet loss on the network. Other than the small amount of memory used for the socket, it won't use other system resources once the error is logged. > A backtrace for knowing what's happening I think is quite enough for me now. > Still curious though, could this worker do anything else if this happened? > I am guessing that if the application no longer does anything, then this > worker > would not do anything. Or the socket might timeout eventually? It depends on the application structure. Often apps have very different code paths for different endpoints so some endpoint being fatally broken may not affect others. A simple endpoint (e.g. static files) could function at 100% and serve other clients without any problems. Eventually the socket will timeout if the client_expire_threshold is reached, otherwise it's fairly harmless to keep the socket around (aside from memory overhead).
