next up previous contents index
Next: UDP Up: Protocol Specifications Previous: TCP

TEST

 

NAME

TEST (instantiated as 'chantest', 'udptest', etc.)

SPECIFICATION

The test protocol, usually running a simple a ``ping-pong'' test of the protocol below it, for various message lengths and number of round trips.

SYNOPSIS

Transport test protocols run in one of two roles, either as ``client'' or as ``server.'' In most cases, 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

The number of round trips for each packet size can be set with the ``trips'' flag:

xkernel -trips=10000

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.



Larry Peterson
Tue Jul 1 14:50:34 MST 1997