Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_easy_reports.c flood_farm.c flood_net.c flood_net_ssl.c flood_report_relative_times.c
On Thu, Aug 23, 2001 at 10:35:50PM -0700, Justin Erenkrantz wrote: On Fri, Aug 24, 2001 at 04:26:39AM -, [EMAIL PROTECTED] wrote: jerenkrantz01/08/23 21:26:39 Modified:floodconfig.h.in configure.in flood.c flood_easy_reports.c flood_farm.c flood_net.c flood_net_ssl.c flood_report_relative_times.c Log: Per Sander, Linux 2.4 returns EAGAIN when we run out of ports. This was a royal screw-up on my part. I only meant to commit flood_net.c, but all of the fork stuff slipped in. It wasn't really ready for commit. But, uh, yeah, it's there now. =) I'll test it some more (it works) and then I'll commit lines to CHANGES with what I really changed on this commit. *sigh* -- justin After looking through the changes I'm not so sure this is what we want. I'd rather not treat threads and forked processes the same, since we may want to mix the two. The fork()ed scenario was what we originally defined as a collective, which is basicly a bunch of farms with each farm running in a single process. I'm worried that we're losing flexibility here, at least in terms of properly emulating some real-world clients (like a browser that truely uses threads). This may just be invalid paranoia on my part, but at this time I see no good reason to restrict ourselves. I like using conditional compilation for things like optimizing OpenSSL usage, but I don't like it for deciding what a farmer does. Anyway, I realize that this was a premature commit, but I thought I'd voice my objections anyway ;) BTW, I'm glad to see we're going to support fork()ing soon :) -aaron
Re: cvs commit: httpd-test/flood CHANGES flood_farm.c
On Fri, Aug 24, 2001 at 05:59:58AM -, [EMAIL PROTECTED] wrote: jerenkrantz01/08/23 22:59:58 Modified:floodCHANGES flood_farm.c Log: Okay, here's the real commit log for the fork()-based implementation of flood. - Remove FLOOD_USE_THREADS as we have no way of determining if we have threads other than APR. (We'd say that threads were always enabled.) I feel comfortable using APR's thread detection rather than mucking with parameters ourselves. - Add strtoq conversion for FreeBSD that #defines it to strtoll. This is a tad cheesy. Thoughts? I don't want to have #ifdef HAVE_STRTOLL and #ifdef HAVE_STRTOQ all over the place. Smells like an APR function. does linux have strtoll? IIRC, we're just reading it into an 'int' anyway, so why the long long? - Remove forking stuff in flood.c as it doesn't make sense to fork() here anyway as this is only bootstrap code. - Make reports output either the current thread id or the pid I assume this is only temporary until we have a better GUID? We really shouldn't be calling apr_os_thread_id() and then trying to print it as an int. How about just a counter for each new thread/process? - Don't do OpenSSL locking when we aren't threaded cool. - Not all OpenSSL versions (FreeBSD 4.2 has 0.9.5a) has AUTO_RETRY. So, only set that option if we have that symbol. So, we now support FreeBSD. Go forth. very cool. -aaron
Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_round_robin.c
On Fri, Aug 17, 2001 at 09:30:24AM -0700, Justin Erenkrantz wrote: [ CCing [EMAIL PROTECTED] - 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
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
