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?
pgp242IVTMqMu.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
