[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] so many options no idea where to begin
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 [expletive deleted]-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...
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|