>
> > 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.
>
> This is the same hole as exists in Oskar's argument - just how is a
> particular piece of data determined to be the latest version without
> actually doing a full follow-through search?
No, you are still doing the full followthrough, its just that *no data
comes from the node that was at the end of htl*. Its the equivalent of a
quick "What ver do you have? Oh, really? Then I'll just get it from ny
neighbor"
>
> This won't happen since a node will drop an update for data which has
> already been updated. Updates also will only be propogated by nodes
> which are locally caching the data, further preventing any form of
> "virus". Lastly, HTLs will also act as a final (but probably
> unnescessary) safety mechanism.
Okay, but then you're terminating the explosion before it reaches
everyone. Second, a cancerous node can reset the HTL, keeping the
explosion going forever.
> This doesn't make sense. How will the requestor do anything if it can't
> find the updated data, or (even more likely) the one, or small number,
> of nodes with the updated data have been killed by the /. effect of all
> these follow-through requests.
If it couldn't find the updated data, then it couldn't find the original.
> What is wrong with a network spike, the spike will be distributed over
> the entire Internet, meaning that it will be distributed in space, if
> not time.
Sure, but I really don't like the traffic-analysis implications of any
sort of event that is triggered by one node but has an effect on the
entire network.
> > 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.
>
> Perhaps, I am not very wedded to the idea of expiration, although I am
> not convinced it is bad either so long as the author of the data knows
> what they are doing when they set the expiration flag.
We're building a system to circumvent the bad parts of human nature
(tendency to err, tendency to meddle), why build in bits that rely on
humans to behave well?
Scott
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
