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.
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
