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 <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.
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
