[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,
Christian