[freenet-dev] FCP changes for ULPRs

[Matthew Toseland]

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 : http://emu.freenetproject.org/pipermail/devl/attachments/20080207/806fd1da/attachment.pgp