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
