> > My solution to the problem of storing the key types with the keys > > is to store the different types of keys in different tables. So > > Request.Data looks in the KHK table, Request.Data.ContentHash looks > > in the CHK table (or generates it if the node doesn`t bother to > > precalculate CHKs for some reason, like no one in that node cluster > > uses them) and so on. No problems with key collisions. > > No, Oskar's right that it's much better for the network if "closeness" > compares all keys, but only returns "equal" if types match: that gives > us the best clustering and still only fetches the right Documents.
Key collisions aren't a problem if you keep them in different tables. Getting the right document isn't a problem if the different message types look in the different tables. Clustering works the same as before. True, if a KHK and a CHK are the same value they will go to the same node, but that isn't important since they will be unrelated so whether they end up on the same node or not isn't important. Actually, they'd only be the same if the key for the first was equal to the data of the second, which would be silly. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
