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