On Thursday 09 April 2009 09:22:08 VolodyA! V Anarhist wrote: > 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
Well, the normal behaviour is to fetch... -------------- 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/20090409/3b644767/attachment.pgp>
