On Mon, Dec 25, 2000 at 10:39:08AM -0500, [EMAIL PROTECTED] wrote:
> On Mon, Dec 25, 2000 at 09:24:46AM -0500, Travis Bemann wrote:
> > On Mon, Dec 25, 2000 at 02:53:12AM -0500, Scott G. Miller wrote:
> > > On Mon, Dec 25, 2000 at 12:36:34AM -0500, Travis Bemann wrote:
> > > > On Sun, Dec 24, 2000 at 10:16:55PM -0800, Ian Clarke wrote:
> > > > > > While I agree that this is a high priority, you can't make a change like
> > > > > > that right before a release. The process is add features, test features,
> > > > > > fix bugs, test more, release. We should just release now and then add it
> > > > > > and try for another release soon.
> > > > >
> > > > > Of course significant changes should generally not be made before a
> > > > > release, but common sense should also be applied. Adding a small
> > > > > probability that a HTL will not be decremented is very straight-forward
> > > > > and doesn't really leave much room for bugs.
> > > >
> > > > Such a probability should IMHO be between 0.2 and 0.5.
> > >
> > > 0.5????? Thats pretty high.
> >
> > The whole point is to make it very difficult for one to determine
> > where a request ended. Setting this probability between 0.2 and 0.5
> > (setting it really high) is an extremely effective way to do so.
>
> How about probability to *NOT* decrement HTL is:
> p = 0.5 * e^-k*(HTL-1)
>
> so if HTL is 1 you get the 50% chance to keep going, but for large
> HTLs you are almost assured the HTL gets decremented (of course you
> have to choose k appropriately).
Yeah. What he said. :)
PGP signature
