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 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? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090408/08e35e0d/attachment.pgp>
