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
