On Sat, Jun 16, 2001 at 07:11:04PM -0700, Ian Clarke wrote: > On Sun, Jun 17, 2001 at 12:15:48AM +0200, Oskar Sandberg wrote: > > > Yes but the current choice of relationship between the time anticipated > > > for retrieval of a particular message and the HTL is arbitrary. We know > > > that the network retrieves information in logarithmic time, but our > > > decisions as for when to decrement the HTL, and by how much, were > > > arbitrary. > > > > Umm, what? I don't have a clue what you mean by the above paragraph > > (seriously). > > You, serious? First time for everything ;-) > > When a node forwards a message, it estimates the time required for a > reply based on the HTL of the forwarded message. As far as I am aware, > this calculation is based on guesswork. Your argument against > increasing the HTL was, at least partially, based on your concern that > a larger HTL would result in nodes waiting for ages for a response, yet > this fact is purely a result of the arbitrary decision as to the > relationship between HTL and the time estimate for a response.
There is no guesswork involved. What we do is place a 90% confidence interval (check your nearest statistics book) around the expected time to reply, meaning that we chose a time so that we get 10% false positives (restarting when it is actually just slow). In fact 90% is a bit low, I would preffer moving it up to 95% or 97.5%, which means waiting longer. Increasing the HTL on the message means that the amount of time until you can be 90% (or 95% or 97.5%) sure that you are not going to get a reply increases too. There are only two assumptions in this calculation. The first is that the time it takes to handle messages is normally distributed (again see stat book), which is a pretty fair assumption, at least for HTL greater than 10 or so (back to the book, see "Central Limit Theorem"). The second is the values we are using for the Expected value and variance, which are based on some pretty rough experiments from last spring. I have been wanting to ask somebody to do some better experiments to find out the current values - it's quite simple to do, simply request nonexistant keys with a HTL around 20-30 (to avoid excessive looping) and measure the time it takes to get a reply. I'm going to put in a node diagnostics module in 0.4 that will do continual tests of this sort of thing in future versions. > There is no evidence that a HTL of 100 is unreasonable, but if such a > HTL would lead to nodes waiting around for ages, then the problem is the > arbitrary calculation, not nescessarily that the HTL is too large. The reason we would have to fucking wait a long time to restart when HTL is 100, is because it takes a fucking long time to make 100 hops even if everything goes right. To say that is because of how we calculate it is silly beyond words. Of course, it can be worked around. One could imagine a system where we continually send ping/pong messages up and down the request path at fixed intervals. However, that would be a bitch to implement, add lots of load, and be an invaluable gift to anyone trying to use traffic analysis on the network - which is not something I am willing to accept for what I see as a half-assed workaround for the fact the routing is currently not working. -- 'DeCSS would be fine. Where is it?' 'Here,' Montag touched his head. 'Ah,' Granger smiled and nodded. Oskar Sandberg oskar at freenetproject.org _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
