On Thursday 09 April 2009 10:55:10 xor wrote: > > > -----Original Message----- > > From: devl-boun...@freenetproject.org > > [mailto:devl-boun...@freenetproject.org] On Behalf Of Matthew Toseland > > Sent: Thursday, April 09, 2009 12:28 AM > > To: Discussion of development issues > > Subject: [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, > > Freetalk and WoT can do -1 because we/I can patch them right now. > This can be done for any SSK/CHK URIs which the plugins know for sure that > they exist, i.e. for messages and message lists which they obtained the URIs > of through other peoples message lists...
This is really for polling. > > However Freetalk and WoT will have to periodically try to download message > lists and trust lists of ALL identities to ensure that nothing is missed if > the propagation through third party lists does not work. Yeah... you may not want to fetch 3 times every half hour for the medium-trusted identities, but you do want to be notified of messages. Hence DontFetch=true for these identities, which means that after you try occasionally to fetch them, if they are found nearby they will be offered. > > > 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. > > The probability of such a request to succeed will be horribly low, won't it? Yes, under normal circumstances. It's a way to tell the node that we want the key, without necessarily requesting it regularly. If other nodes nearby are requesting it, we will get it, even during the periods when we are not actually fetching it. Really it's equivalent to MaxRetries=-1, but instead of having 3 fetches every half hour fetches are entirely up to the client (and other nodes). > > > > 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. > > Good idea IMHO, especially for FT/WoT. Note that ULPRs expire after 1 hour...
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
