Treck Test Suite

Jump to: navigation, search

Table of Contents >> Application Reference

The Treck stack includes a module that allows you to perform a variety of tests on your system. These tests are outlined below:

UDP Tests

TM_TEST_UDP_SEND Sends UDP data to a remote server.
TM_TEST_UDP_RECV Receives UDP data from a remote client.
TM_TEST_UDP_ECHO_CLIENT Sends UDP data to a remote echo server, and waits for the server to echo it back.
TM_TEST_UDP_ECHO_SERVER Receives UDP data from a remote client, and echoes this data back to the client.

TCP Tests

TM_TEST_TCP_SEND Sends TCP data to a remote server.
TM_TEST_TCP_RECV Receives TCP data from a remote client.
TM_TEST_TCP_ECHO_CLIENT Connects to a remote server, and sends data to it, waiting for the server to echo it back.
TM_TEST_TCP_ECHO_SERVER Accepts connections from remote peers. Receives TCP data and echoes it back to the client.
TM_TEST_TCP_CONNECT Repeatedly connects, and then disconnects from a TCP server.

Miscellaneous Tests

TM_TEST_LOCK Verify that the Treck locking mechanism are set up and are functioning properly.


The behavior of these tests is modified by various flags:

TM_TEST_FLAG_ZEROCOPY Send and receive data using the Treck zero copy extensions rather than the standard sockets calls (e.g., tfZeroCopySend() rather than send())
TM_TEST_FLAG_NONBLOCKING Causes the test suite to run in non-blocking mode. This should be used if no kernel is available on your system.
TM_TEST_FLAG_UDP_CONNECT Rather than using the standard UDP (sendto(), recvfrom()) API, call connect() and use the TCP calls (e.g., send(), recv()).
TM_TEST_FLAG_UDP_CS_OFF Disable UDP checksums. Checksums are enabled by default.
TM_TEST_FLAG_TCP_NODELAY Sets the TCP_NODELAY option for this test. This causes TCP to send data immediately rather than delaying until more data is sent.
TM_TEST_FLAG_FILL_DATA This flag causes all outgoing data to be set to a repeating incremental pattern (0x00, 0x01, etc) before being sent.
TM_TEST_FLAG_VALIDATE Verify that all incoming data is as expected (i.e., as TM_TEST_FLAG_FILL_DATA sets it - see above).
TM_TEST_FLAG_RANDOM Choose random values for various parameters.

Blocking Mode

The Treck test suite may be run in either blocking or non-blocking mode. In blocking mode, the tfTestTreck() function will return either when the test has successfully completed, or when an error has occurred. In non-blocking mode, tfTestTreck() simply initiates the test. This function returns immediately, returns a session handle to the user, and returns the result code TM_EWOULDBLOCK.

After the test is started, the user should call tfTestUserExecute() in their main loop to execute an iteration of the test. This function will return TM_EWOULDBLOCK if the test is still in progress; any other return code indicates that the test is complete and the user should no longer call tfTestUserExecute().

For instance, a non-blocking test's main loop may look something like:

ttUserTestHandle    testHandle;
int                 testStarted;
testStarted = 0;
while (1)
    if (testStarted == 0)
* Attempt to send 25 UDP buffers, of 500 bytes each, to 
* remote host at port 9. This should be done in 
* non-blocking mode, * using the Treck Zero 
* Copy socket extensions.
        errorCode = tfTestTreck(TM_TEST_UDP_SEND,
                                TM_TEST_FLAG_NONBLOCKING |
        testStarted = 1;
        errorCode = tfTestUserExecute(testHandle);
        if (errorCode != TM_EWOULDBLOCK)
    if (tfCheckInterface(interfaceHandle) == TM_ENOERROR)

Data Validation

There are two flags that can be used to validate that incoming and outgoing data is correct. TM_TEST_FLAG_FILL_DATA will fill any outgoing data with any incrementing byte pattern of 0x00, 0x01 . 0xFF. The remote host receiving data can then validate that the incoming data matches this pattern.

The flag TM_TEST_FLAG_VALIDATE performs the inverse operation: it verifies that any received data matches this 0x00, 0x01 . 0xFF pattern. If any validation fails, the test will return with a TM_EIO error code.

These two flags can be used in a variety of ways to validate data. For instance, if an echo test is being performed, setting both of these flags will verify that both incoming and outgoing data is correct. Another example application of these flags is when the Treck test suite is being run between two devices, one device could run the TM_TEST_TCP_SEND test with the TM_TEST_FLAG_FILL_DATA option set, and the other device could run the TM_TEST_TCP_RECV test with the TM_TEST_FLAG_VALIDATE option set, and vice versa.

Random Testing Mode

When the TM_TEST_FLAG_RANDOM option is set, tfTestTreck() will execute a random client test, with random parameters. The test type is chosen from the set of send send tests (TM_TEST_UDP_SEND, TM_TEST_TCP_SEND), echo tests (TM_UDP_ECHO_CLIENT, TM_TCP_ECHO_CLIENT) and the TCP connect test (TM_TEST_TCP_CONNECT). If a send or TCP connect test is chosen, it will send data to port 9 of the remote host; if an echo test is chosen it will echo data with port 7. The test will be executed the number of times specified in the parameter 'testCount'.

A random data length is also chosen and is no larger than the data length specified in parameter dataSize. Unless IP fragmentation is enabled, the data length should be no larger than the MTU of the device, less the space for the UDP & IP headers (1472 for Ethernet, as well as most other link layers) in case a UDP test is chosen.

Random options (flags) are chosen appropriately for the selected test. The exception to this is the TM_TEST_FLAG_NONBLOCKING flag which remains set to the value passed in by the user.

Function Calls

Table of Contents >> Application Reference