On Friday 02 Sep 2011 15:34:30 Dennis Nezic wrote: > On Fri, 2 Sep 2011 14:40:22 +0100, Matthew Toseland wrote: > > On Friday 02 Sep 2011 13:20:39 Dennis Nezic wrote: > > > On Fri, 2 Sep 2011 00:23:00 -0400, Dennis Nezic wrote: > > > > On Wed, 31 Aug 2011 15:02:14 -0400, Dennis Nezic wrote: > > > > > On Wed, 31 Aug 2011 09:44:17 -0400, Dennis Nezic wrote: > > > > > > netstat (netstat -pnat | grep java) shows 213 connections to > > > > > > my fproxy at 127.0.0.1:8888, in a "CLOSE_WAIT" state. I only > > > > > > noticed this after I could no longer access fproxy -- > > > > > > probably because of some thread or connection limit. I'm not > > > > > > exactly sure how to reproduce this -- it's not simply a > > > > > > matter of opening a connection to fproxy. > > > > > > > > > > False alarm. I think my freenet wget spider got out of control. > > > > > Apologies. > > > > > > > > Upon further consideration, I think it might actually be a bug. > > > > For one thing, this never happened with earlier pre-1401ish > > > > versions. For another thing, why are there so many sockets open, > > > > when my wget client has long since closed and exited? (it has > > > > been about half an hour now > > > > -- I'll provide updates if they ever do close.) CLOSE_WAIT > > > > apparently means fproxy got the FIN signal from my wget, but > > > > didn't close it's end? > > > > > > > > I'm still not sure exactly how this bizarre behavior (of not > > > > closing sockets) starts -- because if I restart freenet, and do a > > > > simple wget transaction, the socket does get properly closed. > > > > > > All those "HTTP socket handlers" are still open and consuming > > > freenet threads. They were initiated by "wget > > > localhost:8888/USK..." type calls > > > -- and they probably failed because the sites were old. Normal > > > browser access to control localhost:8888 does still close the > > > socket properly. > > > > Well what are they doing then? Still running the requests? This is a > > fundamental problem with fetching stuff over HTTP from Freenet with a > > low timeout - if your tool moves on to add more requests, the old > > requests haven't failed, they are still going. > > They will go on forever? Fproxy will never close them? (Sounds pretty > easy to DDOS that?) And why didn't this happen before?
No, they go on until they complete. There is a limit on the total number of connections handling requests, iirc the default is 100. > > > Having said that it may eventually be possible to detect connection > > closed - in 0.5 there was a hack for it. > > I think tcp's CLOSE_WAIT means fproxy should have already gotten a > "close" signal, no? Surprisingly enough, we are not directly generating TCP packets here...
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
