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:, 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:/USK..." type calls
> > > > > > > > -- and they probably failed because the sites were old.
> > > > > > > > Normal browser access to control localhost: 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
