Re: [freenet-support] http fproxy ports are not closed
On Thu, 22 Sep 2011 07:09:58 +0200, David ‘Bombe’ Roden wrote: On WOCHENTAG, tT. MONAT 23:21:53 Dennis Nezic wrote: 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?? As Matthew already told you, finding out whether a socket has been disconnected can only be done by reading from or writing to the socket. We don’t do either until the request is finished. There’s your answer and it won’t change if you ask more often. What determines whether a request is finished? When I browse freesites normally, those requests expire gracefully. Also, this bug (something fishy is definitely going on) is stranger than I described, because I'm not exactly sure what creates those abandoned open threads/sockets -- it's not simply a wget request, nor one that ends in a failure (500 Internal Error) -- those all end well. :S. A thread dump says they (all 50+ of them) are locked in FProxyFetchWaiter: HTTP socket handler@15723301 (1994) daemon prio=10 tid=0x08a5f800 nid=0x76b6 in Object.wait () [0xb1ffe000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait (Native Method) at java.lang.Object.wait (Object.java:485) at freenet.clients.http.FProxyFetchWaiter.getResult (FProxyFetchWaiter.java:28) - locked 0x6dc52720 (a freenet.clients.http.FProxyFetchWaiter) at freenet.clients.http.FProxyToadlet.innerHandleMethodGET (FProxyToadlet.java:663) at freenet.clients.http.FProxyToadlet.handleMethodGET (FProxyToadlet.java:459) at sun.reflect.GeneratedMethodAccessor15.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:597) at freenet.clients.http.ToadletContextImpl.handle (ToadletContextImpl.java:550) at freenet.clients.http.SimpleToadletServer$SocketHandler.run (SimpleToadletServer.java:989) at freenet.support.PooledExecutor$MyThread.realRun (PooledExecutor.java:233) at freenet.support.io.NativeThread.run (NativeThread.java:130) ___ 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
Re: [freenet-support] http fproxy ports are not closed
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 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!)
Re: [freenet-support] http fproxy ports are not closed
On WOCHENTAG, tT. MONAT 23:21:53 Dennis Nezic wrote: 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?? As Matthew already told you, finding out whether a socket has been disconnected can only be done by reading from or writing to the socket. We don’t do either until the request is finished. There’s your answer and it won’t change if you ask more often. David 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
Re: [freenet-support] http fproxy ports are not closed
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 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
Re: [freenet-support] http fproxy ports are not closed
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. 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. (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. 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
Re: [freenet-support] http fproxy ports are not closed
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 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. ___ 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
Re: [freenet-support] http fproxy ports are not closed
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. 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
Re: [freenet-support] 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:, 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? 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 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
Re: [freenet-support] http fproxy ports are not closed
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. ___ 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
Re: [freenet-support] http fproxy ports are not closed
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. Having said that it may eventually be possible to detect connection closed - in 0.5 there was a hack for it. 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
Re: [freenet-support] http fproxy ports are not closed
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? 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? ___ 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
Re: [freenet-support] http fproxy ports are not closed
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. ___ 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
Re: [freenet-support] http fproxy ports are not closed
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. ___ 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
