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 Saturday 22 January 2011 16:48:08 Dennis Nezic wrote: > 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 > > > minute> send > > > 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. As has been pointed out, scheduling incoming transfers explicitly would be extremely difficult to implement and get right with good performance, and right now 99% of nodes are limited on UPLOAD bandwidth, not download. 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 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 > > minute> send > > 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 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 > > send > 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
-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 > send > 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
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 if send 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
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 send 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
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
-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
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
> 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 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
Re: [freenet-support] Freenet 0.7.5 build 1334
On Fri, 21 Jan 2011 14:08:35 -0500, Dennis Nezic wrote: > On Fri, 21 Jan 2011 14:05:09 -0500, Dennis Nezic wrote: > > On Sat, 22 Jan 2011 07:59:32 +1300, 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. > > > > > > Freenet itself acknowledges packets, > > > > That's what I was referring to. > > > > > and that's part of the rate limiting, which obviously has some > > > bugs. Not reading the packets will work for a while, but when > > > packets are read and ack'd the senders will burst again, not > > > knowing there's a limit. > > > > Sure they will know there is a limit -- they will know how long it > > took for the packets to get acked, and how many were dropped. It's > > not perfect, but I'm sure they will know enough to pull back when > > necessary. > > > > > The only solution is to fix the limiter bugs, which is tough > > > for a project with so few developers. > > > > Fixing that is definitely essential, although either way I think the > > user's limit has to be paramount. (Perhaps there are other ways to > > avoid dropping, like having the UDP packets queued into Freenet's > > memory, but not used more than XKiB/second -- so the long ack-ing > > works for a bit longer, rather than dropping the packets, which is > > worse.) > > Bah. Ok, I see your point. The damage is already done when we are > flooded with traffic. There is no point hurting the user more by > dumping those already-arrived packets :b. 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?) ___ 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 14:05:09 -0500, Dennis Nezic wrote: > On Sat, 22 Jan 2011 07:59:32 +1300, 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. > > > > Freenet itself acknowledges packets, > > That's what I was referring to. > > > and that's part of the rate limiting, which obviously has some bugs. > > Not reading the packets will work for a while, but when packets are > > read and ack'd the senders will burst again, not knowing there's a > > limit. > > Sure they will know there is a limit -- they will know how long it > took for the packets to get acked, and how many were dropped. It's not > perfect, but I'm sure they will know enough to pull back when > necessary. > > > The only solution is to fix the limiter bugs, which is tough > > for a project with so few developers. > > Fixing that is definitely essential, although either way I think the > user's limit has to be paramount. (Perhaps there are other ways to > avoid dropping, like having the UDP packets queued into Freenet's > memory, but not used more than XKiB/second -- so the long ack-ing > works for a bit longer, rather than dropping the packets, which is > worse.) Bah. Ok, I see your point. The damage is already done when we are flooded with traffic. There is no point hurting the user more by dumping those already-arrived packets :b. ___ 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:59:32 +1300, 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. > > Freenet itself acknowledges packets, That's what I was referring to. > and that's part of the rate limiting, which obviously has some bugs. > Not reading the packets will work for a while, but when packets are > read and ack'd the senders will burst again, not knowing there's a > limit. Sure they will know there is a limit -- they will know how long it took for the packets to get acked, and how many were dropped. It's not perfect, but I'm sure they will know enough to pull back when necessary. > The only solution is to fix the limiter bugs, which is tough > for a project with so few developers. Fixing that is definitely essential, although either way I think the user's limit has to be paramount. (Perhaps there are other ways to avoid dropping, like having the UDP packets queued into Freenet's memory, but not used more than XKiB/second -- so the long ack-ing works for a bit longer, rather than dropping the packets, which is worse.) ___ 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 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? ___ 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:55:34 +1300, Phillip Hutchings wrote: > > On 22/01/2011, at 7:51 AM, Dennis Nezic wrote: > > > On Sat, 22 Jan 2011 07:37:54 +1300, Phillip Hutchings wrote: > >> > >> 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. > > > > 1) It puts the user in control. If I specify XKiB/sec, I > > expect/demand XKiB/sec usage :b. > > > > 2) The packets will only be dropped if there is excessive load, > > which obviously should be avoided by all the custom overhead. > > OS-packet dropping would only serve as a last resort -- ie. if > > freenet's traffic-coordination messes up (as it currently > > does! :p), or if we are connected to malicious nodes. > > > > There are two options here -- either we respect the sender's wishes > > (and thus optimize efficiency/network performance), or we respect > > the user's/receiver's wishes, and potentially lose a little > > efficiency/performance. (Guess which option is the right option :b) > > I don't understand what you're getting at. So if you say you want > XKiB/sec you want freenet to read XKiB/sec, regardless of what it's > actually using? Precisely. > The important point is: > - Once the packet is in the receiver's queue it has _already_ been > received. If the limiter has messed up it's too late to fix it. > > It's like deciding to dump half your fuel tank after paying because > you only wanted to fill half way. Precisely. (There is no real limiter, in the scenario you're proposing though. At some point, packets will need to be dropped. How would you distinguish between a DDOS attack, and enthusiastic super-nodes?) (I'm actually not quite sure how the traffic flows -- are packets pushed onto other nodes, or are they pulled?) ___ 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: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. Freenet itself acknowledges packets, and that's part of the rate limiting, which obviously has some bugs. Not reading the packets will work for a while, but when packets are read and ack'd the senders will burst again, not knowing there's a limit. The only solution is to fix the limiter bugs, which is tough for a project with so few developers. ___ 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:51 AM, Dennis Nezic wrote: > On Sat, 22 Jan 2011 07:37:54 +1300, Phillip Hutchings wrote: >> >> 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. > > 1) It puts the user in control. If I specify XKiB/sec, I > expect/demand XKiB/sec usage :b. > > 2) The packets will only be dropped if there is excessive load, which > obviously should be avoided by all the custom overhead. OS-packet > dropping would only serve as a last resort -- ie. if freenet's > traffic-coordination messes up (as it currently does! :p), or if we are > connected to malicious nodes. > > There are two options here -- either we respect the sender's wishes > (and thus optimize efficiency/network performance), or we respect the > user's/receiver's wishes, and potentially lose a little > efficiency/performance. (Guess which option is the right option :b) I don't understand what you're getting at. So if you say you want XKiB/sec you want freenet to read XKiB/sec, regardless of what it's actually using? The important point is: - Once the packet is in the receiver's queue it has _already_ been received. If the limiter has messed up it's too late to fix it. It's like deciding to dump half your fuel tank after paying because you only wanted to fill half way. ___ 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 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!) ___ 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:37:54 +1300, Phillip Hutchings wrote: > > 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. 1) It puts the user in control. If I specify XKiB/sec, I expect/demand XKiB/sec usage :b. 2) The packets will only be dropped if there is excessive load, which obviously should be avoided by all the custom overhead. OS-packet dropping would only serve as a last resort -- ie. if freenet's traffic-coordination messes up (as it currently does! :p), or if we are connected to malicious nodes. There are two options here -- either we respect the sender's wishes (and thus optimize efficiency/network performance), or we respect the user's/receiver's wishes, and potentially lose a little efficiency/performance. (Guess which option is the right option :b) ___ 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
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! On 01/21/2011 11: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? ___ 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 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
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: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 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 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 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
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 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 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
