Dear fellow Flood developers:
It is beneficial to us as members of the Apache Flood community and as
developers of application testing software, using Flood as the basis for
testing web sites within an application we have developed to test
web-based software, within the context of the imminent rollout of the next
revision of Flood to the public by Apache, to try to make available as
many of the bug fixes which respond to the the bugs we find to the Apache
group, as well as provide direction towards a reworking of the Flood
architecture, which we have done in order to integrate with our entire
application as well as to provide greater functionality & efficiency. In
this context, people who have asked whether Flood can be faster may also
find a suitable answer in the solutions we provide..
Therefore, in the upcoming days, as time permits, I will try to provide
these bug fixes and potential feature improvements and efficiency-building
modifications, in exchange asking for guidance on other features which we
are trying to implement (or implement better).
-Norman Tuttle, developer, OpenDemand Systems, [EMAIL PROTECTED]
Below, I have begun with some comments on various topics:
1) Bugs related to keepalives (sockets):
1a) The keepalive code in Flood is error-prone, especially when dealing
with sockets which can represent SSL or non-SSL protocols. We have made
some bug fixes AND added a patch for check_sockets() to work with SSL
sockets. Flood code is especially suspect at this point when attempting to
do keepalive where there are both SSL and non-SSL pages. I believe that I
have fixed this in our code. It may take some time to convert this to the
way the Apache team wants the code (in diff format), so I am only
providing a related fix now:
1b) Keepalive chunking issue
In April, I reported a problem with deploying Flood on Sun Solaris using
keepalive sockets. It appeared that Flood was failing on an assert in the
keepalive code, related to a chunking error. Both Justin Erenkrantz and
Aaron Bannert provided me with some ideas for resolving the issue; I
had to abandon it at the time in favor of other development but have
recently revisited it and found out what was causing the problem. Thank
you both for your assistance. It happens that the chunk length in hex
coming back is padded with extra spaces at the end, and the code currently
in Flood does not allow for this, causing a later error of failing the
assert in the keepalive code (basically saying that a CRLF has not been
found at that point). My solution has been to rewrite the
keepalive_read_chunk_size() function, basically a hex evaluator function,
from scratch as below, to be more flexibile than the one currently found
in flood_socket_keepalive.c:
/* This is really a hex evaluator function. */
static long keepalive_read_chunk_size(char *begin_chunk)
{
long OutputHex=0;
unsigned char Addend;
while (isspace(*begin_chunk)) begin_chunk++;
while (isxdigit(Addend=(*(begin_chunk++))))
{
OutputHex=(OutputHex<<4)+((Addend & 0xF)+((Addend > '9')?9:0));
}
return OutputHex;
}
1c) In "real life", we find the socket structure (using higher levels
accessing pointers to structures at intermediate and lower levels) to be
obfuscating and functionally difficult to deal with (even if it has a
somewhat object-oriented feel), and my next phase of development is to
make a single layer of socket flood_socket_t directly over the apr level.
But for the Flood project I intend to first publish my earlier levels of
changes from our CVS before this modification so that you can benefit from
our bug fixes without necessarily making this modification.
2) The following questions, regarding regex and responsetemplate, are
addressed to the Flood developers on the list, and those familiar with
regex (PCRE) library and regular expressions:
We're trying to use the responses coming back from the websites to fill
variables which can be used in future expressions sent back to the
website. While I understand that regular expressions should be able to
represent an expression to match including parts which represent a
variable or optional piece of information, I am not so familiar with how
Flood is using this information to feed the responsename value. For one, I
am not sure why this information is picked up by match[1], why there is an
nmatch value of 10 passed to the regexec function when picking up the
single matched value (when we are only matching for one responsename), why
a value of 2 for the initial variable name-pattern pattern match, and what
the other match[] members might represent. This will be helpful for our
application, if anyone is knowledgeable about these features.
Thanks in advance.
-Norman Tuttle, developer, OpenDemand Systems, [EMAIL PROTECTED]
