On Thursday 24 January 2008 18:36, Robert Hailey wrote:
>
> 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
>
We take the median of the average ping time for each node. Then we smooth it
over a bit over time.
> And because of the calculation both remote and local requests were
> being rejected.
I don't see how this is possible.
>
> 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.
Does it? The average ping time is a reliable indicator of the node being
severely overloaded on CPU, network or some other vital resource.
> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080124/6c8b33df/attachment.pgp>
