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
Support mailing list
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe

Reply via email to