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!) _______________________________________________ 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
