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

Reply via email to