> -----Ursprüngliche Nachricht-----
> Von: "Matthew Toseland" <[email protected]>
> Gesendet: 09.04.09 00:28:48
> An: Discussion of development issues <[email protected]>
> Betreff: [freenet-dev] Client apps limiting load in bad ways
> 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?).
yes. the code 'emulates' a (passive)request with short timeout (a few minutes)
;)
while (currenttime() < timeout) {
sendrequest();
if sucess break;
wait(500);
}
>
> 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?
If everybody is listen a key with DontFetch=True, the key/data will be known
along the regular insert chain,
but how is this further spreaded?
MfG
saces
__________________________________________________________________________
Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und viele
ausländische Netze zum gleichen Preis!
https://produkte.web.de/webde_sms/sms
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
