Ian writes: > I think that the issue is that a request forwarded to the node > in-question, the chance that the DataSource (ie. the reference with > which a datastore entry will be replaced) will actually be *that* node > is quite high, in fact, it is 100% if that node is maliciously setting > all DataStore values to itself.
Let's ignore the malicious attack situation for now. I presume you don't believe that it is the cause of the reported/observed ubernode phenomenon. We should understand the cause before we propose a fix, agreed? > So every time a request is forwarded to my node, it increases the > probability that other requests will be forwarded to my node, and I can > artificially enhance this effect by setting all DataSources to my node > when I forward a DataReply. This is the positive feedback-loop I was > referring to. You're saying that for any request forwarded to your node (the ubernode), there is a good chance that the DataSource will be set to your node's address. As I understand it this is a fixed probability for every node on the request chain. As the message travels back each one may reset the DataSource to itself, right? I don't see why this should cause positive feedback. While an ubernode can reset the DataSource to itself, other nodes can too. If the ubernode was the first one in the request chain, then it is the last one to see the data as it travels back, so if it sets the DataSource to itself, that will "stick". But if it is not the first one in the chain, then as the data travels back, other nodes may reset the DataSource to themselves even after the ubernode has set it. Mathematically I can't see how this would benefit some nodes at the expense of others. It seems very symmetrical. I haven't analyzed it in detail, but if we imagine that the probability of setting the DataSource to itself is 1, then this is exactly the case I analyzed in my earlier message. X% of the messages go to the ubernode, but this is compensated by the fact that X% of dropped messages were pointing to the ubernode, and so X does not increase. Do you have a mathematical model which shows positive feedback behavior? Back when I was running a node, I observed the ubernode phenomenon. My datastore pointed to fewer and fewer nodes until it was pointing at only one or two. At the time I had a specific hypothesis for what was happening, but I did not have time to validate it. My theory was that nodes were being dropped because they did not respond quickly enough. The node software has timeouts and if other nodes don't respond, they are removed from the list. Due to vagaries of network timing it seemed that many nodes occasionally failed this test and were eliminated. The ubernodes then were the ones with exceptionally good connectivity and performance, or perhaps ones which were located very close to me in the network. They were the ones which never timed out. So over time they came to occupy a larger and larger fraction of my node's key space. You'll notice that my hypothesis is completely different from yours. And in particular, the proposed fix of allowing only one reference to a particular node would not help. It would not stop other nodes from being dropped. The ubernode could not expand its number of references to make up for those lost, so we would end up with almost all the keys in the DataStore with no references, and ultimately only one key with a reference. This "fix" might end up making things worse. Now, I don't know if my theory is right; as I said, I did not have time to do the experiments necessary. But the point is that without a theory about the cause of the problem, we can't fix it. Limiting the number of references is a band-aid. It affects the symptom, but possibly not the cause. We need to understand the cause. Hal _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
