-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > But the problem is that in this case the node, or small number of nodes, > which actually have the updated data will recieve all requests sent with > this "follow-through" flag set. Now from the users perspective they are > *always* going to want the latest version of the data, thus they are > always going to set the follow-through flag, and thus if the data is in > any-way popular (such as a Freenet version of /.) these central servers > will rapidly fall-over. Freenet will, in effect, no longer live up to > its promise of being slashdot-effect-proof. I can refute at least this part. The problem is you're thinking that the last node that the follow through request reaches is the one that winds up serving the data. This isn't true. On the way towards that eventual endpoint, the versions are checked. Its the nearest node with what is determined to be the latest version that actually returns the data. That means that the only additional load on the epi-center is a single control message.
> > If on the other hand, we try to make more nodes respond to the > DataRequest for the updated data, using the "explosion" mechanism I > propose, then a much larger number of nodes will be capable of > responding to these DataRequests (hopefully a number proportional to the > number of nodes actually caching the data), we avoid the /. effect. It still wories me to use broadcast of any sort. There is too much risk of encountering cycles in the network, causing the explosions to trigger mini-explosions, at least until the HTL runs out. Some routers will see this as a potential flood if the explosions overlap, some firewalls might try to dampen the effect, and because its controlled, using some N number of nodes to broadcast to, you're not propogating the update to all the possible interested parties. The problem is, your proposal has the updator decide what should be updated (not directly, but via the explosion). This might leave some people out. The deep-request method lets the requesters decide what should be updated.. which is how it should be... after all, they are who is interested in the recent copy. > The argument that this "explosion" of messages will swamp the network is > also incorrect - think about it. What is the ideal result of an update > (whatever the mechanism)? It is that all of the nodes currently caching > the data to be updated, will (after the update) be caching the updated > data. This means that at some point, sooner-or-later, they must recieve > the update, whether through my explosion mechanism, or through your > mechanism where the updates will be carried in DataReplies. Either way, > there is a lower-bound on the number of messages which must be sent for > a complete data-update, and this lower-bound is directly proportional to > the number of nodes caching the data. If an "explosion" is done > correctly, it should result in a number of messages being sent that is > roughly proportional to the number of nodes caching the data. Sure, but the issue is when the messages are propogated... all at once, making a nice little network spike, or over the lifetime of the data, which is a nice even increase. > > But this "make sure..." process will result in a /. effect on popular > data as I point out above. Or not, as I pointed out. > If the explosion won't work, then your proposal definitely won't work > since it results in much fewer nodes receiving the update initially. As > for too many messages, see my argument above. Yes, but it means that far more nodes will have it eventually. > > Well, disident knew what he was doing when he set the expires - he > doesn't have to do this, it is just useful because it will result in a > faster update. He could always have two versions of the data, one with > an expires, which updates quickly, and the other without, which updates > less efficiently. I hate to make sweeping judgements like this, but expiration is bad. Very bad. Attackably bad at the worst, or just annoying for content creators at the best. I happen to like Theodore's idea about constraining the possibility of a follow-through. The more automatic things are, the more likely people will use Freenet, and the less likely it is that people can screw it up. Scott -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE5Ga3ypXyM95IyRhURAuQWAKCI9wHEuujS9DqcR8Ua0vHackKe1QCfZdm3 JnBH7NcrakIEg1l+NI8dIX8= =+G0n -----END PGP SIGNATURE----- _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
