OS> It is also important, however, that a Request for one type of key OS> never return data for another type of key...[but network routing OS> should cluster different KeyTypes together]
BW> My solution is to have a different message subtype for every kind BW> of key. So there is Request.Data.ContentHash and Request.Data.Signed, BW> etc.. They will inherit from a common subclass. So the routing will BW> be the same. However, there won`t be key crossover because there is BW> a different message for requesting different types of keys. The reason BW> I prefer this to putting the key type in the message or the key itself BW> is that there is more to handling different key types than just making BW> sure they`re never equal. They are handled differently by the node. BW> ContentHash keys have the content hash of their data verified, for BW> instance. That's certainly one way to do it. I don't think that code will be much simpler than just having the KeyType in the SearchKey.X field, though. I'm happy with either. I agree with Oskar that the Closeness relation should be shared between different KeyTypes to cause them to be routed better, but that "KeyType" itself is part of the primary key for purposes of identification. I had even intended to make that part of the URI syntax when we get around to that (e.g. fnet:CH/87234...). If all CHKs, SVKs, and KHKs are just big hex numbers generated by hash functions, the using the same Closeness relation for them all should be simple, but you have to add bits to represent the KeyType, and you have to make sure to add them at the low-order end (i.e., compare by Key, then Type, not vice versa). I don't see any problems here. -- Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lcrocker.html> "All inventions or works of authorship original to me, herein and past, are placed irrevocably in the public domain, and may be used or modified for any purpose, without permission, attribution, or notification."--LDC _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
