Re: http fproxy ports are not closed

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? 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?

(Why isn't there a time limit, or an hop-limit again?)


> > > 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?
_______________________________________________
Support mailing list
[email protected]
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-request-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ@public.gmane.org?subject=unsubscribe