You are viewing a plain text version of this content. The canonical link for it is here.
Posted to test-dev@httpd.apache.org by Aaron Bannert <aa...@clove.org> on 2001/08/17 17:30:20 UTC
Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_round_robin.c
On Fri, Aug 17, 2001 at 07:44:02AM -0000, jerenkrantz@apache.org wrote:
> jerenkrantz 01/08/17 00:44:02
>
> Modified: flood config.h.in configure.in flood.c
> flood_round_robin.c
> Log:
> - Clean up debugging info when using delays.
> - Fix error where a url would be chopped off (must follow l.list of apr_text
> objects to be valid). This should not affect attributes as they are
> handled differently by the expat XML parser.
> - Introduce two more random number generators (rand48 and random). Add
> autoconf test to choose "best" one. May be good to add support for
> /dev/urandom (whatever the non-blocking one is), but Solaris doesn't have
> it, so I don't care much right now.
>
> The rand() period is incredibly short. rand48 and random are supposed to
> have much longer periods. We'll see...
>
> Revision Changes Path
> 1.14 +4 -0 httpd-test/flood/config.h.in
>
> Index: config.h.in
> ===================================================================
> RCS file: /home/cvs/httpd-test/flood/config.h.in,v
> retrieving revision 1.13
> retrieving revision 1.14
> diff -u -r1.13 -r1.14
> --- config.h.in 2001/08/14 20:14:50 1.13
> +++ config.h.in 2001/08/17 07:44:02 1.14
> @@ -57,4 +57,8 @@
> #define RANDFILE "@RANDFILE@"
> #define CAPATH "@CAPATH@"
>
> +#define FLOOD_USE_RAND @prngrand@
> +#define FLOOD_USE_RAND48 @prngrand48@
> +#define FLOOD_USE_RANDOM @prngrandom@
> +
> #endif /* __config_h */
>
>
>
> 1.5 +24 -0 httpd-test/flood/configure.in
>
> Index: configure.in
> ===================================================================
> RCS file: /home/cvs/httpd-test/flood/configure.in,v
> retrieving revision 1.4
> retrieving revision 1.5
> diff -u -r1.4 -r1.5
> --- configure.in 2001/08/07 19:00:23 1.4
> +++ configure.in 2001/08/17 07:44:02 1.5
> @@ -86,6 +86,27 @@
> AC_CHECK_LIB(crypto, SHA1)
> AC_CHECK_LIB(ssl, SSL_library_init)
>
> +AC_CHECK_FUNC(rand, hasrand="1", hasrand="0")
> +AC_CHECK_FUNC(lrand48, hasrand48="1", hasrand48="0")
> +AC_CHECK_FUNC(random, hasrandom="1", hasrandom="0")
> +
> +AC_MSG_CHECKING([random number generator to use])
> +prngrand="0"
> +prngrand48="0"
> +prngrandom="0"
> +if test $hasrandom = "1"; then
> + prngrandom="1"
> + AC_MSG_RESULT([random])
> +else if $hasrand48 = "1"; then
> + prngrand48="1"
> + AC_MSG_RESULT([rand48])
> +else if $hasrand = "1"; then
> + prngrand="1"
> + AC_MSG_RESULT([rand])
> +fi
> +fi
> +fi
> +
> AC_SUBST(FLOOD_USE_THREADS)
> AC_SUBST(OPENSSL_PREFIX)
> AC_SUBST(RANDFILE)
> @@ -97,6 +118,9 @@
> AC_SUBST(EXTRA_CPPFLAGS)
> AC_SUBST(EXTRA_LDFLAGS)
> AC_SUBST(EXTRA_LIBS)
> +AC_SUBST(prngrand)
> +AC_SUBST(prngrand48)
> +AC_SUBST(prngrandom)
Shouldn't this just be FLOOD_HAS_* by the way you are deciding which
one to use inside the #ifdef's? I'll post a patch later today.
(I know I know, I'm being picky.)
>
> <snip>
>
The rest looks good.
-aaron
Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_round_robin.c
Posted by Aaron Bannert <aa...@clove.org>.
On Fri, Aug 17, 2001 at 11:15:34AM -0700, Justin Erenkrantz wrote:
> On Fri, Aug 17, 2001 at 09:34:28AM -0700, Aaron Bannert wrote:
> > This is all really NBD, I'm just pointing out that by what you were doing
> > in code should have been done with USE instead of HAS, and that it would
> > be no big deal to add HAS and USE.
>
> Please check the code again - it is using USE. =-) -- justin
You are indeed correct. Nevermind my ramblings... ;)
-aaron
Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_round_robin.c
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Fri, Aug 17, 2001 at 09:34:28AM -0700, Aaron Bannert wrote:
> This is all really NBD, I'm just pointing out that by what you were doing
> in code should have been done with USE instead of HAS, and that it would
> be no big deal to add HAS and USE.
Please check the code again - it is using USE. =-) -- justin
Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_round_robin.c
Posted by Aaron Bannert <aa...@clove.org>.
On Fri, Aug 17, 2001 at 09:19:26AM -0700, Justin Erenkrantz wrote:
> On Fri, Aug 17, 2001 at 09:00:53AM -0700, Aaron Bannert wrote:
> > Let me be more clear here. I'd prefer if we did the check for
> > 'rand' 'rand48' 'random' (and possibly also /dev/urandom) and
> > set each of FLOOD_HAS_RAND* individually. This is the way you are
> > using it in the code, where you have something like:
> >
> > #if FLOOD_HAS_RAND
> > rand()
> > #elsif FLOOD_HAS_RAND48
> > rand48()
> > ...
>
> Eh? No. We shouldn't do it that way. I want the configure to pick the
> "best" PRNG available and I want to use it. In the code snippet you
> just posted, you'd almost always use rand - which is the absolutely
> worst one you could use. So, you'd have to code it like:
>
> #if FLOOD_HAS_RANDOM
> random()
> #elsif FLOOD_HAS_RAND48
> rand48()
> #else FLOOD_HAS_RAND
> rand()
> #endif
>
> -1. The actual code is almost always going to want USE #defines
> not HAS #defines. Relying on the order of HAS is counter-intuitive -
> therefore, I'll veto the hell out of it. =-) You would typically
> want the HAS #defines when they are all equivalent functions - you
> want the USE #defines when there is a definite priority as to which
> one you want (and it is very possible that a system will have all
> of the different possibilities). Think of shmem in APR...
Of course you don't want to use rand() if others are available!
There is no order inherent in HAS semantics. HAS merely defines the
existance of some function or functionality, it does not define any
relationship between other similiar functions or functionality.
What you are doing in code should be done with USE semantics.
> > That allows us to choose which rand we have in the #ifdefs instead of
> > relying on autoconf. If this is unsatisfactory, we'll have to go with
> > the compromise, which is FLOOD_USE_RAND* and FLOOD_HAS_RAND*
>
> It should be trivial to add FLOOD_HAS_RAND* macros from what I committed
> last night - I just don't think you would add any value by having the
> HAS_RAND* macros for the reasons described above.
This is all really NBD, I'm just pointing out that by what you were doing
in code should have been done with USE instead of HAS, and that it would
be no big deal to add HAS and USE.
-aaron
Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_round_robin.c
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Fri, Aug 17, 2001 at 09:00:53AM -0700, Aaron Bannert wrote:
> Let me be more clear here. I'd prefer if we did the check for
> 'rand' 'rand48' 'random' (and possibly also /dev/urandom) and
> set each of FLOOD_HAS_RAND* individually. This is the way you are
> using it in the code, where you have something like:
>
> #if FLOOD_HAS_RAND
> rand()
> #elsif FLOOD_HAS_RAND48
> rand48()
> ...
Eh? No. We shouldn't do it that way. I want the configure to pick the
"best" PRNG available and I want to use it. In the code snippet you
just posted, you'd almost always use rand - which is the absolutely
worst one you could use. So, you'd have to code it like:
#if FLOOD_HAS_RANDOM
random()
#elsif FLOOD_HAS_RAND48
rand48()
#else FLOOD_HAS_RAND
rand()
#endif
-1. The actual code is almost always going to want USE #defines
not HAS #defines. Relying on the order of HAS is counter-intuitive -
therefore, I'll veto the hell out of it. =-) You would typically
want the HAS #defines when they are all equivalent functions - you
want the USE #defines when there is a definite priority as to which
one you want (and it is very possible that a system will have all
of the different possibilities). Think of shmem in APR...
> That allows us to choose which rand we have in the #ifdefs instead of
> relying on autoconf. If this is unsatisfactory, we'll have to go with
> the compromise, which is FLOOD_USE_RAND* and FLOOD_HAS_RAND*
It should be trivial to add FLOOD_HAS_RAND* macros from what I committed
last night - I just don't think you would add any value by having the
HAS_RAND* macros for the reasons described above.
And, really, this should be moved into APR not flood.
My $.02. -- justin
Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_round_robin.c
Posted by Aaron Bannert <aa...@clove.org>.
On Fri, Aug 17, 2001 at 08:30:20AM -0700, Aaron Bannert wrote:
> On Fri, Aug 17, 2001 at 07:44:02AM -0000, jerenkrantz@apache.org wrote:
> > jerenkrantz 01/08/17 00:44:02
> >
> > Modified: flood config.h.in configure.in flood.c
> > flood_round_robin.c
> > Log:
> > - Clean up debugging info when using delays.
> > - Fix error where a url would be chopped off (must follow l.list of apr_text
> > objects to be valid). This should not affect attributes as they are
> > handled differently by the expat XML parser.
> > - Introduce two more random number generators (rand48 and random). Add
> > autoconf test to choose "best" one. May be good to add support for
> > /dev/urandom (whatever the non-blocking one is), but Solaris doesn't have
> > it, so I don't care much right now.
> >
> > The rand() period is incredibly short. rand48 and random are supposed to
> > have much longer periods. We'll see...
> >
> > Revision Changes Path
> > 1.14 +4 -0 httpd-test/flood/config.h.in
> >
> > Index: config.h.in
> > ===================================================================
> > RCS file: /home/cvs/httpd-test/flood/config.h.in,v
> > retrieving revision 1.13
> > retrieving revision 1.14
> > diff -u -r1.13 -r1.14
> > --- config.h.in 2001/08/14 20:14:50 1.13
> > +++ config.h.in 2001/08/17 07:44:02 1.14
> > @@ -57,4 +57,8 @@
> > #define RANDFILE "@RANDFILE@"
> > #define CAPATH "@CAPATH@"
> >
> > +#define FLOOD_USE_RAND @prngrand@
> > +#define FLOOD_USE_RAND48 @prngrand48@
> > +#define FLOOD_USE_RANDOM @prngrandom@
> > +
> > #endif /* __config_h */
> >
> >
> >
> > 1.5 +24 -0 httpd-test/flood/configure.in
> >
> > Index: configure.in
> > ===================================================================
> > RCS file: /home/cvs/httpd-test/flood/configure.in,v
> > retrieving revision 1.4
> > retrieving revision 1.5
> > diff -u -r1.4 -r1.5
> > --- configure.in 2001/08/07 19:00:23 1.4
> > +++ configure.in 2001/08/17 07:44:02 1.5
> > @@ -86,6 +86,27 @@
> > AC_CHECK_LIB(crypto, SHA1)
> > AC_CHECK_LIB(ssl, SSL_library_init)
> >
> > +AC_CHECK_FUNC(rand, hasrand="1", hasrand="0")
> > +AC_CHECK_FUNC(lrand48, hasrand48="1", hasrand48="0")
> > +AC_CHECK_FUNC(random, hasrandom="1", hasrandom="0")
> > +
> > +AC_MSG_CHECKING([random number generator to use])
> > +prngrand="0"
> > +prngrand48="0"
> > +prngrandom="0"
> > +if test $hasrandom = "1"; then
> > + prngrandom="1"
> > + AC_MSG_RESULT([random])
> > +else if $hasrand48 = "1"; then
> > + prngrand48="1"
> > + AC_MSG_RESULT([rand48])
> > +else if $hasrand = "1"; then
> > + prngrand="1"
> > + AC_MSG_RESULT([rand])
> > +fi
> > +fi
> > +fi
> > +
> > AC_SUBST(FLOOD_USE_THREADS)
> > AC_SUBST(OPENSSL_PREFIX)
> > AC_SUBST(RANDFILE)
> > @@ -97,6 +118,9 @@
> > AC_SUBST(EXTRA_CPPFLAGS)
> > AC_SUBST(EXTRA_LDFLAGS)
> > AC_SUBST(EXTRA_LIBS)
> > +AC_SUBST(prngrand)
> > +AC_SUBST(prngrand48)
> > +AC_SUBST(prngrandom)
>
> Shouldn't this just be FLOOD_HAS_* by the way you are deciding which
> one to use inside the #ifdef's? I'll post a patch later today.
>
> (I know I know, I'm being picky.)
Let me be more clear here. I'd prefer if we did the check for
'rand' 'rand48' 'random' (and possibly also /dev/urandom) and
set each of FLOOD_HAS_RAND* individually. This is the way you are
using it in the code, where you have something like:
#if FLOOD_HAS_RAND
rand()
#elsif FLOOD_HAS_RAND48
rand48()
...
That allows us to choose which rand we have in the #ifdefs instead of
relying on autoconf. If this is unsatisfactory, we'll have to go with
the compromise, which is FLOOD_USE_RAND* and FLOOD_HAS_RAND*
-aaron
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/
Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_round_robin.c
Posted by Justin Erenkrantz <je...@ebuilt.com>.
[ 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 Justin Erenkrantz <je...@ebuilt.com>.
[ 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 Aaron Bannert <aa...@clove.org>.
On Fri, Aug 17, 2001 at 09:02:01AM -0700, Justin Erenkrantz wrote:
> On Fri, Aug 17, 2001 at 08:30:20AM -0700, Aaron Bannert wrote:
> > > Index: config.h.in
> > > ===================================================================
> > > RCS file: /home/cvs/httpd-test/flood/config.h.in,v
> > > retrieving revision 1.13
> > > retrieving revision 1.14
> > > diff -u -r1.13 -r1.14
> > > --- config.h.in 2001/08/14 20:14:50 1.13
> > > +++ config.h.in 2001/08/17 07:44:02 1.14
> > > @@ -57,4 +57,8 @@
> > > #define RANDFILE "@RANDFILE@"
> > > #define CAPATH "@CAPATH@"
> > >
> > > +#define FLOOD_USE_RAND @prngrand@
> > > +#define FLOOD_USE_RAND48 @prngrand48@
> > > +#define FLOOD_USE_RANDOM @prngrandom@
> > > +
> > > #endif /* __config_h */
>
> > Shouldn't this just be FLOOD_HAS_* by the way you are deciding which
> > one to use inside the #ifdef's? I'll post a patch later today.
> >
> > (I know I know, I'm being picky.)
>
> I dunno. I think it is a USE because you may have all three, but you
> only want to use one of them. I don't think this is a HAS/HAVE
> because you may not always use the ones you have. Confusing...
> -- justin
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?
-aaron
Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_round_robin.c
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Fri, Aug 17, 2001 at 08:30:20AM -0700, Aaron Bannert wrote:
> > Index: config.h.in
> > ===================================================================
> > RCS file: /home/cvs/httpd-test/flood/config.h.in,v
> > retrieving revision 1.13
> > retrieving revision 1.14
> > diff -u -r1.13 -r1.14
> > --- config.h.in 2001/08/14 20:14:50 1.13
> > +++ config.h.in 2001/08/17 07:44:02 1.14
> > @@ -57,4 +57,8 @@
> > #define RANDFILE "@RANDFILE@"
> > #define CAPATH "@CAPATH@"
> >
> > +#define FLOOD_USE_RAND @prngrand@
> > +#define FLOOD_USE_RAND48 @prngrand48@
> > +#define FLOOD_USE_RANDOM @prngrandom@
> > +
> > #endif /* __config_h */
> Shouldn't this just be FLOOD_HAS_* by the way you are deciding which
> one to use inside the #ifdef's? I'll post a patch later today.
>
> (I know I know, I'm being picky.)
I dunno. I think it is a USE because you may have all three, but you
only want to use one of them. I don't think this is a HAS/HAVE
because you may not always use the ones you have. Confusing...
-- justin