Re: [freenet-support] Freenet 0.7.5 build 1336

2011-01-29 Thread Matthew Toseland
On Friday 28 January 2011 23:04:27 Phillip Hutchings wrote:
 
  I was referring to Freenet's custom congestion control. There is no
  resending of UDP packets, unless Freenet pro-actively resends it.
  
  Right, and what we do is we resend packets if they are not acknowledged 
  after a few round trips. Which is pretty much what TCP does.
 
 I'm not entirely sure how Freenet does it, but it doesn't sound quite the 
 same as TCP.
 
 Disclaimer: I'm not an expert on TCP
 
 In TCP congestion control is handled by the window size, the exponential 
 backoff algorithm and estimated round-trip time.
 
 The window size controls how many bytes can by 'in-flight', that is sent 
 without an ACK received. This is advertised by the receiver as part of the 
 handshake.
 
 If an ACK isn't received after a given delay the packet is resent and the 
 window is decreased, say by a power of two. When the ACKs are received in a 
 timely fashion the window size is increased linearly. This stabilises the 
 transmission rate fairly well.

Right. We do exactly this, in the link-level AIMD's. However, the congestion 
window at the moment operates at a relatively high level, not directly 
controlling the packets in flight, but only controlling the 
queued-plus-in-flight block transfer messages (not all packets). This is one of 
several things that needs to be fixed.
 
 TCP is more complex than this brief summary, as it also implements a 
 slow-start algorithm and makes an effort to avoid hitting backoff by the 
 linear increase.

We also have slow start, and the RFC-specified hack to avoid increasing the 
window size when we're not filling it. But we need the window to be a true 
window that applies to all packets, and at the transfer level, not to block 
transfer messages only.


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

Re: [freenet-support] Freenet 0.7.5 build 1336

2011-01-29 Thread Matthew Toseland
On Friday 28 January 2011 18:25:09 Dennis Nezic wrote:
 On Fri, 28 Jan 2011 18:14:14 +, Matthew Toseland wrote:
 (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?
   
   Nope. It might have started the flood -- I'll do some more testing,
   but during the flood the connection was only minimally being used.
   (I really don't know why my peers will still dumping so much data
   onto my node -- perhaps it was in their to-send queues? Perhaps
   there is a bug, and they didn't get my slow-down traffic messages?)
  
  What slow down messages?
  
  Are you saying that the peers are actually doing exactly what the
  node is asking of them, i.e. sending useful data? I.e. it's not a
  problem with constant resends?
 
 How does one differentiate between a resend and useful data? 

Generally you don't on the receiver side. On the sender side it is obvious from 
the stats - both the overall bandwidth stats and the per-peer in/out/resent 
stats.

 Does the 
 value in the /stats page, or on the peer-list page indicate useful
 data? If so, it is steadily rising, even when the peer is backed off,
 even when my downstream is peaked at FIVE TIMES my downstream limit :p
 completely saturating my downstream (upstream is always generally
 low-traffic), for many (~5+) minutes.

IMHO it is likely that it is resends because we do *try* to respect the 
downstream limits in our acceptance of requests. I.e. we only accept as many 
requests as we can transfer the data for, within 60 seconds (realtime) or 120 
seconds (bulk); add a bit on for overhead. Plus we have some rarely used token 
buckets; your reject reasons might be interesting. However, it is still 
possible for it to max it out for a while even without resending; it just seems 
more likely that it is resending.

The difficulty with the resending theory is that if your upstream is okay, and 
you don't have the sort of connection where saturating your downstream also 
makes your upstream break (I believe some forms of DSL have this problem or 
used to), there is no real reason to expect mass resend, except perhaps for 
hard to identify bugs.


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

Re: [freenet-support] Freenet 0.7.5 build 1336

2011-01-29 Thread Matthew Toseland
On Friday 28 January 2011 18:39:53 Dennis Nezic wrote:
 On Fri, 28 Jan 2011 18:11:29 +, 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 +, Matthew Toseland wrote:
On Thursday 27 January 2011 17:17:15 Dennis Nezic wrote:
 On Thu, 27 Jan 2011 16:55:58 +, Matthew Toseland wrote:
  On Wednesday 26 January 2011 20:14:52 Dennis Nezic wrote:
   On Wed, 26 Jan 2011 19:59:43 +, Matthew Toseland wrote:
On Wednesday 26 January 2011 19:42:38 Dennis Nezic wrote:
 On Wed, 26 Jan 2011 19:38:55 +, Matthew Toseland
 wrote:
  On Monday 24 January 2011 22:28:36 you wrote:
   On Mon, 24 Jan 2011 18:29:14 +, 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.
 
 

Re: [freenet-support] Freenet 0.7.5 build 1336

2011-01-28 Thread Matthew Toseland
On Thursday 27 January 2011 19:01:28 Dennis Nezic wrote:
 On Thu, 27 Jan 2011 18:49:57 +, Matthew Toseland wrote:
  On Thursday 27 January 2011 17:17:15 Dennis Nezic wrote:
   On Thu, 27 Jan 2011 16:55:58 +, Matthew Toseland wrote:
On Wednesday 26 January 2011 20:14:52 Dennis Nezic wrote:
 On Wed, 26 Jan 2011 19:59:43 +, Matthew Toseland wrote:
  On Wednesday 26 January 2011 19:42:38 Dennis Nezic wrote:
   On Wed, 26 Jan 2011 19:38:55 +, Matthew Toseland wrote:
On Monday 24 January 2011 22:28:36 you wrote:
 On Mon, 24 Jan 2011 18:29:14 +, 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.

Re: [freenet-support] Freenet 0.7.5 build 1336

2011-01-28 Thread Dennis Nezic
On Fri, 28 Jan 2011 17:44:07 +, Matthew Toseland wrote:
 On Thursday 27 January 2011 19:01:28 Dennis Nezic wrote:
  On Thu, 27 Jan 2011 18:49:57 +, Matthew Toseland wrote:
   On Thursday 27 January 2011 17:17:15 Dennis Nezic wrote:
On Thu, 27 Jan 2011 16:55:58 +, Matthew Toseland wrote:
 On Wednesday 26 January 2011 20:14:52 Dennis Nezic wrote:
  On Wed, 26 Jan 2011 19:59:43 +, Matthew Toseland wrote:
   On Wednesday 26 January 2011 19:42:38 Dennis Nezic wrote:
On Wed, 26 Jan 2011 19:38:55 +, Matthew Toseland
wrote:
 On Monday 24 January 2011 22:28:36 you wrote:
  On Mon, 24 Jan 2011 18:29:14 +, 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.

I was referring to Freenet's custom congestion control. There is no
resending of UDP packets, unless Freenet pro-actively resends it.


  (My last flood occurred for over 10 

Re: [freenet-support] Freenet 0.7.5 build 1336

2011-01-28 Thread Matthew Toseland
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 +, Matthew Toseland wrote:
  On Thursday 27 January 2011 17:17:15 Dennis Nezic wrote:
   On Thu, 27 Jan 2011 16:55:58 +, Matthew Toseland wrote:
On Wednesday 26 January 2011 20:14:52 Dennis Nezic wrote:
 On Wed, 26 Jan 2011 19:59:43 +, Matthew Toseland wrote:
  On Wednesday 26 January 2011 19:42:38 Dennis Nezic wrote:
   On Wed, 26 Jan 2011 19:38:55 +, Matthew Toseland wrote:
On Monday 24 January 2011 22:28:36 you wrote:
 On Mon, 24 Jan 2011 18:29:14 +, 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.
 
 (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.)

What was your upstream bandwidth doing during this period? The reason for 
resends is that the original messages were not acked.

Several 

Re: [freenet-support] Freenet 0.7.5 build 1336

2011-01-28 Thread Matthew Toseland
On Friday 28 January 2011 18:05:53 Dennis Nezic wrote:
 On Fri, 28 Jan 2011 17:44:07 +, Matthew Toseland wrote:
  On Thursday 27 January 2011 19:01:28 Dennis Nezic wrote:
   On Thu, 27 Jan 2011 18:49:57 +, Matthew Toseland wrote:
On Thursday 27 January 2011 17:17:15 Dennis Nezic wrote:
 On Thu, 27 Jan 2011 16:55:58 +, Matthew Toseland wrote:
  On Wednesday 26 January 2011 20:14:52 Dennis Nezic wrote:
   On Wed, 26 Jan 2011 19:59:43 +, Matthew Toseland wrote:
On Wednesday 26 January 2011 19:42:38 Dennis Nezic wrote:
 On Wed, 26 Jan 2011 19:38:55 +, Matthew Toseland
 wrote:
  On Monday 24 January 2011 22:28:36 you wrote:
   On Mon, 24 Jan 2011 18:29:14 +, 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.
 
 I was referring to 

Re: [freenet-support] Freenet 0.7.5 build 1336

2011-01-28 Thread Dennis Nezic
On Fri, 28 Jan 2011 18:14:14 +, Matthew Toseland wrote:
(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?
  
  Nope. It might have started the flood -- I'll do some more testing,
  but during the flood the connection was only minimally being used.
  (I really don't know why my peers will still dumping so much data
  onto my node -- perhaps it was in their to-send queues? Perhaps
  there is a bug, and they didn't get my slow-down traffic messages?)
 
 What slow down messages?
 
 Are you saying that the peers are actually doing exactly what the
 node is asking of them, i.e. sending useful data? I.e. it's not a
 problem with constant resends?

How does one differentiate between a resend and useful data? Does the
value in the /stats page, or on the peer-list page indicate useful
data? If so, it is steadily rising, even when the peer is backed off,
even when my downstream is peaked at FIVE TIMES my downstream limit :p
completely saturating my downstream (upstream is always generally
low-traffic), for many (~5+) minutes.
___
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


Re: [freenet-support] Freenet 0.7.5 build 1336

2011-01-28 Thread Dennis Nezic
On Fri, 28 Jan 2011 18:11:29 +, 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 +, Matthew Toseland wrote:
   On Thursday 27 January 2011 17:17:15 Dennis Nezic wrote:
On Thu, 27 Jan 2011 16:55:58 +, Matthew Toseland wrote:
 On Wednesday 26 January 2011 20:14:52 Dennis Nezic wrote:
  On Wed, 26 Jan 2011 19:59:43 +, Matthew Toseland wrote:
   On Wednesday 26 January 2011 19:42:38 Dennis Nezic wrote:
On Wed, 26 Jan 2011 19:38:55 +, Matthew Toseland
wrote:
 On Monday 24 January 2011 22:28:36 you wrote:
  On Mon, 24 Jan 2011 18:29:14 +, 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* 

Re: [freenet-support] Freenet 0.7.5 build 1336

2011-01-28 Thread Phillip Hutchings

 I was referring to Freenet's custom congestion control. There is no
 resending of UDP packets, unless Freenet pro-actively resends it.
 
 Right, and what we do is we resend packets if they are not acknowledged after 
 a few round trips. Which is pretty much what TCP does.

I'm not entirely sure how Freenet does it, but it doesn't sound quite the same 
as TCP.

Disclaimer: I'm not an expert on TCP

In TCP congestion control is handled by the window size, the exponential 
backoff algorithm and estimated round-trip time.

The window size controls how many bytes can by 'in-flight', that is sent 
without an ACK received. This is advertised by the receiver as part of the 
handshake.

If an ACK isn't received after a given delay the packet is resent and the 
window is decreased, say by a power of two. When the ACKs are received in a 
timely fashion the window size is increased linearly. This stabilises the 
transmission rate fairly well.

TCP is more complex than this brief summary, as it also implements a slow-start 
algorithm and makes an effort to avoid hitting backoff by the linear increase.
___
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


Re: [freenet-support] Freenet 0.7.5 build 1336

2011-01-27 Thread Matthew Toseland
On Wednesday 26 January 2011 20:14:52 Dennis Nezic wrote:
 On Wed, 26 Jan 2011 19:59:43 +, Matthew Toseland wrote:
  On Wednesday 26 January 2011 19:42:38 Dennis Nezic wrote:
   On Wed, 26 Jan 2011 19:38:55 +, Matthew Toseland wrote:
On Monday 24 January 2011 22:28:36 you wrote:
 On Mon, 24 Jan 2011 18:29:14 +, 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

Re: [freenet-support] Freenet 0.7.5 build 1336

2011-01-27 Thread Dennis Nezic
On Thu, 27 Jan 2011 16:55:58 +, Matthew Toseland wrote:
 On Wednesday 26 January 2011 20:14:52 Dennis Nezic wrote:
  On Wed, 26 Jan 2011 19:59:43 +, Matthew Toseland wrote:
   On Wednesday 26 January 2011 19:42:38 Dennis Nezic wrote:
On Wed, 26 Jan 2011 19:38:55 +, Matthew Toseland wrote:
 On Monday 24 January 2011 22:28:36 you wrote:
  On Mon, 24 Jan 2011 18:29:14 +, 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


Re: [freenet-support] Freenet 0.7.5 build 1336

2011-01-27 Thread Dennis Nezic
On Thu, 27 Jan 2011 18:49:57 +, Matthew Toseland wrote:
 On Thursday 27 January 2011 17:17:15 Dennis Nezic wrote:
  On Thu, 27 Jan 2011 16:55:58 +, Matthew Toseland wrote:
   On Wednesday 26 January 2011 20:14:52 Dennis Nezic wrote:
On Wed, 26 Jan 2011 19:59:43 +, Matthew Toseland wrote:
 On Wednesday 26 January 2011 19:42:38 Dennis Nezic wrote:
  On Wed, 26 Jan 2011 19:38:55 +, Matthew Toseland wrote:
   On Monday 24 January 2011 22:28:36 you wrote:
On Mon, 24 Jan 2011 18:29:14 +, 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?

(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.)
___
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


Re: [freenet-support] Freenet 0.7.5 build 1336

2011-01-27 Thread Dennis Nezic
On Thu, 27 Jan 2011 14:01:28 -0500, Dennis Nezic wrote:
 On Thu, 27 Jan 2011 18:49:57 +, Matthew Toseland wrote:
  On Thursday 27 January 2011 17:17:15 Dennis Nezic wrote:
   On Thu, 27 Jan 2011 16:55:58 +, Matthew Toseland wrote:
On Wednesday 26 January 2011 20:14:52 Dennis Nezic wrote:
 On Wed, 26 Jan 2011 19:59:43 +, Matthew Toseland wrote:
  On Wednesday 26 January 2011 19:42:38 Dennis Nezic wrote:
   On Wed, 26 Jan 2011 19:38:55 +, Matthew Toseland
   wrote:
On Monday 24 January 2011 22:28:36 you wrote:
 On Mon, 24 Jan 2011 18:29:14 +, 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?
 
 (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.)

I just experienced, I think, a spontaneous flood -- I don't think my
connection was even being used significantly.

Build 1337.
2 connected stranger.
9 backed off.

Reasons:
* AcceptedTimeout 3 
* ForwardRejectedOverload 1
* 

Re: [freenet-support] Freenet 0.7.5 build 1336

2011-01-26 Thread Dennis Nezic
On Wed, 26 Jan 2011 19:59:43 +, Matthew Toseland wrote:
 On Wednesday 26 January 2011 19:42:38 Dennis Nezic wrote:
  On Wed, 26 Jan 2011 19:38:55 +, Matthew Toseland wrote:
   On Monday 24 January 2011 22:28:36 you wrote:
On Mon, 24 Jan 2011 18:29:14 +, 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.

Moreover, what's the problem with completely disconnecting from a
peer, after it continues to flood us for many minutes?
___
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


Re: [freenet-support] Freenet 0.7.5 build 1336

2011-01-24 Thread Dennis Nezic
On Mon, 24 Jan 2011 18:29:14 +, 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.)
___
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