gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-developers] How do updates work?


From: Kenneth Almquist
Subject: [GNUnet-developers] How do updates work?
Date: Wed, 5 Aug 2009 19:01:41 -0400

I've been trying to understand how namespaces are supposed to support
updates.

As I understand it, a namespace advertisement contains a string called
the root, which can be used in a namespace search.  A result of a
search of a namespace may contain a string which can be used for a
subsequent search, and it looks like the search code will initiate
a search using this string automatically.

Thus one could post a file under the keyword A with next_id set
to B, and subsequently publish a file under keyword B with next_id
set to C, and finally publish a file under keyword C.  This would
allow someone to find all three files using repeated searches starting
with A.  The question is:  how does this differ from publishing all
three files under the keyword A?  In terms of speed, a single search
for A is likely to be faster than performing a series of searches
starting with A.  In terms of completeness, the answer is less clear.
Possibly a chain of searches would be more likely to locate all the
files, because each search only has to produce one result.  On the
other hand, a single failed search in the middle of chain means that
none of the files in the rest of the chain will be found, so I would
suspect that the odds of the search finding *most* of the files would
be higher with a single keyword search than with a chain once the
chain reached a certain length.

If the above mechanism provides a way to perform updates, I don't see
it.  When the ECRS paper states that, "since SBlocks are signed, it
is possible to allow updates," the point is that updating an existing
file involves deleting the old version, so we want the originator of
the content to be able to do that, without allowing anyone else to do
so.  A scheme to do this might work as follows:

Allow an SBlock to include a 16 bit version number.  (For backward
compatibility, the version number is optional, and an omitted version
number is equivalent to a version number of zero.)  The rules for
dealing with version numbers are:

1)  Any time a host sees an SBlock with a given version number, it
    gets rid of versions of the SBlock with lower version numbers.

2)  A host does not earn trust for supplying an obsolete version.
    This means that if a host is doing a search, gets one version
    of an SBlock, and then receives a later version, it should
    revoke the trust credited to the host that provided the older
    version and give it to the host that provided the newer
    version.  This rule means that there is no incentive for
    hosts to keep old versions around.

3)  If a host receives an obsolete version of an SBlock, it can
    request a refund of the trust expended on the search by
    sending a more recent version of the SBlock.  This requires
    a new message type.  This rule means that hosts which have
    cached obsolete SBlocks are likely to be provided with updated
    versions of those SBlocks.  (Otherwise, a host might cache
    an obsolete version of an SBlock indefinitely, since it would
    receive periodic search requests that matched it.)

To allow a user with a given version of a file to see if a more recent
version of the file exists, we need a variant of the keyword search
which specifies the minimum version number that is being searched for.
It would be conceptually simplest to say that a search with a version
number of N would return any version greater than or equal to N.  To
allow for reasonably efficent Bloomfield filtering, I would suggest
that a search specifying version number 0 should query the data base
for any version of the file, and a search with a nonzero version
number N should query for versions N through at least N+4.

Versioning only applies to search records.  Since DBlocks and IBlocks
may be shared by different files, I don't see any way to explicitly
get rid of the IBlocks and DBlocks from an obsolete version of a file.
Once the obsolete version of the file no longer shows up in searches,
there will be no more requests for the IBlocks and DBocks (unless
they are, in fact, shared by a different file), and they can be pushed
out of caches to make space for blocks thare are being requested.



Get free photo software from Windows Live Click here.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]