Re: [freenet-support] Freenet 0.7.5 build 1334
On Friday 21 January 2011 19:32:15 Dennis Nezic wrote: On Sat, 22 Jan 2011 08:22:13 +1300, Phillip Hutchings wrote: So, the question then becomes, when the node is clearly receiving more packets than it's supposed to, why is it taking so long (many minutes -- I never actually waited to see if the flood, which consumed my entire connection's 80KiB/sec capacity, would eventually subside) for the rate to stabilize? How much time does the node give it's peers to stabilize their traffic, before it disconnects from them? And does the node accept packets from peers it is not currently connected to? (Ie. say we give our peers 1minute to get their s*** straight, and then disconnect from them, I should see the flood end in 1 minute?) Mostly because development capability is limited by available people and testing capabilities - without a dedicated lab setup it's very hard to test bandwidth limiting, so the only real test is on the network. I'm sure fixing this is on the list somewhere, but we either need to pitch in and code it or wait for someone else to have time. I'm curious, though, as to what the node currently does. (To bring us back to the original question of this thread.) (Yes, I should just look at the code myself.) Surely it does something like I just described above? And surely that's a simple thing? (When you refer to testing, you're probably referring to fine-tunning the above parameters to maximize efficiency ... which is all good ... except even without such testing, I don't see why it should take many minutes for flow to stabilize -- unless our grace-period for overflowing nodes is many minutes long?) What it does is EXACTLY WHAT TCP DOES: If it doesn't get a response within a few round trips, it sends the data again. It also applies congestion control algorithms which are similar to TCP's, but not as accurate as they only (at the moment) apply to big packets and not to small ones. 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] Freenet 0.7.5 build 1334
On Sat, 22 Jan 2011 08:06:28 +0300, Volodya wrote: Please describe the formula through which to calculate the speed of the data that you need to send to your peer, which has 19 other peers (and you have no knowledge about the speed with which they are transmitting). Simple: for i in output-bandwidth for j in list-of-peers if j said it was ok to send stuff over within the last minute send remaining-output-bandwidth, weighted for particular peer end end In other words, the main thing is I have to explicitly say I am expecting stuff, and that there is an explicit timeperiod beyond which other peers should not continue sending me stuff, without my saying it's ok. Similarly, on the receiving end, I will only read packets from peers on my connected-list. (Yes, this is kindof like wasting bandwidth and dropping precious packets ... but remember this is AFTER we give our flooding peer ample time to settle down -- aka. this is bordering on malicious / ddos behavior.) I think that would make the problem much worse: Scenario: You have a spike of CPU useage and your node receives little packets over 1 minute. We can make the threshold longer -- 2, 3 minutes? (My flood went on for at least 5+ minutes.) It calculates how much it could have received more and sends all its peers request to almost entire bandwidth. Obviously it shouldn't do this, then :p. (Ie. obviously asking for a flood will probably deliver a flood. It should never ask for more than it can handle -- even if that means not being fully efficient for a little while.) Then the CPU spike ends and it gets swamped with about 20 times the download limit of packets. It then starts dropping packets because it considers this an attack, hurting not only its ow self, but others in the process. Nope. It will only consider it an attack AFTER it sends these flooding peers notice to back off (or, similarly, if those peers aren't explicitly told it's ok to send stuff). At which point it really is an attack. ___ 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] Freenet 0.7.5 build 1334
On Sat, 22 Jan 2011 10:55:40 -0500, Dennis Nezic wrote: On Sat, 22 Jan 2011 08:06:28 +0300, Volodya wrote: Please describe the formula through which to calculate the speed of the data that you need to send to your peer, which has 19 other peers (and you have no knowledge about the speed with which they are transmitting). Simple: for i in output-bandwidth for j in list-of-peers if j said it was ok to send stuff over within the last minute send remaining-output-bandwidth, weighted for particular peer end end In other words, the main thing is I have to explicitly say I am expecting stuff, and that there is an explicit timeperiod beyond which other peers should not continue sending me stuff, without my saying it's ok. Similarly, on the receiving end, I will only read packets from peers on my connected-list. (Yes, this is kindof like wasting bandwidth and dropping precious packets ... but remember this is AFTER we give our flooding peer ample time to settle down -- aka. this is bordering on malicious / ddos behavior.) I think that would make the problem much worse: Scenario: You have a spike of CPU useage and your node receives little packets over 1 minute. We can make the threshold longer -- 2, 3 minutes? (My flood went on for at least 5+ minutes.) It calculates how much it could have received more and sends all its peers request to almost entire bandwidth. Obviously it shouldn't do this, then :p. (Ie. obviously asking for a flood will probably deliver a flood. It should never ask for more than it can handle -- even if that means not being fully efficient for a little while.) This actually sounds like a very plausible explanation for what was going on. Build 1335 seems a lot more robust for me. I've had it up for about a day, under various traffic conditions, and it hasn't gone insane yet. Quite stable, actually. ___ 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] Freenet 0.7.5 build 1334
On Fri, 21 Jan 2011 05:59:06 +0100, David ‘Bombe’ Roden wrote: On Thursday 20 January 2011 20:32:30 Dennis Nezic wrote: Fix! Please refrain from bossing us around. You are not in a position to do that. Please refrain from mis-interpreting my words. (There is such a thing as 'c-o-n-t-e-x-t', eh?) (Perhaps acquire a sense of humor while you're at it.) The context here would be three messages in which you are ranting about how Freenet does not manage to do a “simple thing” like bandwidth limiting and how it sucks and get worse all the time, In fact, I tried hard to figure out when exactly the limiting was failing, and graciously reported my debugging efforts. (It's occurring only when my connection gets swamped by other traffic.) And though I can assure you that nothing is wrong with my humor, I fail to see anything funny in behaving like you specifically were the person Freenet has been developed for. I assure you, there is something wrong with your humor. And you are completly projecting your own false imaginations of my intentions and behavior on my words -- which, honestly, were meant to be playful and helpful. (It would be interesting to explore the source of these negative projections of yours, but it's off topic on this list.) ___ 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] Freenet 0.7.5 build 1334
On Fri, 21 Jan 2011 05:59:06 +0100, David ‘Bombe’ Roden wrote: a “simple thing” like bandwidth limiting Can someone explain why bandwidth limiting might not be such a simple thing? Volodya tried, with his massive-incoming-packet theory (40KiB :p), but that's not true -- freenet packets are about 1KiB. So, is there not a central class/wrapper in place that feeds the node with at most X KiB / second? Ie. it will only read X UDP packets per second? ___ 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] Freenet 0.7.5 build 1334
On 22/01/2011, at 7:21 AM, Dennis Nezic wrote: On Fri, 21 Jan 2011 05:59:06 +0100, David ‘Bombe’ Roden wrote: a “simple thing” like bandwidth limiting Can someone explain why bandwidth limiting might not be such a simple thing? Volodya tried, with his massive-incoming-packet theory (40KiB :p), but that's not true -- freenet packets are about 1KiB. So, is there not a central class/wrapper in place that feeds the node with at most X KiB / second? Ie. it will only read X UDP packets per second? It doesn't matter if you only read X packets a second, they've still been sent to you so it still used bandwidth. If you don't read UDP all that happens is your OS queues for a while the starts dropping packets. Unlike TCP, UDP doesn't implement speed controls. To control UDP you have to implement your own feedback and control system on the sender. To compound that freenet has to allocate its bandwidth over multiple senders, and it can't just to an even split as not all senders are equal. ___ 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] Freenet 0.7.5 build 1334
On Sat, 22 Jan 2011 07:26:56 +1300, Phillip Hutchings wrote: On 22/01/2011, at 7:21 AM, Dennis Nezic wrote: On Fri, 21 Jan 2011 05:59:06 +0100, David ‘Bombe’ Roden wrote: a “simple thing” like bandwidth limiting Can someone explain why bandwidth limiting might not be such a simple thing? Volodya tried, with his massive-incoming-packet theory (40KiB :p), but that's not true -- freenet packets are about 1KiB. So, is there not a central class/wrapper in place that feeds the node with at most X KiB / second? Ie. it will only read X UDP packets per second? It doesn't matter if you only read X packets a second, they've still been sent to you so it still used bandwidth. If you don't read UDP all that happens is your OS queues for a while the starts dropping packets. Exactly. Why isn't this being done? ___ 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] Freenet 0.7.5 build 1334
On 22/01/2011, at 7:34 AM, Dennis Nezic wrote: On Sat, 22 Jan 2011 07:26:56 +1300, Phillip Hutchings wrote: On 22/01/2011, at 7:21 AM, Dennis Nezic wrote: On Fri, 21 Jan 2011 05:59:06 +0100, David ‘Bombe’ Roden wrote: a “simple thing” like bandwidth limiting Can someone explain why bandwidth limiting might not be such a simple thing? Volodya tried, with his massive-incoming-packet theory (40KiB :p), but that's not true -- freenet packets are about 1KiB. So, is there not a central class/wrapper in place that feeds the node with at most X KiB / second? Ie. it will only read X UDP packets per second? It doesn't matter if you only read X packets a second, they've still been sent to you so it still used bandwidth. If you don't read UDP all that happens is your OS queues for a while the starts dropping packets. Exactly. Why isn't this being done? Why isn't what being done? There's absolutely no point letting the OS drop the packets. They have already been transmitted, they're in the receiver's memory. Dropping the packets is just wasting time and resources, you have to stop them before they're transmitted. ___ 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] Freenet 0.7.5 build 1334
So, the question then becomes, when the node is clearly receiving more packets than it's supposed to, why is it taking so long (many minutes -- I never actually waited to see if the flood, which consumed my entire connection's 80KiB/sec capacity, would eventually subside) for the rate to stabilize? How much time does the node give it's peers to stabilize their traffic, before it disconnects from them? And does the node accept packets from peers it is not currently connected to? (Ie. say we give our peers 1minute to get their s*** straight, and then disconnect from them, I should see the flood end in 1 minute?) Mostly because development capability is limited by available people and testing capabilities - without a dedicated lab setup it's very hard to test bandwidth limiting, so the only real test is on the network. I'm sure fixing this is on the list somewhere, but we either need to pitch in and code it or wait for someone else to have time. ___ 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] Freenet 0.7.5 build 1334
On Sat, 22 Jan 2011 08:22:13 +1300, Phillip Hutchings wrote: So, the question then becomes, when the node is clearly receiving more packets than it's supposed to, why is it taking so long (many minutes -- I never actually waited to see if the flood, which consumed my entire connection's 80KiB/sec capacity, would eventually subside) for the rate to stabilize? How much time does the node give it's peers to stabilize their traffic, before it disconnects from them? And does the node accept packets from peers it is not currently connected to? (Ie. say we give our peers 1minute to get their s*** straight, and then disconnect from them, I should see the flood end in 1 minute?) Mostly because development capability is limited by available people and testing capabilities - without a dedicated lab setup it's very hard to test bandwidth limiting, so the only real test is on the network. I'm sure fixing this is on the list somewhere, but we either need to pitch in and code it or wait for someone else to have time. I'm curious, though, as to what the node currently does. (To bring us back to the original question of this thread.) (Yes, I should just look at the code myself.) Surely it does something like I just described above? And surely that's a simple thing? (When you refer to testing, you're probably referring to fine-tunning the above parameters to maximize efficiency ... which is all good ... except even without such testing, I don't see why it should take many minutes for flow to stabilize -- unless our grace-period for overflowing nodes is many minutes long?) ___ 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] Freenet 0.7.5 build 1334
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/21/2011 10:32 PM, Dennis Nezic wrote: On Sat, 22 Jan 2011 08:22:13 +1300, Phillip Hutchings wrote: So, the question then becomes, when the node is clearly receiving more packets than it's supposed to, why is it taking so long (many minutes -- I never actually waited to see if the flood, which consumed my entire connection's 80KiB/sec capacity, would eventually subside) for the rate to stabilize? How much time does the node give it's peers to stabilize their traffic, before it disconnects from them? And does the node accept packets from peers it is not currently connected to? (Ie. say we give our peers 1minute to get their s*** straight, and then disconnect from them, I should see the flood end in 1 minute?) Mostly because development capability is limited by available people and testing capabilities - without a dedicated lab setup it's very hard to test bandwidth limiting, so the only real test is on the network. I'm sure fixing this is on the list somewhere, but we either need to pitch in and code it or wait for someone else to have time. I'm curious, though, as to what the node currently does. (To bring us back to the original question of this thread.) (Yes, I should just look at the code myself.) Surely it does something like I just described above? And surely that's a simple thing? (When you refer to testing, you're probably referring to fine-tunning the above parameters to maximize efficiency ... which is all good ... except even without such testing, I don't see why it should take many minutes for flow to stabilize -- unless our grace-period for overflowing nodes is many minutes long?) Please describe the formula through which to calculate the speed of the data that you need to send to your peer, which has 19 other peers (and you have no knowledge about the speed with which they are transmitting). - Volodya - -- http://freedom.libsyn.com/ Echo of Freedom, Radical Podcast None of us are free until all of us are free.~ Mihail Bakunin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNOeoUAAoJENW9VI+wmYas5M4IAJtcV0CNJAKaAbAifds9dtTi mVMfwrBmAAs64pYrMZJe6ib2c/JBuh4XATFu1Dj6VMdtwVz0Pp3lxMDqdytQ5eTm P8lbo2kXuWG8MDdRxFKOKnuVv4mNA3GH3EN9Zh9DyON30G63uRL6epm8nypsuo39 m7l7vOmrqmsmBNifjRcaoo/IJcKIv6mHWCulqwgAc//ytWnvOhAlpuAcL1ca+Qo4 ry/VtEH0v1d3opDIBxxgvSj49Z53Q/2iUhpQXcU/0EAXU9IqyxdFBkkMIwtSgWgs ct98GnR2z8TQo/rBV7uc+3Ue4y4JlsNyeEU59hN1yAWJF/CG6D2JDh2DSLK1RUg= =0Oah -END PGP SIGNATURE- ___ 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] Freenet 0.7.5 build 1334
So let me see if I understand. It's a breeze to get my firewall to accept incoming TCP packets from A or from B. But there are special routing permissions necessary to forward packets from A to B or from B to A, and it would be a nightmare to keep routing tables straight? Speaking of firewalls, I have my FN UDP port forwarded both at my router and at my computer firewall. Most the time everything is fine, but once in a while I get a You appear to be behind a NAT warning. I dismiss the warning and I don't see anything for several hours or days. Is this normal? On 01/21/2011 12:19 PM, Phillip Hutchings wrote: On 22/01/2011, at 8:04 AM, Ray Jones wrote: On 01/21/2011 11:59 AM, Phillip Hutchings wrote: On 22/01/2011, at 7:55 AM, Dennis Nezic wrote: On Fri, 21 Jan 2011 11:51:35 -0700, Ray Jones wrote: If I understand correctly UDP has no such thing as flow control. So even though your machine reads only X packets per second, the sending machine is still sending and you're still receiving. If the packets build up too far your machine will drop them, but you've already used the bandwidth to get them there before they were dropped! I agree it's a terrible waste -- but, I say, tough luck. Surely the senders will throttle back when they start seeing some of their packets not being acknowledged. (Like I said, we should avoid this situation as much as possible, but ultimately the user has to be in control. The network, selfish as this might sound, comes second!) NO! We're using UDP - UDP packets have no acknowledgment. TCP would behave like you describe, but UDP senders have no way of knowing that there's a problem. Which brings this non-techies to the obvious (to me) question: So why are we using UDP instead of TCP? Because UDP is easier to get through firewalls. TCP has state, so the firewall has to know you want to receive packets on a port, and it can identify the difference between an outgoing an incoming connection. With a network setup like this A |firewall| C- |firewall| B if A wants to talk to B, B needs to configure their firewall to allow it. They can both talk via C, but C always has to forward packets, if A send a packet to B the firewall would simply block it. However, UDP doesn't have state, a firewall can't identify connections. This means if you have this setup: A || C || B A can get a message to B via C, then at an agreed time both A and B send a packet to each other. Since the firewall can only identify packets, not connections, A's firewall consider's B's packet a response, and vice versa. Then A and B have a communication channel independent of C. This is how the STUN system works. It's advantageous for any system to use UDP as it removes many firewall issues and lowers the support load. There are other reasons to use UDP, such as real time protocols - if you drop a packet in a voice conversation a delay is more harmful than an audio glitch. ___ 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 ___ 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] Freenet 0.7.5 build 1334
On Fri, 21 Jan 2011 23:18:33 +0300, Volodya wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/21/2011 10:32 PM, Dennis Nezic wrote: On Sat, 22 Jan 2011 08:22:13 +1300, Phillip Hutchings wrote: So, the question then becomes, when the node is clearly receiving more packets than it's supposed to, why is it taking so long (many minutes -- I never actually waited to see if the flood, which consumed my entire connection's 80KiB/sec capacity, would eventually subside) for the rate to stabilize? How much time does the node give it's peers to stabilize their traffic, before it disconnects from them? And does the node accept packets from peers it is not currently connected to? (Ie. say we give our peers 1minute to get their s*** straight, and then disconnect from them, I should see the flood end in 1 minute?) Mostly because development capability is limited by available people and testing capabilities - without a dedicated lab setup it's very hard to test bandwidth limiting, so the only real test is on the network. I'm sure fixing this is on the list somewhere, but we either need to pitch in and code it or wait for someone else to have time. I'm curious, though, as to what the node currently does. (To bring us back to the original question of this thread.) (Yes, I should just look at the code myself.) Surely it does something like I just described above? And surely that's a simple thing? (When you refer to testing, you're probably referring to fine-tunning the above parameters to maximize efficiency ... which is all good ... except even without such testing, I don't see why it should take many minutes for flow to stabilize -- unless our grace-period for overflowing nodes is many minutes long?) Please describe the formula through which to calculate the speed of the data that you need to send to your peer, which has 19 other peers (and you have no knowledge about the speed with which they are transmitting). Simple: for i in output-bandwidth for j in list-of-peers if j said it was ok to send stuff over within the last minute send remaining-output-bandwidth, weighted for particular peer end end In other words, the main thing is I have to explicitly say I am expecting stuff, and that there is an explicit timeperiod beyond which other peers should not continue sending me stuff, without my saying it's ok. Similarly, on the receiving end, I will only read packets from peers on my connected-list. (Yes, this is kindof like wasting bandwidth and dropping precious packets ... but remember this is AFTER we give our flooding peer ample time to settle down -- aka. this is bordering on malicious / ddos behavior.) ___ 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] Freenet 0.7.5 build 1334
On 01/21/2011 02:34 PM, Dennis Nezic wrote: On Fri, 21 Jan 2011 23:18:33 +0300, Volodya wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/21/2011 10:32 PM, Dennis Nezic wrote: On Sat, 22 Jan 2011 08:22:13 +1300, Phillip Hutchings wrote: So, the question then becomes, when the node is clearly receiving more packets than it's supposed to, why is it taking so long (many minutes -- I never actually waited to see if the flood, which consumed my entire connection's 80KiB/sec capacity, would eventually subside) for the rate to stabilize? How much time does the node give it's peers to stabilize their traffic, before it disconnects from them? And does the node accept packets from peers it is not currently connected to? (Ie. say we give our peers 1minute to get their s*** straight, and then disconnect from them, I should see the flood end in 1 minute?) Mostly because development capability is limited by available people and testing capabilities - without a dedicated lab setup it's very hard to test bandwidth limiting, so the only real test is on the network. I'm sure fixing this is on the list somewhere, but we either need to pitch in and code it or wait for someone else to have time. I'm curious, though, as to what the node currently does. (To bring us back to the original question of this thread.) (Yes, I should just look at the code myself.) Surely it does something like I just described above? And surely that's a simple thing? (When you refer to testing, you're probably referring to fine-tunning the above parameters to maximize efficiency ... which is all good ... except even without such testing, I don't see why it should take many minutes for flow to stabilize -- unless our grace-period for overflowing nodes is many minutes long?) Please describe the formula through which to calculate the speed of the data that you need to send to your peer, which has 19 other peers (and you have no knowledge about the speed with which they are transmitting). Simple: for i in output-bandwidth for j in list-of-peers ifj said it was ok to send stuff over within the last minute sendremaining-output-bandwidth, weighted for particular peer end end I played around with some Basic programming (back before VB). I even got C++ to say 'Hello, World' to me a time or two. So don't think I'm speaking as a pro when I say, I be guessing it ain't that simple, bro. ___ 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] Freenet 0.7.5 build 1334
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please describe the formula through which to calculate the speed of the data that you need to send to your peer, which has 19 other peers (and you have no knowledge about the speed with which they are transmitting). Simple: for i in output-bandwidth for j in list-of-peers if j said it was ok to send stuff over within the last minute send remaining-output-bandwidth, weighted for particular peer end end In other words, the main thing is I have to explicitly say I am expecting stuff, and that there is an explicit timeperiod beyond which other peers should not continue sending me stuff, without my saying it's ok. Similarly, on the receiving end, I will only read packets from peers on my connected-list. (Yes, this is kindof like wasting bandwidth and dropping precious packets ... but remember this is AFTER we give our flooding peer ample time to settle down -- aka. this is bordering on malicious / ddos behavior.) I think that would make the problem much worse: Scenario: You have a spike of CPU useage and your node receives little packets over 1 minute. It calculates how much it could have received more and sends all its peers request to almost entire bandwidth. Then the CPU spike ends and it gets swamped with about 20 times the download limit of packets. It then starts dropping packets because it considers this an attack, hurting not only its ow self, but others in the process. - Volodya - -- http://freedom.libsyn.com/ Echo of Freedom, Radical Podcast None of us are free until all of us are free.~ Mihail Bakunin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNOmXTAAoJENW9VI+wmYasxOoH/04L3eIdl5+CATH9Bti08qef 2wEdQcqCVeBJ9Mc8aubMBcvq/GuqsELWB5XuzQoyQ0XS9RLp2J+iUGiAtkOvegER FKIQtp2jCPLArQ03voIN0mzTF6NH955th6y5BdCG22Zw4MCNNO/ykHC+fFXKoFPC LsCY0nAIZ9EH2c84KIIDb3nYbtljmgNvBeKcYr5KUNLpwehE2meUfBVdYNS0e4fL O2KY3KC1tpRNP9R2x5eI+1DsdMiUhhE/Dpq6ilnvdi8R7JooN/eefW3WqhqFOgXS XuG0cZEn5IHr7fqyFpgHmcTBBl2ehGVk3GwcWNgCCFJmwxWbyEBtX73T97+oL9o= =Hxhy -END PGP SIGNATURE- ___ 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
[freenet-support] Freenet 0.7.5 build 1334
Freenet 0.7.5 build 1334 is now available. It may fix some recent problems (particularly bwlimitDelayTime problems). Please upgrade! 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] Freenet 0.7.5 build 1334
On Thu, 20 Jan 2011 12:48:56 +, Matthew Toseland wrote: Freenet 0.7.5 build 1334 is now available. It may fix some recent problems (particularly bwlimitDelayTime problems). Please upgrade! Same problem as I originally reported a while ago. Input bandwidth limit is trivially broken. So, like I mentioned before, but experience is making clearer, the limit is more or less obeyed, UNTIL my isp-connection gets swamped (by other activities). I would handwave that because freenet is competing for the small pipe, which would cause packets to take longer to arrive / not arrive at all, it becomes heuristically more aggressive, somehow, and (arguably more seriously) even when the pipe clears up a bit, remains aggressive. Fix! ___ 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] Freenet 0.7.5 build 1334
On Thursday 20 January 2011 18:24:15 Dennis Nezic wrote: Fix! Please refrain from bossing us around. You are not in a position to do that. 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] Freenet 0.7.5 build 1334
On Thu, 20 Jan 2011 20:28:24 +0100, David ‘Bombe’ Roden wrote: On Thursday 20 January 2011 18:24:15 Dennis Nezic wrote: Fix! Please refrain from bossing us around. You are not in a position to do that. Please refrain from mis-interpreting my words. (There is such a thing as 'c-o-n-t-e-x-t', eh?) (Perhaps acquire a sense of humor while you're at it.) ___ 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] Freenet 0.7.5 build 1334
On Thursday 20 January 2011 20:32:30 Dennis Nezic wrote: Fix! Please refrain from bossing us around. You are not in a position to do that. Please refrain from mis-interpreting my words. (There is such a thing as 'c-o-n-t-e-x-t', eh?) (Perhaps acquire a sense of humor while you're at it.) The context here would be three messages in which you are ranting about how Freenet does not manage to do a “simple thing” like bandwidth limiting and how it sucks and get worse all the time, ending all messages with the command “Fix!”. And though I can assure you that nothing is wrong with my humor, I fail to see anything funny in behaving like you specifically were the person Freenet has been developed for. 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
