SPECIFICATION
The test protocol runs a ``ping-pong'' test of the protocol below it
for various message lengths and numbers of iterations.
SYNOPSIS
Transport test protocols run in one of two roles, either as ``client''
or as ``server.'' The client will send a message to the server and
wait for a reply before sending the next message. There are no
provisions for retransmission - if the protocol below the test
protocol drops a message, the test will fail.
CONFIGURATION
When the test protocol instantiates, it can determine which role it
should assume in several ways. Command line parameters can be used to
cause the same kernel to run as the server on one machine and as the
client on another. The server should be started up with a ``-s''
flag:
xkernel -s
The client side must be told the host address of the server peer (note that on the sunos platform, this should be the address of the simulated IP host.) This can be done with the ``-c'' command line option, e.g.:
xkernel -c192.12.69.54
If you will be running several tests between the same hosts you may find it convenient to copy the test protocol to your build directory and edit the declaration of ServerAddr and ClientAddr in your local copy to name these hosts directly. This will eliminate the need for client and server flags. Note that most test protocols include other files from the protocols/test directory, so you will either have to copy those files as well or add $(XRT)/protocols/test to the TMP_INCLUDES variable in your Makefile.
If a test protocol is configured with an instance name of 'client' or 'server', it will come up in the appropriate role. This can be used to run both a client and server in the same kernel for loopback testing as in this graph.comp excerpt:
... name=udp protocols=ip; name=udptest/server protocols=udp; name=udptest/client protocols=udp;
If you have configured several standard test protocols into the kernel, you can run any subset of them by putting the test names onto the command line, e.g.:
xkernel -testip -testudp
With no command line test selections, all of the configured test protocols will run.
The number of round trips for each packet size can be set with the ``trips'' flag:
xkernel -trips=10000
If you use ``dns'' lines (see 9.6) in your rom file to map host names to IP addresses, then you can use the name in place of the IP address when starting the client, i.e.,
Rom file entry:
dns mars 192.12.69.54
Sample command lines for starting client:
xkernel -c mars
xkernel -cmars
Note that the name on the command line must be an exact match (not a substring) of the rom file entry.
The test protocols all use the common trace variable prottest which can be set in the third section of graph.comp:
@; ... name=udptest protocols=udp; @; name=prottest trace=TR_EVENTS;
If you set a trace level when you declare the test protocol in the second section of graph.comp, it will be ignored.
CAVEATS
Remember that if you are using simeth you must use the name of
the simulated host when you invoke the client, not the real host.