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. 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080207/806fd1da/attachment.pgp>
