Re: Notes... The case for an open client
Elektron <elektron_rc5-FFYn/[email protected]> Mon, 16 Aug 2004 03:19:44 +0800
| Newsgroups | gmane.comp.distributed-net.hardware |
|---|---|
| Message-ID | <[email protected]> |
> Or implement a simple database of which keys have been searched, and > how > using a redundant 3 or 4 deep 256 way tree in peer to peer mode with > network centric "geographic" tiers based on routing distance/topology. > With 150GB disks, it's not that expensive to maintain a few hundred > megabyte flat ascii file which is appended to by update messages from > local peers, and periodically sorted, uniq'd, and updates propagated > back out to peers. > > It takes a pretty small DNS server hack to setup the initial contact > points, and modest effort to establish a redundant interconnection > graph, > everything else can be cron driven perl/shell scripts. And you have to trust that everyone else isn't lying about blocks that they're searching. And huge ASCII files are a horror to parse. >> With projects handling 64 bits at a time that leaves 8 bits or 256 >> blocks for projects to pick from. Coordination of these assignments >> can >> easily be handled by the projects publicly declaring which blocks >> they've done, the block they are currently processing and the next >> block they plan to work. > > Why so coarse when a modest sized file allows several orders better > granularity? Because there aren't 256 big projects yet. - Purr _______________________________________________ Hardware mailing list Hardware-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected] http://lists.distributed.net/mailman/listinfo/hardware