FYI: Stats from my Frost running for appr. 18 hours. nodeTime is the time that Frost wait after starting a request until the request finished. Its the sum of all update thread wait times. Maybe it would help if we would be able to retrieve a KSK without to retrieve the underlying CHK. Then we could check the underlying CHK at .... key if we already know this key. In this case we could choose to not to retrieve the CHK and therefore stop pushing the request stats for this CHK? I don't know if this makes any sense.
Summary for current session: *** Today (2008.1.26) *** nodeTime: 0d 13:54:39 (15,74 s/req) countTriedIndices : 3181 countADNF : 628 (19,74%) countDNF : 27 (0,85%) countInvalid: 2524 (79,35%) countValid : 2 (0,06%) *** Overall *** nodeTime: 4d 01:37:50 (15,84 s/req) countTriedIndices : 22183 countADNF : 3196 (14,41%) countDNF : 281 (1,27%) countInvalid: 18686 (84,24%) countValid : 20 (0,09%) On Jan 24, 2008 7:37 PM, <bbackde at googlemail.com> wrote: > In the meantime I think the lots of ADNF where caused by the slow > node. With 1103 it became much better, now I see alot of invalid > messages again: > > Board: frost > Date : 2008.1.24 > > Informations for current session: > > nodeTime: 00:46:31 (5,7 s/req) > > countTriedIndices : 490 > currentIndex : 517 > maxIndex : 517 > maxSuccessfulIndex: -1 > > countADNF : 7 (1,43%) > countDNF : 3 (0,61%) > countInvalid: 480 (97,96%) > countValid : 0 (0%) > > > > On Jan 22, 2008 9:07 PM, Matthew Toseland <toad at amphibian.dyndns.org> > wrote: > > On Tuesday 22 January 2008 19:41, bbackde at googlemail.com wrote: > > > On Jan 22, 2008 8:25 PM, Matthew Toseland <toad at amphibian.dyndns.org> > > > wrote: > > > > On Tuesday 22 January 2008 18:40, bbackde at googlemail.com wrote: > > > > > If Frost receives ALL_DATA_NOT_FOUND, it keeps retrying this index > > > > > during next board updates. > > > > > But the current DoS attack uses many ADNF, and together with the > > > > > backload (days to download backward) > > > > > it takes ages until a board completes to update. > > > > > > > > I thought he was pointing them to a GIF / some evil content he inserted > > block > > > > by block... > > > > > > He lately switched to 'redirects to nowhere'. This is what I get from > > > the node. >90% ADNF. > > > > That's interesting, it means he hasn't yet figured out how to redirect each > > post to a single key within a target splitfile - or he doesn't want to fill > > up our datastores with any specific content. > > > > > > > > > > My question is: what is a good way to re-request keys that got an > > > > > ADNF? Try it exactly X times, > > > > > or keep it trying if we request keys for today, but don't try them > > > > > again if we download messages for > > > > > previous days, or what? I know, in theory those keys could finally > > > > > arrive after weeks, so what logic should > > > > > we use? > > > > > > > > Try it at some point in the vague future I suppose was the original > > > > idea. > > You > > > > could set max retries to 3 and never retry on ADNF, if the messages are > > > > reasonably expendable. > > > > > > "if the messages are reasonably expendable." ??? > > > > Plainly retrying slightly increases the chances of fetching a valid message. > > It's a tradeoff. > > > > > > > > bback. > > > > > _______________________________________________ > > Devl mailing list > > Devl at freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > > > -- > __________________________________________________ > GnuPG key: (0x48DBFA8A) > Keyserver: pgpkeys.pca.dfn.de > Fingerprint: > 477D F057 1BD4 1AE7 8A54 8679 6690 E2EC 48DB FA8A > __________________________________________________ > -- __________________________________________________ GnuPG key: (0x48DBFA8A) Keyserver: pgpkeys.pca.dfn.de Fingerprint: 477D F057 1BD4 1AE7 8A54 8679 6690 E2EC 48DB FA8A __________________________________________________
