> > No, the reason why I want to use a binary tree is to do high speed > file index lookups. The reason why is that you don't have to compare > the key you are looking for with each other key for other files until > you come upon the file the key you have points to. And also, this > would greatly reduce the time spent in the worst case (which would be > searching for a nonexistant item with a plain sequential search). And like I said, this just won't work for large numbers of keys accessed on disk. Please read up on a B-tree and get back to me. You obviously don't know what one is or you'd realize that a B-tree is a generalized binary tree with the splitting level not necessarily equal to two. Its optimized for high-latency storage systems (ie disks) where you can get away with hundreds of branches per level. They both perform the same general task, that is optimizing the number of accesses before finding the key you want (or finding out if you even have that key).
> > > This depends a lot upon Freenet's topology, which depends on > > > mechanisms which nodes find out about each other through. If it takes > > > a UUCPNET type topology, you *will* have these sorts of nodes. > > > > I'm arguing that if these kinds of nodes must exist, then Freenet isn't > > doing its job. > > Well, to determine this kind of stuff, we will have to do testing and > modeling (with Serapis, of course). Sure, but one of the main design goals of Freenet is to spread data evenly across the network so that one doesnt need to rely on small numbers of high-quantity nodes. > > > happen. > > Fine. Go for it. Never said you couldn't do it, just that it really > > isn't necessary to have these monster freenet processes for freenet to > > succeed. > > Extreme cases will happen, and you should account for them even if > they are quite unlikely. Like I said, I'm not here to stop you, only to keep you from reinventing the wheel, doing stupid things, making bad assumptions, etc. I'm on your side. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20000803/5fedcb49/attachment.pgp>
