----- Original Message ----- From: "Tom Kaitchuck" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, August 04, 2003 6:03 AM Subject: Re: [Tech] freenet not suited for sharing large data
> OK, I think all confusion comes down to one simple issue. Yes, you can protect > both the senders anonymity when requesting/sending a request or insert using > the mixnet poxing approach. However you can't prevent neighboring nodes from > knowing the holder of the data. Yes this is exactly what it all boils down to I guess, glad you brought it up :) Now, I don't agree that for any given protocol your statement above is true. It all depends on the design of the network. > Think about it like this: You have to route your request for data to the node > that has the data. How do you do that. > A. Just broadcast your request to everyone. > Doesn't scale. In DC you broadcast your request to everyone. But a better approach is to organize the search like chord does I think. Anyway, let's say it would be possible for a node to send a request to another neighbour, which passes it on, and in time the request forks, so that the requester doesn't have to wait for the message to pass ALL nodes. And even though it forks, and the same request is asked simultainiously, there are NO looping problems. A node only recieves the messages once. I would say that scales, would you? > B. Have a centrial server to keep track of it for you. > Centralized, and vulnerable to attack. Modification: you can have a central server making decisions for the network and individual nodes, and STILL it can be safe from attack IF no node knows its IP adress! It is VERY practical to have such an authority that every nodes trusts and obeys. If they trust ONE instance, this makes it a lot easier to solve many problems, because you avoid scaleability problems with voting processes (many times, if ONE any node can decide on it's own, that power can be abused) . > C. Use some sort of predefined routing scheme, where it is determined in > advance which node holds which data. > The holder any given piece of data can easily be determined. This COULD be solved by letting the "hidden" central server take care of such things, but it is better to put as much work as possible on nodes, to relieve the importance and load on the central point (if there is one). This is also why I think it's good to leave the data at the nodes that holds them from the beginning. No sorting into the network, and no extra store space on each node for someone elses files. You only are responsible for the stuff you WANT yourself. > D. Use an algorithm that learns form past requests. > Freenet uses this scheme. > > CHORD uses C. IMHO a better implementation of C is the Grapevine project. If > you are doing C you have the option of returning the data directly. However > most implinentations don't because the other nodes have no way of knowing > whether or not the node that was supposed to actually did, or is malicious. > Using D you cannot, because nodes need to find out whether or not the data > was where they thought it would be. You can't just trust the node to tell you > whether or not they sent the data. Since the intermediate nodes don't know > what the data is, nothing short of showing them the data is sufficient proof > that you were able to locate it, and that it was returned to the requester. Umm, you are talking about that the HOLDER of the data is malicious and doesn't send the data? I would say there is no defense against that attack. That is also why it's good to just leave the data at the node that introduced it to the network. If THAT node is malicious, it might not even join the network and share it's data! The only harm in saying it shares data and then not sending it, is that a requester gets his hopes up and then gets very very sad :) Of course you can't force a malicious node to send you data. Hey, I can ask my friend to send me a tune, and if he sends me some other tune I didn't request, there is nothing I can do about it except ask him nicely! :) > From the performance perspective, it's true it does incur overhead. However > this is only over the whole network, not for any individual user. So each > user gets a download rate equal to their maximum network throughput under > peek demand. However supposing the network averages using 10 hops and the > load balancing works well, the total network cannot be receiving with more > than 1/10th of it's TOTAL bandwidth at any given time. This is not a problem, > because under most circomstances this is not the case. Yes, this prevents > dial-up users form contributing to the network, but for Broadband it's a non > issue. A 128k link can transmit a theoretical 10.8GB a day. Show me someone > who has a 128k link and AVERAGES downloading more than 1GB a day, and I'll > show you someone who needs a faster connection. Sure you could change it from > aveaging 10 hops to 5 hops, but then you cut the rate that nodes learn in > half. Well, you are assuming users are active spread equal throughout the day... I say that it is likely that networks will form where most users are from a specific region in the worlds, for instance scandinavia. So their activity will have it's peak at some time. And at this time I think it's not hard to reach the limit! Anyway, you are missing the point here... Sure, they might not reach this limit, BUT the PROTOCOL should not require so much BW! Maybe a user doesn't only want to use freeNet. Maybe he runs DirectConnect as well while doing other stuff that requires some BW... It's like saying "well it's ok that TCP has lots of overhead, people don't use their full amount of bandwitdh anyway!". Do you see what I'm trying to say? :) > It would be nice to find the optimum value, but there is no way to do > that on the existing network. (only in simulation.) Not in freeNet... and that's why I think it's not suited for large file transfers.. at least not with the level of activity I think one should assume when writing a protocol. /Gabriel _______________________________________________ Tech mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/tech
