-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew Toseland wrote: > FMS does bad things to limit load: Rather than queueing every key at > MaxRetries=-1, it does all the scheduling itself, doing simple ClientGet's > with no maxretries and no priority (hence prio 2), in order to enforce a > maximum number of parallel requests. Other client apps probably do similar > things. MiniChat presumably does the opposite, constantly requesting keys, > starting a new request for the same key when the last one has finished > (saces: is this true?). > > The reason that FMS's behaviour is a problem is that ULPRs rely on nodes > knowing which keys they are interested in. ULPRs are the main network level > optimisation for SSK polling/chat/WoT apps, so this is potentially a big > source of problems - excessive load, slow propagation of messages etc. > > Possible solutions: > > DontFetch=true : if set, a request would be purely passive: no requests would
A minor point probably, but is it at all possible not to use negative there? It sometimes make FCPv2 standard harder to follow: DontFailToNotFetch=false takes a few extra seconds to figure out than Fetch=true > be started as a result of that request, but the node would know it wants > those blocks, and if the blocks do come in, the request would progress. > Suggested usage is that a client app would set up DontFetch requests for > everything it is interested in, with Verbosity sufficiently high, and then > poll using whatever load heuristics they want. When a block (typically an SSK > block when polling SSK outqueues) is found, either the request succeeds, > fatally fails, or it is a redirect. If it is a redirect, the client would get > a SimpleProgress and would schedule a normal request to fetch the rest of the > key. (This should be fairly easy to implement) > > Client configurable cooldown: Running a request with MaxRetries=-1 means > fetching it 3 times every half hour. We could make the half hour bit > configurable, and maybe the 3 times too. Note that it is quite likely that we > will eventually impose network level limits on polling (e.g. using > RecentlyFailed), so setting this low will not necessarily (in the long run) > yield better performance. (This should be moderately easy to implement) > > Any other ideas? Is this the right approach? IMHO we can implement whatever > API fairly easily, but maybe there are some other ideas? > > > ------------------------------------------------------------------------ > > _______________________________________________ > Devl mailing list > Devl@freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl - -- http://freedom.libsyn.com/ Echo of Freedom, Radical Podcast http://eng.anarchopedia.org/ Anarchopedia, A Free Knowledge Portal http://www.freedomporn.org/ Freedom Porn, anarchist and activist smut "None of us are free until all of us are free." ~ Mihail Bakunin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkndsCwACgkQuWy2EFICg+05NACfR91vYCW2StcpNFC/6FTlYrro j9cAoLqQ7apxP3XLP2CBOW8vYRciOkZx =dJXO -----END PGP SIGNATURE----- _______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
