You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Justin Erenkrantz <je...@ebuilt.com> on 2001/08/17 18:30:24 UTC
Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_round_robin.c
[ CCing dev@apr - this came about due to flood requiring a PRNG... ]
On Fri, Aug 17, 2001 at 09:21:06AM -0700, Aaron Bannert wrote:
> Really this should be in APR, but I fear that PRNG is a touchy subject
> for portability. The problem is that when you're using a PRNG, you usually
> need to know the operating parameters of the PRNG, like what you ran in to:
> period, distribution, etc... If we put an abstraction into APR, we may end
> up with lowest-common-denominator-syndrome, where it becomes less than
> useful for cases that require specific amounts of entropy.
> What do you think?
Knuth Vol. 2 or Numerical Recipies in C. =-) Both have fairly large
and detailed sections on PRNGs. (I have both books.)
I don't see a problem adding a PRNG into APR as long as we have a by
default "good" one available with known characteristics. -- justin
Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_round_robin.c
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> > I don't see a problem adding a PRNG into APR as long as we have a by
> > default "good" one available with known characteristics. -- justin
>
> Um... APR *already* has random stuff in there. It can build against the
> truerand library, and it can use the /dev/random device.
>
> If we have a small hunk of PRNG code, that would be great. Unfortunately,
> though, it would be rather difficult to feed APR with a lot of entropic
> data. (i.e. where/how would it come from?)
PRNG == pseudo-random number generator
== repeatable so that simulations can be repeated for analysis
I don't know if it would be useful in apr or not.
....Roy
Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_round_robin.c
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> > I don't see a problem adding a PRNG into APR as long as we have a by
> > default "good" one available with known characteristics. -- justin
>
> Um... APR *already* has random stuff in there. It can build against the
> truerand library, and it can use the /dev/random device.
>
> If we have a small hunk of PRNG code, that would be great. Unfortunately,
> though, it would be rather difficult to feed APR with a lot of entropic
> data. (i.e. where/how would it come from?)
PRNG == pseudo-random number generator
== repeatable so that simulations can be repeated for analysis
I don't know if it would be useful in apr or not.
....Roy
Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_round_robin.c
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 17, 2001 at 09:30:24AM -0700, Justin Erenkrantz wrote:
> [ CCing dev@apr - this came about due to flood requiring a PRNG... ]
>
> On Fri, Aug 17, 2001 at 09:21:06AM -0700, Aaron Bannert wrote:
> > Really this should be in APR, but I fear that PRNG is a touchy subject
> > for portability. The problem is that when you're using a PRNG, you usually
> > need to know the operating parameters of the PRNG, like what you ran in to:
> > period, distribution, etc... If we put an abstraction into APR, we may end
> > up with lowest-common-denominator-syndrome, where it becomes less than
> > useful for cases that require specific amounts of entropy.
> > What do you think?
>
> Knuth Vol. 2 or Numerical Recipies in C. =-) Both have fairly large
> and detailed sections on PRNGs. (I have both books.)
>
> I don't see a problem adding a PRNG into APR as long as we have a by
> default "good" one available with known characteristics. -- justin
Um... APR *already* has random stuff in there. It can build against the
truerand library, and it can use the /dev/random device.
If we have a small hunk of PRNG code, that would be great. Unfortunately,
though, it would be rather difficult to feed APR with a lot of entropic
data. (i.e. where/how would it come from?)
But just a good PRNG function would be handy, I'd think.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_round_robin.c
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 17, 2001 at 09:30:24AM -0700, Justin Erenkrantz wrote:
> [ CCing dev@apr - this came about due to flood requiring a PRNG... ]
>
> On Fri, Aug 17, 2001 at 09:21:06AM -0700, Aaron Bannert wrote:
> > Really this should be in APR, but I fear that PRNG is a touchy subject
> > for portability. The problem is that when you're using a PRNG, you usually
> > need to know the operating parameters of the PRNG, like what you ran in to:
> > period, distribution, etc... If we put an abstraction into APR, we may end
> > up with lowest-common-denominator-syndrome, where it becomes less than
> > useful for cases that require specific amounts of entropy.
> > What do you think?
>
> Knuth Vol. 2 or Numerical Recipies in C. =-) Both have fairly large
> and detailed sections on PRNGs. (I have both books.)
>
> I don't see a problem adding a PRNG into APR as long as we have a by
> default "good" one available with known characteristics. -- justin
Um... APR *already* has random stuff in there. It can build against the
truerand library, and it can use the /dev/random device.
If we have a small hunk of PRNG code, that would be great. Unfortunately,
though, it would be rather difficult to feed APR with a lot of entropic
data. (i.e. where/how would it come from?)
But just a good PRNG function would be handy, I'd think.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/