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?
As I understand it, and if any networking gurus are around please correct me, IT IS EXACTLY WHAT TCP DOES. > > (My last flood occurred for over 10 minutes, and then managed to stop. > I believe all 5 of my connected strangers were listed as BackedOff > during the flood. I will try to provide more details and more testing.) Was your upstream saturated at the time due to e.g. external pressure?
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