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