On Friday 28 January 2011 18:39:53 Dennis Nezic wrote:
> On Fri, 28 Jan 2011 18:11:29 +0000, Matthew Toseland wrote:
> > CC'ing Martin in case he has any ideas.
> > 
> > On Thursday 27 January 2011 19:01:28 Dennis Nezic wrote:
> > > On Thu, 27 Jan 2011 18:49:57 +0000, Matthew Toseland wrote:
> > > > On Thursday 27 January 2011 17:17:15 Dennis Nezic wrote:
> > > > > On Thu, 27 Jan 2011 16:55:58 +0000, Matthew Toseland wrote:
> > > > > > On Wednesday 26 January 2011 20:14:52 Dennis Nezic wrote:
> > > > > > > On Wed, 26 Jan 2011 19:59:43 +0000, Matthew Toseland wrote:
> > > > > > > > On Wednesday 26 January 2011 19:42:38 Dennis Nezic wrote:
> > > > > > > > > On Wed, 26 Jan 2011 19:38:55 +0000, Matthew Toseland
> > > > > > > > > wrote:
> > > > > > > > > > On Monday 24 January 2011 22:28:36 you wrote:
> > > > > > > > > > > On Mon, 24 Jan 2011 18:29:14 +0000, Matthew Toseland
> > > > > > > > > > > wrote:
> > > > > > > > > > > > Freenet 0.7.5 build 1336 is now available. Please
> > > > > > > > > > > > upgrade, it will be mandatory on Friday. Much of
> > > > > > > > > > > > this build is intended to try to improve network
> > > > > > > > > > > > performance and particularly to prevent transfer
> > > > > > > > > > > > failures especially on realtime requests.
> > > > > > > > > > > > 
> > > > > > > > > > > > Details:
> > > > > > > > > > > > - Fix some block transfer bugs related to transfer
> > > > > > > > > > > > coalescing, disconnects and reassigning to self
> > > > > > > > > > > > after a request has taken too long.
> > > > > > > > > > > > - Keep on transferring the data if we need it for
> > > > > > > > > > > > a local request, and explain why this is safe in
> > > > > > > > > > > > comments. However it will go away when we get rid
> > > > > > > > > > > > of receiver-side transfer cancels anyway.
> > > > > > > > > > > > - Fix even more bugs related to request forking on
> > > > > > > > > > > > timeout.
> > > > > > > > > > > > - Always drop the queued messages when we
> > > > > > > > > > > > disconnect due to a timeout.
> > > > > > > > > > > > - Eliminate turtle transfers, they are no longer
> > > > > > > > > > > > necessary and involve unnecessary complexity and
> > > > > > > > > > > > transfer cancels. We will soon eliminate receiver
> > > > > > > > > > > > cancels too which will further simplify matters.
> > > > > > > > > > > > - Remove timed out filters more often.
> > > > > > > > > > > > - Show totals for backoff times.
> > > > > > > > > > > > - Fixes to auto-testing code.
> > > > > > > > > > > 
> > > > > > > > > > > This build still can't manage to handle input
> > > > > > > > > > > bandwidth sanely, on a congested connection -- it
> > > > > > > > > > > entirely consumes my already busy connection. (Aka.
> > > > > > > > > > > my freenet is still unusable here.)
> > > > > > > > > > 
> > > > > > > > > > Limiting input bandwidth usage accurately is
> > > > > > > > > > extraordinarily difficult and most people have fat
> > > > > > > > > > pipes downstream.
> > > > > > > > > > 
> > > > > > > > > > Probably your peers are resending packets constantly.
> > > > > > > > > 
> > > > > > > > > So, umm, make them stop, after say a minute of flooding?
> > > > > > > > > 
> > > > > > > > And disconnect completely? That kind of defeats the point
> > > > > > > > doesn't it?
> > > > > > > 
> > > > > > > No, that doesn't defeat the point. The point is to have a
> > > > > > > running Freenet, which is simply not possible at the moment,
> > > > > > > since it will flood my internet connection to an unusable
> > > > > > > state.
> > > > > > 
> > > > > > A running Freenet that disconnects from all your peers and
> > > > > > constantly announces because your connection is broken? How is
> > > > > > that useful?
> > > > > 
> > > > > My connection isn't broken. I actually took much pain to
> > > > > somewhat guarantee that my Freenet gets the bandwidth I
> > > > > allocate it.
> > > > > 
> > > > > 
> > > > > > > Moreover, what's the problem with "completely disconnecting"
> > > > > > > from a peer, after it continues to flood us for many
> > > > > > > minutes?
> > > > > > 
> > > > > > You are flooding it, not the other way around. It's entirely
> > > > > > your fault for not having the bandwidth to handle the data.
> > > > > > Freenet is tested and developed on typical connections which
> > > > > > have lots of downstream bandwidth and not much upstream
> > > > > > bandwidth. And Freenet is only doing exactly what TCP would
> > > > > > do! Admittedly TCP has a different algorithm for estimating
> > > > > > round trip times, and a more precise congestion control
> > > > > > mechanism. But I have yet to be convinced that this is a
> > > > > > serious issue for any other person than you and therefore
> > > > > > worth spending significant amounts of developer time on. I'm
> > > > > > also not sure exactly what would fix it...
> > > > > 
> > > > > I really think you haven't understood the problem yet. This
> > > > > isn't just a bumpy averaging of bursting input -- this is a
> > > > > *sustained 5+ minute flood that completely uses up 100KB/s
> > > > > downstream connection, and 5x the bandwidth I allocate it*.
> > > > > You're not sure what would fix it? Like I mentioned a couple
> > > > > times here already, *how about after a minute or two, telling
> > > > > my connected peers to SLOW DOWN*?
> > > > 
> > > > The reason they are sending data is that they are NOT receiving
> > > > your acknowledgements. So sending yet more control data won't
> > > > help.
> > > 
> > > Well that sure sounds like a recipe for disaster. How long are peers
> > > supposed to keep pushing data to un-acknowledging peers, before they
> > > do something?
> > 
> > We disconnect from a node if we haven't received anything from it in
> > 60 seconds.
> 
> So, this suggests that my flooding peer(s) do receive traffic-control
> messages from me. So, after a minute in the flood, obviously my allowed
> input is *ZERO* bytes from them, or anyone, (give or take a kilobyte --
> i'm a flexible dude), and my peers are told this -- why aren't they
> slowing down?

I have filed a bunch of related bugs that may help with reducing unnecessary 
resends, all linked from this bug:
https://bugs.freenetproject.org/view.php?id=4700

Attachment: 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

Reply via email to