[Top][All Lists]

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

Re: [GNUnet-developers] About collections

From: Christian Grothoff
Subject: Re: [GNUnet-developers] About collections
Date: Mon, 15 Nov 2004 12:21:00 -0500
User-agent: KMail/1.7.1

On Monday 15 November 2004 05:27, Igor Wronsky wrote:
> I just noticed the collection concept. After looking
> for a moment at the code, I got the impression that
> it runs on sporadic sblocks. While inserting, a
> nextId is generated, which is used to identify the
> next update and so on. If this is so, it seems
> to inherit the weakness of the sporadic inserts,
> that is, one lost link in the chain and the
> collection is done for?
> Correct me if I'm wrong. I couldn't find much about
> these background technical issues in the docs.

So I guess I should just shut up, since in my opinion everything you're saying 
is absolutely correct? :-)

> In addition, the republished nblock doesn't seem
> to be updated to reflect the nextId, so that it
> doesn't safeguard the chain either. Again, sorry if
> I'm wrong. But if this is so, I understand why we
> don't update it, as that'd cause some serious extra
> pollution to the namespace adverts channel,
> especially with big collections.

Right.  Now, we could theoretically keep track of the length of the chain and 
just do an update after every 10 additions.  That would balance things 
slightly, but it is of course not a good solution (or at least: what you 
suggest below is better :-).

> In possible future protocol change this could
> be fixed somewhat if we had a special type of blocks
> that has gnunetd readable, but immutable and
> verifiable plaintext fields. With this, we
> could put a collection serial number visible
> to the nblock, and make gnunetd, when seeing
> this type of block, retain only the newest
> entry. As this is done for an advertisement,
> I don't think it would bother to users to
> find only the latest entry. Even if the sblock
> chain would break, finding a new advertisement
> would get the users back on track.

Right.  But as you said, it could only be done by changing the protocol. For 
this version, my goal was to just introduce the idea (with a working but far 
from perfect implementation) and try to see if people would find it useful. 

> Just my 0.127 cents,


reply via email to

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