On Sun, Jan 29, 2006 at 11:53:35AM +0200, Jusa Saari wrote:
> On Thu, 26 Jan 2006 01:41:59 +0000, Matthew Toseland wrote:
>
> > Possible FCP options on a ClientGet:
> >
> > offline=true // keep going after this connection closes persist=false //
> > don't keep going after the node is restarted remember=false // don't
> > remember after completed => won't show up on
> > ListRecentlyCompleted (only valid if offline=true)
>
> What happens if someone sets offline=false and persist=true ?-)
Then they get a protocol error? It isn't ideal, yeah...
>
> It would be better to have a single "persistance" option, with options of
> "online" (keep on going until the connection closes), "reboot" (keep on
> going until the node is restarted) and "forever" (keep on going after node
> is restarted). Having two persistance options ("offline" and "persist") is
> confusing and opens possibility for bugs that simply can't exist with a
> single option.
Okay, so Persistence=:
Online = Request tied to a connection. If the connection is closed, drop
the request. Requests kept in RAM only, and ephemerally encrypted temp
buckets.
Reboot = Request tied to a client Name (these must be unique). If when
the request completes, there is a connection to the named client, return
the result immediately over that connection. If it is not, then remember
the result (subject to time without seeing client and size limits).
Requests kept in RAM only, and ephemerally encrypted temp buckets.
Forever = Request still tied to client Name, but persist across reboots,
because they are recorded to disk.
Prefetch = Request kept in RAM only, not tied to a connection OR a Name.
Nobody will be notified when it completes.
I think if a prefetch is so important that it must persist across a
reboot, it is reasonable that the client may want to be notified, so
probably we don't need a prefetch-but-persist-across-reboots option.
We do need a flag to indicate that we don't want the data (on a
request), but that is a matter for ReturnType.
DoNotReturnData=true => don't return data to client.
> For that matter, you could simply have an option to persist until the
> specified time, no matter how many times the node is restarted:
> "persistance=123456789", where the number would simply be the time in
> milliseconds since midnight, January 1, 1970 UTC
> (System.currentTimeMillis(), in other words). Simple and completely
> unambigious.
Dangerous though. If a request does not need to persist across a reboot,
then it **should not be written to disk**. An optional time after which
a request can be dropped isn't a bad idea though.
>
> After all, if the client wants to have the request persist after it
> disconnects from the node, why should it care if the node gets rebooted
> between the disconnect and the next connection ?
Because if it is written to disk, then it is recoverable by a Bad Guy.
>
> So, I propose that there's a single option, "persistance" (or
> "persistuntil", whichever you think is clearer), which accepts either the
> option "connection" to persist until the connection is severed (the
> default), or the date it should persist until, in the "milliseconds since
> midnight Janurary 1 1979 UTC". Examples:
>
> persistance=connection
> persistance=123456789
>
> Coming to think of it, if "connection" is the default, then there's no
> reason why "persistance" should accept it - just leave the option off
> completely if you want the default behavior.
Generally it's a good idea to be able to explicitly specify these
things.
--
Matthew J Toseland - toad at amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/tech/attachments/20060130/175dbd31/attachment.pgp>
