On Friday 21 January 2011 19:32:15 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?)

What it does is EXACTLY WHAT TCP DOES: If it doesn't get a response within a 
few round trips, it sends the data again.

It also applies congestion control algorithms which are similar to TCP's, but 
not as accurate as they only (at the moment) apply to big packets and not to 
small ones.

Attachment: signature.asc
Description: This is a digitally signed message part.

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