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 [EMAIL PROTECTED] 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, <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > On Tuesday 22 January 2008 19:41, [EMAIL PROTECTED] wrote: > > > On Jan 22, 2008 8:25 PM, Matthew Toseland <[EMAIL PROTECTED]> wrote: > > > > On Tuesday 22 January 2008 18:40, [EMAIL PROTECTED] 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 > > [email protected] > > 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 __________________________________________________ _______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
