On Thursday 24 January 2008 19:46, Robert Hailey wrote: > > On Jan 24, 2008, at 12:45 PM, Matthew Toseland wrote: > > > 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. > > Well, in this case it was a reliable indication that one of our peers > maybe being overloaded (or defunct); and supposing that this node > appears consistently bad to all it's peers, then as a whole the > network does route around this node, but at one-extra-peer radius (it > does so because my node is rejecting requests in his favor).
Definition of median: line up all the numbers in order and pick the middle one. One very high or very low value therefore has no or marginal influence on a median, if the others are unchanged. So if one of your peers is severely overloaded, that should have no effect whatsoever on your pInstantReject. > > With respect to measuring CPU/network/etc. A ping average is a ping > average, you're only measuring packet ack times (and then... available > bandwidth). Think about it backwords... If an overloaded node with a > high CPU load has a high ping average, then we should not route to > them (backoff?). Not start refusing requests from our peers. > > The underlying problem might be that the ping average is a feedback > loop that can somehow be stuck ON. If a peer is marked as being super- > latent, we will not send any packets to them, and thus we can't see > that the latency is wrong. If the code is even written to such a > respect, if that peer would then want to send us anything he would be > ack'ing old packets (possibly making us think he is more latent???). We still send keepalive packets if nothing else. IIRC they contain FNPVoid's. -------------- 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/2c12f8dc/attachment.pgp>
