On Sun, 17 Feb 2002, Ian Clarke wrote: I want to first off thank you for replying to my email.
Let me first off say that my network may use some of the ideas of freenet but I never said it will be based on freenet. > On Mon, Feb 18, 2002 at 01:31:02AM -0500, Kevin Atkinson wrote: > > *) Focus more on speed and scalability than anonymity. The goal of > > DistribNet is to be as fast or faster than the Web for any sort of > > pages with reasonable popularity. > > Certainly, by removing a lot of the crypto in Freenet, you could probably come > up with a system that is faster, but Freenet's underlying protocol has log(n) > scalability which is probably as good as you could hope for in any such > system. My advice is to stick with the underlying protocol to get its > scalability, and adaptiveness, just strip out the crypto. I believe that through clever routing and constant communication between nodes any node should be able to get to what ever data they want by only contacting a few carefully selected nodes. Popular data will be able to be retrieved by only contacting one or two nodes. > > *) Will allow anyone to anonymously post content to the network > > You can't have it both ways. If you get rid of the crypto, you lose the > anonymity. Not necessary. When node A sends an upload request to node B node B has no idea if the data originally came from node A or if node A was sending the request on behalf of another node. Thus the true origin of the data is unknown. > > *) The ability for one to share content that is on one's hard drive > > or be able to fetch content from the Web or other networks when it > > is more effect to do so. > > Again, the reason that you can't just share stuff on your hard disk is that > nobody else will be able to find it without using some kind of inefficient > gnutella-style search. I believe that you can by having nodes occasionally broadcasting whats on there node with several other carefully selected nodes which in turn broadcast the information to other nodes. Before long the entire network will know about what's on your hard drive. Every node does not have to know what on every other node but they need to know how to find it. > > Query for keys will be handled similar to freenet but instead of > > returning the actual data a pointer to the node which can easily > > provide the data is returned. > > What if that node goes down? What if its connection is slow? What if its > data is so popular that the node goes down? What if the data is available > from multiple nodes? Instead of just returning a single node a list of possible nodes is selected. From that list the best possible node is selected and tried. If that node refuses (for what ever the reason) the next possible node is selected. It will also be possible to try several nodes at once by downloading different parts of the file. If one of the nodes tried is being really slow it will be dropped and another node will be tried. Nodes will be selected based on network distance, speed, and reliability. > You should stick to Freenet's caching algorithms, they are essential to > Freenet's scalability and robustness. If you don't care about those, > then you shouldn't try to claim that your architecture is based on > Freenet, since you will be throwing out most of what is valuable about > the Freenet architecture. I never said it would be based on Freenet. Just similar to it. The problem I see with freenet's caching algorithm is that by having to route data through other nodes it takes a long time for not-so popular content to be retrieved. Although I didn't say it before I envision my network working by nodes in constant communication with each other so that every node has a good idea of what's on the network. My original implementation will be based on every node knowing what's own every other node. After I get that working I plan on adding fancy routing so that nodes won't actually store the contents of every other node but will be able to know which nodes to content in order to find a particular key. They were be lots of redundancy in the routing so that the network will continue to function even if parts of it go down. I also believe that by simply transferring data from one node to another a lot of the benefits of freenet's caching algorithm can be retained. Because, once node A transfers a key from node B nodes close to A (say B,C,D) can transfer data from node A instead of having to download it from node S which is farther away. If node A is inaccessible to node B,C,D for some reason this scheme will still work because once node B downloads the data nodes C and D can transfer it from node B. The more nodes that download the data the less chance there is that *all* off them will be inaccessible to other nodes. However, if for some reason nodes A,B,C,D and completely inaccessible to other nodes, node S will notice that it is getting a large number of requested from far away and will upload the data to some other nodes which are closer to the origin of the requests. I don't mean to belittle your network as it gave me the original idea. I just think better performance can be obtained by clever routing of queries and direct communication between nodes when transferring data. --- http://kevin.atkinson.dhs.org _______________________________________________ freenet-tech mailing list [EMAIL PROTECTED] http://lists.freenetproject.org/mailman/listinfo/tech
