Ok that "example" I had with TCP.. just forget about it, it was a bad example.
/Gabriel ----- Original Message ----- From: "Gabriel K" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, August 04, 2003 11:20 AM Subject: Re: [Tech] freenet not suited for sharing large data > > ----- 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 _______________________________________________ Tech mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/tech
