On Jan 22, 2008, at 4:18 PM, Matthew Toseland wrote:
> On Tuesday 22 January 2008 21:43, Robert Hailey wrote:
>>
>> I have tested it, in the little simulator (20 nodes) and am running
>> this on my node now. The simulator works fine (CHK), my node has
>> locked up once with pInstantReject=100%{Outputbandwidth liability},
>> but I am not sure if it was running pre or post r17192 (forgot to set
>> this.status), so I just restarted it. Given the nature of r17192, the
>> symptoms make sense (thinking that every request is a failure for
>> byte
>> logging).
>
> Can you elaborate on this? Output bandwidth liability assumes every
> request
> will be successful and then works out how many requests we can
> accept on that
> basis. I have reports from several sources of problems with 1101 and
> later
> getting pInstantReject=100%, low bandwidth usage, ... :(
>
> We need to fix this before releasing alpha 2 - if it is in fact a
> real bug.
>
> https://bugs.freenetproject.org/view.php?id=2006
Ok. I think I found it (by accident... but I'll take it).
This time {SUB_MAX_PING/MAX_PING} as the reasons. Examining the source
I find that the reject is always computed as an average across all
nodes.
Usually that's fine, but one of my opennet peers was CRAZY SLOW: 92B/
sec delay 11129ms (RTT 16347ms window 1.4688538312911987
And because of the calculation both remote and local requests were
being rejected.
Since this appears to be exploitable as a DoS, I have changed the
calculation to be based on the source (or average if a local request)
[r17235], which makes more sense to me anyway. To the best of my
knowledge this will allow normal operation with a CRAZY SLOW PEER, and
will backoff that peer (e.g. on request timeouts which are certain if
round trip > 16 seconds as in this case). To help this further, I've
added sendSync() timing out as a potential backoff reason (r17236).
For the time being I'm sure that will fix remote requests, but I'm not
sure about local requests. As they still use the average, local
requests will have to wait until that peer is backed off (and thus
discluded from the average). Is this acceptable, or is there a better
solution?
--
Robert Hailey
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080124/b5782088/attachment.html>
