>Hi! > >Presumably this post belongs in the tech section, but I didn't see much except >SPAM in the archives. Didn't see anything like it in the devl archives either, >so here goes.
Actually, ideas like this have been discussed before...but always shot down for complaints of random routing times - occasionally a request would just keep going and going and going... >This is about HTL 25 and identification of the nodes inserting and requesting >informations. To achieve maximum reach, most programs will increase the HTL on >both gets and inserts to 25 if needed. The problem with this is that this also >means the node using that is also the originating node, since the default HTL >max limit is 25, and so any neighbouring node could monitor them. I wonder >whether this problem could be solved by not making HTLs absolute, but rather >probabilistic. This means that a server will decrease HTL with 1 with a >probability p%, or pass it on with same HTL with probability (1-p%). In fact, >I'd consider it a good thing for the entire HTL system as it makes nothing >certain about the number of hops to or from anything, making trafic analysis >difficult. Something like this will be needed at some point. No matter how much you tell people about the problems with anonymity, people will use the max HTL, as it's just plain more reliable. This strikes me as one of the more well-thought suggestions for doing this. > However, to keep it from being too varying, it should be less and less likely > the lower the HTL. I've played around a bit with the numbers in > Excel with @RISK and came up with a TTL (time to live) formula that g >?ives results like this: > >New ? ? ?Old ? ?(5%th-95%th percentile) >TTL ?5 = HTL ?5 (HTL05-05) >TTL 10 = HTL 10 (HTL10-11) >TTL 15 = HTL 16 (HTL15-18) >TTL 20 = HTL 25 (HTL21-29) > >Chance that a TTL20 insert/get is the original inserter/requester: 47% >Chance that a TTL19 insert/get is next to inserter: 22% > >Tranlation: Finding the original inserter will be a really big bitch. > >Pseudocode: IF(OldTTL^3/15000 <?RAND()) THEN NewTTL = OldTTL ELSE NewTTL = >OldTTL-1, where RAND() is a random number between 0 and 1. Nice numbers, and very little chance of a runaway request, from the looks of things...and the very rare runaway request is unlikely to hurt anything. >Potentially, the transition could be fairly easy, if the new nodes simply >reduce HTL >?20 to TTL 20 and pass it on. while old nodes use the same as HTL. >In a worst case scenario, you lose 5 hops HTL 25 ->?TTL 20 ->?HTL again (or >gain 5, if you get both HTL 25->20 + TTL hops). > >My java knowledge is less than stunning, but I think the idea is sound and the >numbers good. Let me know what you other people think, and if you are >interested. I could try to implement it myself, but I'd probably introdouce a >dozen Heisenbugs in the process, so suggest that at your own risk :) Actually, that seems to be the standard answer for this sort of thing... >Kjella [ cruise / casual-tempest.net / transference.org ] _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
