-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 
> In this case the number of extra messages generated by the update would be
> relative to the number of people requesting the data, which is exactly what 
> the
> number of places that the data is cached in is relative to.
This sounds fairly sensible.  I don't think its bad to have non-updated
data on Freenet.  Think of it this way:

Sometimes your htl isn't long enough to cover the net.  The data you find
might be just out of reach.  Furthermore, it might exist on only half the
net.  Its the actions of requesting that cause it to finish
propogating.  The same is true of updates.  The update is stuck locally
until someone cares (a follow-through).  The actions of users requesting
finishes the propogation.  This allows us to complete ignore updates for
non-popular data.  Otherwise, everone who does an update causes an
exponential broadcast (which I agree, in a disorganized network like
Freenet, is a bad thing).  

This is along the same lines as what I consider the better proposals for
searching.  Those that avoid broadcast, but rely instead on locality and
the standard routing to do so.

> Notice that not all requests for updatable data should be follow-throughs
> (though all InsertRequests for updates would have to follow through of
> course). One might for example tag an "update by" field in the meta-data, and
> have the client make a wager based on that. If we can get it so that the 
> number
> of follow-throughs becomes an exponential distribution restarting at every
> update, it should lead to very good and fast propogation of updates.
This fits nicely into the Browser concept of "check once per
session".  Those types of requests are follow-throughs.  

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5FwUDpXyM95IyRhURAreuAJkBv57puyinJUTHwjaSjm62OKeb/ACcCC0D
tvh7LrHs/WgF0tDCjFpsJNo=
=QyK2
-----END PGP SIGNATURE-----


_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev

Reply via email to