First of all, sorry for the latency.
> After spending some time debating how to implement a client API > for ULPRs, I propose the following: > > Every key queued by the client layer (from FCP or other sources), will be > tried at most N times every M minutes. N is configurable, but M is not > (well it could be configurable per node but not per request). I suggest a > default N of 3 and M of 30. At the moment, if a key is queued at > MaxRetries=-1, and no other keys are queued, it will be retried forever > every few seconds. > > This eliminates the need to have any other FCP API for ULPRs: all a polling > client writer needs to do is request the key with MaxRetries=-1, and > Freenet will request it every so often, unless the client disconnects. > Obviously we would need a way to kill a non-persistent request as well, but > that's not difficult. > > The basic problem here is that ULPRs may find the key at a time when the > client is not actually requesting it i.e. between explicit polling. We need > the node to know that the client wants the key. > > Do we need an explicit subscribe-without-requesting message, or would the > above be sufficient? Even with the above, if a client asked explicitly for > an update, the client could cancel the request and start a new one. Also, a > subscription without a request is of very limited value: no node will know > we want it unless we request it. > Yes, I think an explicit subscribe-without-requesting message would be useful. Because I can't imagine myself starting requests on all the indexes or on all the trust lists of the WoT I'm implementing. At the moment, I will use SubscribeUSK (with DontPoll=true), but I think a more general message (able to work on KSK etc using ULPRs) would be nice. Also, I would like to know, how many ULPRs can be started without making troubles do you think ? ~100 ? I ask that because an index tree can contain many hundred of indexes if the user just add all the indexes [s]he can find (I have a Thaw with more than 600 indexes). > Please read my other mail for details on ULPRs and failure tables. > > Internal implementation details: > > The reason M is fixed is that it makes the data structures very easy and > low overhead. If M is variable, we need a full tree, and it needs to be far > more memory efficient than java.util.TreeMap. But if we have a fixed M, we > can just use a sorted (circular) array, since we only ever add to the end, > remove from the beginning, and very rarely remove from the middle (in which > case we can remember the time to look for in another structure and do a > binary search to find the item to delete). > > The ULPRs code remembers which nodes have recently requested a specific > key; the length of time it remembers it for is currently 1 hour, but this > can be negotiated. Longer equals faster propagation at the cost of > obviously slightly weaker security. This is why I suggest a 30 minute > cooldown. -- Jerome Flesch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080213/5b9b01b5/attachment.pgp>
