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? _______________________________________________ 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
