On Sun, 18 Sep 2011 20:23:35 -0400, Dennis Nezic wrote: > On Fri, 9 Sep 2011 09:05:55 -0400, Dennis Nezic wrote: > > On Fri, 9 Sep 2011 13:00:30 +0100, Matthew Toseland wrote: > > > On Wednesday 07 Sep 2011 21:35:44 Dennis Nezic wrote: > > > > On Wed, 7 Sep 2011 17:50:36 +0100, Matthew Toseland wrote: > > > > > 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. > > > > > > > > Well, I just checked -- all the 80 connections that were opened > > > > a week ago are still open and still in CLOSE_WAIT. What does > > > > "until they complete" mean? > > > > > > The thread on Freenet's side will continue until it fetches the > > > data. After that it *should* close the socket. > > > > So, to DOS freenet, I simply need to ask it to fetch old / > > not-fully-existent content? > > > > > > > > > Also, if I kept my wget spider running, it could easily > > > > use 213 or over, like it did when I first reported the problem, > > > > and eventually not let me back into fproxy :s. How does that fit > > > > into the 100 request limit? > > > > > > Fproxy stops accepting more connections after 100 are running. > > > > How does that explain the 213 I originally saw? And why wasn't I > > able to access fproxy, without restarting my node? And why didn't > > this happen to me before with earlier builds -- I've had my spider > > running for months. > > > > > > > > (Why isn't there a time limit, or an hop-limit again?) > > > > > > There is. > > > > ? > > > > > > > > > > > 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... > > > > > > > > Huh? I meant, (I'm guessing), didn't my wget already send a > > > > "FIN" tcp message to fproxy at some point, which is what put > > > > those connections into CLOSE-WAIT? (a la > > > > http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm > > > > ), or am I missing something? > > > > > > As I said before, we are not writing TCP packets directly. We are > > > using a socket API. It is therefore somewhat painful to get > > > notified when the socket is closed, if we are not actually > > > reading from it - which we won't be while handling a request. > > I believe things have been fixed in 1404. (Many threads (~50) do > linger for a while -- I'm not sure if this occurred before as well, > but they do eventually close. With the past few builds they remained > open forever!)
Nevermind. There's still a problem. I haven't been entirely locked out of fproxy, but many of the threads and sockets seem to persist forever -- or at least for far too long. Currently I have over 50 such HTTP sockets, started by my wget. Why don't these things die after the HTL expires, like everything else?? Or, if not by HTL, why not after some sensible time-span, like 10minutes?? And, I still don't quite understand why you can't check the status of a socket, or be notified of wget's FIN signal (It did send one, didn't it, or am I missing something?) -- isn't that fundamental to any tcp connection?? _______________________________________________ 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
