[
Lists Home |
Date Index |
Thread Index
]
yet another newbie stumbles into the maze of twisty TLA's all similar
but different...
long ago and far away (first public distribution in 1993), i
wrote/edited a benchmark called netperf (http://www.netperf.org/) it was
simple a netperf process on one side would take command-line arguments,
establish a control connection to a netserver process on another system,
config info would be passed, the test run and the numbers reported.
adding new tests meant changing several files and recompiling the whole
thing - tests were staticaly included in the netperf/netserver binaries.
netperf was coded in C and ported to a number of platforms - most
Unixes, 32-bit Windows. someone tried to get it going on a palmtop but
ran into the next issue.
the config info was passed as binary data - this meant some interesting
schennanigans for things like doubles (there being no htond for example)
and knowing to not flip strings around. some platforms had different
formats (let alone endianness) and well, they were just SOL for netperf.
(I never went as far as XDR, not sure why - I guess that doesn't matter
now though...)
time passed, people wanted more than just single connection tests, i
wanted to measure more than just bare TCP/UDP. thus was born netperf3 -
still command-line, now threaded/multiple process with synchronized
starting. still netperf processes talking to netserver processes. this
time config info was passed as strings. however, for some tests, having
both a netperf and netserver was silly when the system under test (SUT)
was really a third system (eg the FTP and DNS stuff as described
ftp://ftp.cup.hp.com/dist/networking/briefs/) tests are still statically
compiled into netperf/netserver. netperf remains coded in C.
now I'm looking to abstract further, and someone suggested that XML may
be the way to go. i am looking for a more flexible config format and
message passing mechanism, and reporting. in this new version of
netperf, I anticipate there being a single controlling netperf process,
and all the tests themselves will reside and run within netserver
processes/threads. I figure there will be an abstraction called a
"server" that corresponds to the netserver, and a "test" abstraction
that corresponds to the test instances in a server(s).
i want all the sources used in this new version of netperf to be freely
distributable, just like the older versions
i'm looking to have test suites be "plugins" (without full knowledge yet
of what that may mean :) - which means that the base netperf may not
know quite how to grok test-specific config info for a new test suite.
a test instance would be in a number of "states" in its lifetime:
new - the thread for the test instance was created
init - the test is initialized and read to start
load - the test is generating load
measure - the test is measuring its generated load
there would be messages passed between netperf and netserver to cause
thse things to occur - there may also be other things like a kill
message to kill a test with extreme predjudice and perhaps a request for
intermediate results. some messages are of things completely known to
netperf, some are likely to be rather test-specific. there is to be a
single TCP connection between a netperf and a netserver overwhich will
be multiplexed comms for the individual test instances living within
that netserver.
in C-like-speak a config file might look something like this:
server 1 {
host foo.bar.baz;
port 12345;
};
server 2 {
host bing.fred.ethel; // just a random comment
port 54321;
};
test 1 {
type SEND_TCP_STREAM; /* the name of the test instance to run */
library libnettest_bsd.sl; /* library with the routines */
server 1; /* the server instance hosting us */
specific { /* test-specific settings */
sfamily AF_INET; /* local address family */
source foo.bar.baz; /* local IP INADDR_ANY means no bind */
sport 1234; /* local port 0 means system choose */
sndbuf 32768; /* the local send buffer size */
rcvbuf 32768; /* the local recv buffer size */
ssize 4KB; /* the send size */
nodelay 0; /* setting for TCP_NODELAY */
dfamily AF_INET; /* destination address family */
dest fred.ethel; /* the destination host info */
dport auto 2; /* destination port number */
salign 8; /* send buffer alignment */
soffset 0; /* send buffer offset */
};
};
test 2 {
type RECV_TCP_STREAM;
library libnettest_bsd.sl; /* where to find test-specific routines */
server 2;
specific {
sfamily AF_INET;
source bing.fred.ethel;
sport 0;
sndbuf 32768;
rcvbuf 32768;
};
};
notice that there is a dependency between test 2 and test 1 - test 2
needs to know what the dynamically alolcated port number used by test 1
happens to be before it can establish the data connection.
also for something like an FTP or HTTP or DNS test, there will not be
paired instances.
my current strawman XML version looks like this at the moment:
<?xml version="1.0"?>
<netperf xmlns="http://www.netperf.org/ns/netperf";
xmlns:nettest_bsd="http://www.netperf.org/ns/netperf/nettest_bsd";
xmlns:xi="http://www.w3.org/2001/XInclude";
>
<server id="1">
<host>foo.bar.baz</host>
<port>12345</port>
<family>AF_INET</family>
</server>
<server id="2">
<host>bing.fred.ethel</host>
<port>12345</port>
<family>AF_INET</family>
</server>
<test id="1">
<type>SEND_TCP_STREAM</type>
<library>libnettest_bsd.sl</library>
<companion>2</companion>
<nettest_bsd:specific>
<nettest_bsd:source>foo.bar.baz</nettest_bsd:source>
<nettest_bsd:sourcefamily>AF_INET</nettest_bsd:sourcefamily>
<nettest_bsd:sourceport>1234</nettest_bsd:sourceport>
<nettest_bsd:sndbuf>32768</nettest_bsd:sndbuf>
<nettest_bsd:rcvbuf>32768</nettest_bsd:rcvbuf>
<nettest_bsd:sendsize>4KB</nettest_bsd:sendsize>
<nettest_bsd:nodelay>0</nettest_bsd:nodelay>
<nettest_bsd:destination>bin.fred.ethel</nettest_bsd:destination>
<nettest_bsd:destport>0</nettest_bsd:destport>
<nettest_bsd:destfamily>AF_INET</nettest_bsd:destfamily>
<nettest_bsd:sendalign>8</nettest_bsd:sendalign>
<nettest_bsd:sendoffset>0</nettest_bsd:sendoffset>
</nettest_bsd:specific>
</test>
<!-- This is just another boring comment -->
<test id="2">
<type>RECV_TCP_STREAM</type>
<library>libnettest_bsd.sl</library>
<companion>1</companion>
<nettest_bsd:specific>
<nettest_bsd:source>bing.fred.ethel</nettest_bsd:source>
<nettest_bsd:sourcefamily>AF_INET</nettest_bsd:sourcefamily>
<nettest_bsd:sourceport>0</nettest_bsd:sourceport>
<nettest_bsd:sndbuf>32768</nettest_bsd:sndbuf>
<nettest_bsd:rcvbuf>32768</nettest_bsd:rcvbuf>
<nettest_bsd:recvsize>4KB</nettest_bsd:recvsize>
<nettest_bsd:recvalign>8</nettest_bsd:recvalign>
<nettest_bsd:recvoffset>0</nettest_bsd:recvoffset>
</nettest_bsd:specific>
</test>
<!-- I would like to be able to include a file of just test and server
elements without a containing <netperf></netperf> -->
<xi:include href="sub.xml" />
</netperf>
having become totally confused by C++ several times, and wanting more
low-level control over sockets than I understand is available in Java,
and wanting to use things like libcurl for the FTP and HTTP i would like
to stick with C (perhaps that shows my age :) i have come across libxml
from the gnome folks - haven't gone quite as far as gdome2 yet though,
peeked only a little at SOAP and am not sure I want to go that far just
yet.
using XML as the output format of the benchmark appears appealing - the
stuff I wrote to parse netperf2 output for the netperf database was,
well, quaint.
well enough of this tedious background infomration; some of the
XML-specific questions I have at the moment:
*) i'm not sure when one "should" use attributes versus a nested element
*) my config files may become quite large - XInclude sounds interesting,
but a fully formed file XIncluded (at least via libxml) has the whole
file as a sub-element when what I really want (I think anyway) is the
elements in the file being included be at the same depth as the include
itself (ie up one level)
*) since I am interested in things like doubles and 64-bit integers and
such i think i want to use XML schemas (?) but those seem to be still
rather new and not part of libxml - are they part of any other C-based
offering.
*) when someone adds a new test suite, I'd like them to be able to
include a validator (schema?) that will be sucked-in to the main config
file. however, i'm concerned about what I read about namespaces (which I
think I may need/want to avoid name conflicts) and validation, and it
seems that the validators have to be all specified at the top of a
document?
i'm sure that my questions show just how little I really understand
about all this, so please be gentle :)
rick jones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...
|
