Re: [freenet-support] Freenet 0.7.5 build 1334

2011-01-26 Thread Matthew Toseland
On Friday 21 January 2011 19:32:15 Dennis Nezic wrote:
 On Sat, 22 Jan 2011 08:22:13 +1300, Phillip Hutchings wrote:
   So, the question then becomes, when the node is clearly receiving
   more packets than it's supposed to, why is it taking so long (many
   minutes
   -- I never actually waited to see if the flood, which consumed my
   entire connection's 80KiB/sec capacity, would eventually subside)
   for the rate to stabilize? How much time does the node give it's
   peers to stabilize their traffic, before it disconnects from them?
   And does the node accept packets from peers it is not currently
   connected to? (Ie. say we give our peers 1minute to get their s***
   straight, and then disconnect from them, I should see the flood end
   in 1 minute?)
  
  Mostly because development capability is limited by available people
  and testing capabilities - without a dedicated lab setup it's very
  hard to test bandwidth limiting, so the only real test is on the
  network.
  
  I'm sure fixing this is on the list somewhere, but we either need to
  pitch in and code it or wait for someone else to have time.
 
 I'm curious, though, as to what the node currently does. (To bring us
 back to the original question of this thread.) (Yes, I should just look
 at the code myself.) Surely it does something like I just described
 above? And surely that's a simple thing? (When you refer to testing,
 you're probably referring to fine-tunning the above parameters to
 maximize efficiency ... which is all good ... except even without such
 testing, I don't see why it should take many minutes for flow to
 stabilize -- unless our grace-period for overflowing nodes is many
 minutes long?)

What it does is EXACTLY WHAT TCP DOES: If it doesn't get a response within a 
few round trips, it sends the data again.

It also applies congestion control algorithms which are similar to TCP's, but 
not as accurate as they only (at the moment) apply to big packets and not to 
small ones.


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 1334

2011-01-22 Thread Dennis Nezic
On Sat, 22 Jan 2011 08:06:28 +0300, Volodya wrote:
  Please describe the formula through which to calculate the speed of
  the data that you need to send to your peer, which has 19 other
  peers (and you have no knowledge about the speed with which they
  are transmitting).
  
  Simple:
  
  for i in output-bandwidth
for j in list-of-peers
  if j said it was ok to send stuff over within the last minute
send remaining-output-bandwidth, weighted for particular
  peer end
  end
  
  In other words, the main thing is I have to explicitly say I am
  expecting stuff, and that there is an explicit timeperiod beyond
  which other peers should not continue sending me stuff, without my
  saying it's ok.
  
  Similarly, on the receiving end, I will only read packets from
  peers on my connected-list. (Yes, this is kindof like wasting
  bandwidth and dropping precious packets ... but remember this is
  AFTER we give our flooding peer ample time to settle down -- aka.
  this is bordering on malicious / ddos behavior.)
 
 I think that would make the problem much worse:
 
 Scenario:
 You have a spike of CPU useage and your node receives little packets
 over 1 minute.

We can make the threshold longer -- 2, 3 minutes? (My flood went on for
at least 5+ minutes.)

 It calculates how much it could have received more and sends all its
 peers request to almost entire bandwidth.

Obviously it shouldn't do this, then :p. (Ie. obviously asking for a
flood will probably deliver a flood. It should never ask for more than
it can handle -- even if that means not being fully efficient for a
little while.)

 Then the CPU spike ends and it gets swamped with about 20 times the
 download limit of packets. It then starts dropping packets because it
 considers this an attack, hurting not only its ow self, but others in
 the process.

Nope. It will only consider it an attack AFTER it sends these flooding
peers notice to back off (or, similarly, if those peers aren't
explicitly told it's ok to send stuff). At which point it really is an
attack.
___
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 1334

2011-01-22 Thread Dennis Nezic
On Sat, 22 Jan 2011 10:55:40 -0500, Dennis Nezic wrote:
 On Sat, 22 Jan 2011 08:06:28 +0300, Volodya wrote:
   Please describe the formula through which to calculate the speed
   of the data that you need to send to your peer, which has 19
   other peers (and you have no knowledge about the speed with
   which they are transmitting).
   
   Simple:
   
   for i in output-bandwidth
 for j in list-of-peers
   if j said it was ok to send stuff over within the last
   minute send remaining-output-bandwidth, weighted for particular
   peer end
   end
   
   In other words, the main thing is I have to explicitly say I am
   expecting stuff, and that there is an explicit timeperiod beyond
   which other peers should not continue sending me stuff, without my
   saying it's ok.
   
   Similarly, on the receiving end, I will only read packets from
   peers on my connected-list. (Yes, this is kindof like wasting
   bandwidth and dropping precious packets ... but remember this is
   AFTER we give our flooding peer ample time to settle down -- aka.
   this is bordering on malicious / ddos behavior.)
  
  I think that would make the problem much worse:
  
  Scenario:
  You have a spike of CPU useage and your node receives little packets
  over 1 minute.
 
 We can make the threshold longer -- 2, 3 minutes? (My flood went on
 for at least 5+ minutes.)
 
  It calculates how much it could have received more and sends all its
  peers request to almost entire bandwidth.
 
 Obviously it shouldn't do this, then :p. (Ie. obviously asking for a
 flood will probably deliver a flood. It should never ask for more than
 it can handle -- even if that means not being fully efficient for a
 little while.)

This actually sounds like a very plausible explanation for what was
going on.

Build 1335 seems a lot more robust for me. I've had it up for about a
day, under various traffic conditions, and it hasn't gone insane yet.
Quite stable, actually.
___
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 1334

2011-01-21 Thread Dennis Nezic
On Fri, 21 Jan 2011 05:59:06 +0100, David ‘Bombe’ Roden wrote:
 On Thursday 20 January 2011 20:32:30 Dennis Nezic wrote:
 
Fix!
   Please refrain from bossing us around. You are not in a position
   to do that.
  Please refrain from mis-interpreting my words. (There is such a
  thing as 'c-o-n-t-e-x-t', eh?) (Perhaps acquire a sense of humor
  while you're at it.)
 
 The context here would be three messages in which you are ranting
 about how Freenet does not manage to do a “simple thing” like
 bandwidth limiting and how it sucks and get worse all the time,

In fact, I tried hard to figure out when exactly the limiting was
failing, and graciously reported my debugging efforts. (It's occurring
only when my connection gets swamped by other traffic.)

 And though I can assure you that nothing is wrong with my humor, I
 fail to see anything funny in behaving like you specifically were the
 person Freenet has been developed for.

I assure you, there is something wrong with your humor. And you are
completly projecting your own false imaginations of my intentions and
behavior on my words -- which, honestly, were meant to be playful and
helpful. (It would be interesting to explore the source of these
negative projections of yours, but it's off topic on this list.)
___
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 1334

2011-01-21 Thread Dennis Nezic
On Fri, 21 Jan 2011 05:59:06 +0100, David ‘Bombe’ Roden wrote:
 a “simple thing” like bandwidth limiting

Can someone explain why bandwidth limiting might not be such a simple
thing? Volodya tried, with his massive-incoming-packet theory
(40KiB :p), but that's not true -- freenet packets are about 1KiB. So,
is there not a central class/wrapper in place that feeds the node with
at most X KiB / second? Ie. it will only read X UDP packets per second?
___
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 1334

2011-01-21 Thread Phillip Hutchings

On 22/01/2011, at 7:21 AM, Dennis Nezic wrote:

 On Fri, 21 Jan 2011 05:59:06 +0100, David ‘Bombe’ Roden wrote:
 a “simple thing” like bandwidth limiting
 
 Can someone explain why bandwidth limiting might not be such a simple
 thing? Volodya tried, with his massive-incoming-packet theory
 (40KiB :p), but that's not true -- freenet packets are about 1KiB. So,
 is there not a central class/wrapper in place that feeds the node with
 at most X KiB / second? Ie. it will only read X UDP packets per second?

It doesn't matter if you only read X packets a second, they've still been sent 
to you so it still used bandwidth. If you don't read UDP all that happens is 
your OS queues for a while the starts dropping packets. Unlike TCP, UDP doesn't 
implement speed controls. To control UDP you have to implement your own 
feedback and control system on the sender. To compound that freenet has to 
allocate its bandwidth over multiple senders, and it can't just to an even 
split as not all senders are equal.
___
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 1334

2011-01-21 Thread Dennis Nezic
On Sat, 22 Jan 2011 07:26:56 +1300, Phillip Hutchings wrote:
 
 On 22/01/2011, at 7:21 AM, Dennis Nezic wrote:
 
  On Fri, 21 Jan 2011 05:59:06 +0100, David ‘Bombe’ Roden wrote:
  a “simple thing” like bandwidth limiting
  
  Can someone explain why bandwidth limiting might not be such a
  simple thing? Volodya tried, with his massive-incoming-packet theory
  (40KiB :p), but that's not true -- freenet packets are about 1KiB.
  So, is there not a central class/wrapper in place that feeds the
  node with at most X KiB / second? Ie. it will only read X UDP
  packets per second?
 
 It doesn't matter if you only read X packets a second, they've still
 been sent to you so it still used bandwidth. If you don't read UDP
 all that happens is your OS queues for a while the starts dropping
 packets.

Exactly. Why isn't this being done?
___
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 1334

2011-01-21 Thread Phillip Hutchings

On 22/01/2011, at 7:34 AM, Dennis Nezic wrote:

 On Sat, 22 Jan 2011 07:26:56 +1300, Phillip Hutchings wrote:
 
 On 22/01/2011, at 7:21 AM, Dennis Nezic wrote:
 
 On Fri, 21 Jan 2011 05:59:06 +0100, David ‘Bombe’ Roden wrote:
 a “simple thing” like bandwidth limiting
 
 Can someone explain why bandwidth limiting might not be such a
 simple thing? Volodya tried, with his massive-incoming-packet theory
 (40KiB :p), but that's not true -- freenet packets are about 1KiB.
 So, is there not a central class/wrapper in place that feeds the
 node with at most X KiB / second? Ie. it will only read X UDP
 packets per second?
 
 It doesn't matter if you only read X packets a second, they've still
 been sent to you so it still used bandwidth. If you don't read UDP
 all that happens is your OS queues for a while the starts dropping
 packets.
 
 Exactly. Why isn't this being done?

Why isn't what being done? There's absolutely no point letting the OS drop the 
packets. They have already been transmitted, they're in the receiver's memory. 
Dropping the packets is just wasting time and resources, you have to stop them 
before they're transmitted.
___
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 1334

2011-01-21 Thread Phillip Hutchings
 So, the question then becomes, when the node is clearly receiving more
 packets than it's supposed to, why is it taking so long (many minutes
 -- I never actually waited to see if the flood, which consumed my
 entire connection's 80KiB/sec capacity, would eventually subside) for
 the rate to stabilize? How much time does the node give it's peers to
 stabilize their traffic, before it disconnects from them? And does the
 node accept packets from peers it is not currently connected to? (Ie.
 say we give our peers 1minute to get their s*** straight, and then
 disconnect from them, I should see the flood end in 1 minute?)

Mostly because development capability is limited by available people and 
testing capabilities - without a dedicated lab setup it's very hard to test 
bandwidth limiting, so the only real test is on the network.

I'm sure fixing this is on the list somewhere, but we either need to pitch in 
and code it or wait for someone else to have time.

___
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 1334

2011-01-21 Thread Dennis Nezic
On Sat, 22 Jan 2011 08:22:13 +1300, Phillip Hutchings wrote:
  So, the question then becomes, when the node is clearly receiving
  more packets than it's supposed to, why is it taking so long (many
  minutes
  -- I never actually waited to see if the flood, which consumed my
  entire connection's 80KiB/sec capacity, would eventually subside)
  for the rate to stabilize? How much time does the node give it's
  peers to stabilize their traffic, before it disconnects from them?
  And does the node accept packets from peers it is not currently
  connected to? (Ie. say we give our peers 1minute to get their s***
  straight, and then disconnect from them, I should see the flood end
  in 1 minute?)
 
 Mostly because development capability is limited by available people
 and testing capabilities - without a dedicated lab setup it's very
 hard to test bandwidth limiting, so the only real test is on the
 network.
 
 I'm sure fixing this is on the list somewhere, but we either need to
 pitch in and code it or wait for someone else to have time.

I'm curious, though, as to what the node currently does. (To bring us
back to the original question of this thread.) (Yes, I should just look
at the code myself.) Surely it does something like I just described
above? And surely that's a simple thing? (When you refer to testing,
you're probably referring to fine-tunning the above parameters to
maximize efficiency ... which is all good ... except even without such
testing, I don't see why it should take many minutes for flow to
stabilize -- unless our grace-period for overflowing nodes is many
minutes long?)
___
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 1334

2011-01-21 Thread Volodya
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/21/2011 10:32 PM, Dennis Nezic wrote:
 On Sat, 22 Jan 2011 08:22:13 +1300, Phillip Hutchings wrote:
 So, the question then becomes, when the node is clearly receiving
 more packets than it's supposed to, why is it taking so long (many
 minutes
 -- I never actually waited to see if the flood, which consumed my
 entire connection's 80KiB/sec capacity, would eventually subside)
 for the rate to stabilize? How much time does the node give it's
 peers to stabilize their traffic, before it disconnects from them?
 And does the node accept packets from peers it is not currently
 connected to? (Ie. say we give our peers 1minute to get their s***
 straight, and then disconnect from them, I should see the flood end
 in 1 minute?)

 Mostly because development capability is limited by available people
 and testing capabilities - without a dedicated lab setup it's very
 hard to test bandwidth limiting, so the only real test is on the
 network.

 I'm sure fixing this is on the list somewhere, but we either need to
 pitch in and code it or wait for someone else to have time.
 
 I'm curious, though, as to what the node currently does. (To bring us
 back to the original question of this thread.) (Yes, I should just look
 at the code myself.) Surely it does something like I just described
 above? And surely that's a simple thing? (When you refer to testing,
 you're probably referring to fine-tunning the above parameters to
 maximize efficiency ... which is all good ... except even without such
 testing, I don't see why it should take many minutes for flow to
 stabilize -- unless our grace-period for overflowing nodes is many
 minutes long?)

Please describe the formula through which to calculate the speed of the data
that you need to send to your peer, which has 19 other peers (and you have no
knowledge about the speed with which they are transmitting).

- Volodya


- -- 
http://freedom.libsyn.com/ Echo of Freedom, Radical Podcast

 None of us are free until all of us are free.~ Mihail Bakunin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNOeoUAAoJENW9VI+wmYas5M4IAJtcV0CNJAKaAbAifds9dtTi
mVMfwrBmAAs64pYrMZJe6ib2c/JBuh4XATFu1Dj6VMdtwVz0Pp3lxMDqdytQ5eTm
P8lbo2kXuWG8MDdRxFKOKnuVv4mNA3GH3EN9Zh9DyON30G63uRL6epm8nypsuo39
m7l7vOmrqmsmBNifjRcaoo/IJcKIv6mHWCulqwgAc//ytWnvOhAlpuAcL1ca+Qo4
ry/VtEH0v1d3opDIBxxgvSj49Z53Q/2iUhpQXcU/0EAXU9IqyxdFBkkMIwtSgWgs
ct98GnR2z8TQo/rBV7uc+3Ue4y4JlsNyeEU59hN1yAWJF/CG6D2JDh2DSLK1RUg=
=0Oah
-END PGP SIGNATURE-
___
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 1334

2011-01-21 Thread Ray Jones


So let me see if I understand.

It's a breeze to get my firewall to accept incoming TCP packets from A 
or from B. But there are special routing permissions necessary to 
forward packets from A to B or from B to A, and it would be a nightmare 
to keep routing tables straight?


Speaking of firewalls, I have my FN UDP port forwarded both at my router 
and at my computer firewall. Most the time everything is fine, but once 
in a while I get a You appear to be behind a NAT warning. I dismiss 
the warning and I don't see anything for several hours or days. Is this 
normal?


On 01/21/2011 12:19 PM, Phillip Hutchings wrote:

On 22/01/2011, at 8:04 AM, Ray Jones wrote:


On 01/21/2011 11:59 AM, Phillip Hutchings wrote:

On 22/01/2011, at 7:55 AM, Dennis Nezic wrote:


On Fri, 21 Jan 2011 11:51:35 -0700, Ray Jones wrote:

If I understand correctly

UDP has no such thing as flow control. So even though your machine
reads only X packets per second, the sending machine is still sending
and you're still receiving. If the packets build up too far your
machine will drop them, but you've already used the bandwidth to get
them there before they were dropped!

I agree it's a terrible waste -- but, I say, tough luck. Surely the
senders will throttle back when they start seeing some of their packets
not being acknowledged. (Like I said, we should avoid this situation as
much as possible, but ultimately the user has to be in control. The
network, selfish as this might sound, comes second!)

NO! We're using UDP - UDP packets have no acknowledgment. TCP would behave like 
you describe, but UDP senders have no way of knowing that there's a problem.

Which brings this non-techies to the obvious (to me) question: So why are we 
using UDP instead of TCP?

Because UDP is easier to get through firewalls. TCP has state, so the firewall 
has to know you want to receive packets on a port, and it can identify the 
difference between an outgoing an incoming connection. With a network setup 
like this

A |firewall|   C-  |firewall| B

if A wants to talk to B, B needs to configure their firewall to allow it. They 
can both talk via C, but C always has to forward packets, if A send a packet to 
B the firewall would simply block it.

However, UDP doesn't have state, a firewall can't identify connections. This 
means if you have this setup:

A ||  C  || B

A can get a message to B via C, then at an agreed time both A and B send a 
packet to each other. Since the firewall can only identify packets, not 
connections, A's firewall consider's B's packet a response, and vice versa. 
Then A and B have a communication channel independent of C.

This is how the STUN system works.

It's advantageous for any system to use UDP as it removes many firewall issues 
and lowers the support load.

There are other reasons to use UDP, such as real time protocols - if you drop a 
packet in a voice conversation a delay is more harmful than an audio glitch.
___
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

___
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 1334

2011-01-21 Thread Dennis Nezic
On Fri, 21 Jan 2011 23:18:33 +0300, Volodya wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 01/21/2011 10:32 PM, Dennis Nezic wrote:
  On Sat, 22 Jan 2011 08:22:13 +1300, Phillip Hutchings wrote:
  So, the question then becomes, when the node is clearly receiving
  more packets than it's supposed to, why is it taking so long (many
  minutes
  -- I never actually waited to see if the flood, which consumed my
  entire connection's 80KiB/sec capacity, would eventually subside)
  for the rate to stabilize? How much time does the node give it's
  peers to stabilize their traffic, before it disconnects from them?
  And does the node accept packets from peers it is not currently
  connected to? (Ie. say we give our peers 1minute to get their s***
  straight, and then disconnect from them, I should see the flood
  end in 1 minute?)
 
  Mostly because development capability is limited by available
  people and testing capabilities - without a dedicated lab setup
  it's very hard to test bandwidth limiting, so the only real test
  is on the network.
 
  I'm sure fixing this is on the list somewhere, but we either need
  to pitch in and code it or wait for someone else to have time.
  
  I'm curious, though, as to what the node currently does. (To bring
  us back to the original question of this thread.) (Yes, I should
  just look at the code myself.) Surely it does something like I just
  described above? And surely that's a simple thing? (When you refer
  to testing, you're probably referring to fine-tunning the above
  parameters to maximize efficiency ... which is all good ... except
  even without such testing, I don't see why it should take many
  minutes for flow to stabilize -- unless our grace-period for
  overflowing nodes is many minutes long?)
 
 Please describe the formula through which to calculate the speed of
 the data that you need to send to your peer, which has 19 other peers
 (and you have no knowledge about the speed with which they are
 transmitting).

Simple:

for i in output-bandwidth
  for j in list-of-peers
if j said it was ok to send stuff over within the last minute
  send remaining-output-bandwidth, weighted for particular peer
  end
end

In other words, the main thing is I have to explicitly say I am
expecting stuff, and that there is an explicit timeperiod beyond which
other peers should not continue sending me stuff, without my saying
it's ok.

Similarly, on the receiving end, I will only read packets from peers on
my connected-list. (Yes, this is kindof like wasting bandwidth and
dropping precious packets ... but remember this is AFTER we give our
flooding peer ample time to settle down -- aka. this is bordering on
malicious / ddos behavior.)
___
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 1334

2011-01-21 Thread Ray Jones

On 01/21/2011 02:34 PM, Dennis Nezic wrote:

On Fri, 21 Jan 2011 23:18:33 +0300, Volodya wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/21/2011 10:32 PM, Dennis Nezic wrote:

On Sat, 22 Jan 2011 08:22:13 +1300, Phillip Hutchings wrote:

So, the question then becomes, when the node is clearly receiving
more packets than it's supposed to, why is it taking so long (many
minutes
-- I never actually waited to see if the flood, which consumed my
entire connection's 80KiB/sec capacity, would eventually subside)
for the rate to stabilize? How much time does the node give it's
peers to stabilize their traffic, before it disconnects from them?
And does the node accept packets from peers it is not currently
connected to? (Ie. say we give our peers 1minute to get their s***
straight, and then disconnect from them, I should see the flood
end in 1 minute?)

Mostly because development capability is limited by available
people and testing capabilities - without a dedicated lab setup
it's very hard to test bandwidth limiting, so the only real test
is on the network.

I'm sure fixing this is on the list somewhere, but we either need
to pitch in and code it or wait for someone else to have time.

I'm curious, though, as to what the node currently does. (To bring
us back to the original question of this thread.) (Yes, I should
just look at the code myself.) Surely it does something like I just
described above? And surely that's a simple thing? (When you refer
to testing, you're probably referring to fine-tunning the above
parameters to maximize efficiency ... which is all good ... except
even without such testing, I don't see why it should take many
minutes for flow to stabilize -- unless our grace-period for
overflowing nodes is many minutes long?)

Please describe the formula through which to calculate the speed of
the data that you need to send to your peer, which has 19 other peers
(and you have no knowledge about the speed with which they are
transmitting).

Simple:

for i in output-bandwidth
   for j in list-of-peers
 ifj said it was ok to send stuff over within the last minute
   sendremaining-output-bandwidth, weighted for particular peer
   end
end


I played around with some Basic programming (back before VB). I even got 
C++ to say 'Hello, World' to me a time or two. So don't think I'm 
speaking as a pro when I say, I be guessing it ain't that simple, bro.


___
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 1334

2011-01-21 Thread Volodya
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 Please describe the formula through which to calculate the speed of
 the data that you need to send to your peer, which has 19 other peers
 (and you have no knowledge about the speed with which they are
 transmitting).
 
 Simple:
 
 for i in output-bandwidth
   for j in list-of-peers
 if j said it was ok to send stuff over within the last minute
   send remaining-output-bandwidth, weighted for particular peer
   end
 end
 
 In other words, the main thing is I have to explicitly say I am
 expecting stuff, and that there is an explicit timeperiod beyond which
 other peers should not continue sending me stuff, without my saying
 it's ok.
 
 Similarly, on the receiving end, I will only read packets from peers on
 my connected-list. (Yes, this is kindof like wasting bandwidth and
 dropping precious packets ... but remember this is AFTER we give our
 flooding peer ample time to settle down -- aka. this is bordering on
 malicious / ddos behavior.)

I think that would make the problem much worse:

Scenario:
You have a spike of CPU useage and your node receives little packets over 1
minute. It calculates how much it could have received more and sends all its
peers request to almost entire bandwidth. Then the CPU spike ends and it gets
swamped with about 20 times the download limit of packets. It then starts
dropping packets because it considers this an attack, hurting not only its ow
self, but others in the process.

 - Volodya

- -- 
http://freedom.libsyn.com/ Echo of Freedom, Radical Podcast

 None of us are free until all of us are free.~ Mihail Bakunin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNOmXTAAoJENW9VI+wmYasxOoH/04L3eIdl5+CATH9Bti08qef
2wEdQcqCVeBJ9Mc8aubMBcvq/GuqsELWB5XuzQoyQ0XS9RLp2J+iUGiAtkOvegER
FKIQtp2jCPLArQ03voIN0mzTF6NH955th6y5BdCG22Zw4MCNNO/ykHC+fFXKoFPC
LsCY0nAIZ9EH2c84KIIDb3nYbtljmgNvBeKcYr5KUNLpwehE2meUfBVdYNS0e4fL
O2KY3KC1tpRNP9R2x5eI+1DsdMiUhhE/Dpq6ilnvdi8R7JooN/eefW3WqhqFOgXS
XuG0cZEn5IHr7fqyFpgHmcTBBl2ehGVk3GwcWNgCCFJmwxWbyEBtX73T97+oL9o=
=Hxhy
-END PGP SIGNATURE-
___
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 1334

2011-01-20 Thread Dennis Nezic
On Thu, 20 Jan 2011 12:48:56 +, Matthew Toseland wrote:
 Freenet 0.7.5 build 1334 is now available. It may fix some recent
 problems (particularly bwlimitDelayTime problems). Please upgrade!

Same problem as I originally reported a while ago. Input bandwidth
limit is trivially broken. So, like I mentioned before, but experience
is making clearer, the limit is more or less obeyed, UNTIL my
isp-connection gets swamped (by other activities). I would handwave
that because freenet is competing for the small pipe, which would cause
packets to take longer to arrive / not arrive at all, it becomes
heuristically more aggressive, somehow, and (arguably more seriously)
even when the pipe clears up a bit, remains aggressive.

Fix!
___
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 1334

2011-01-20 Thread David ‘Bombe’ Roden
On Thursday 20 January 2011 18:24:15 Dennis Nezic wrote:

 Fix!

Please refrain from bossing us around. You are not in a position to do that.


David


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 1334

2011-01-20 Thread Dennis Nezic
On Thu, 20 Jan 2011 20:28:24 +0100, David ‘Bombe’ Roden wrote:
 On Thursday 20 January 2011 18:24:15 Dennis Nezic wrote:
 
  Fix!
 
 Please refrain from bossing us around. You are not in a position to
 do that.

Please refrain from mis-interpreting my words. (There is such a thing
as 'c-o-n-t-e-x-t', eh?) (Perhaps acquire a sense of humor while you're
at it.)
___
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 1334

2011-01-20 Thread David ‘Bombe’ Roden
On Thursday 20 January 2011 20:32:30 Dennis Nezic wrote:

   Fix!
  Please refrain from bossing us around. You are not in a position to
  do that.
 Please refrain from mis-interpreting my words. (There is such a thing
 as 'c-o-n-t-e-x-t', eh?) (Perhaps acquire a sense of humor while you're
 at it.)

The context here would be three messages in which you are ranting about how 
Freenet does not manage to do a “simple thing” like bandwidth limiting and how 
it sucks and get worse all the time, ending all messages with the command 
“Fix!”. And though I can assure you that nothing is wrong with my humor, I 
fail to see anything funny in behaving like you specifically were the person 
Freenet has been developed for.


David


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