Winsock Stress Test - ReceiveSend (Compact 2013)


The Winsock Stress Test strains Winsock and networking functionality by performing a large number of socket operations. The socket operations performed by this test may also stress the remainder of the networking stack, for example, when receiving and sending large amounts of data.

This test stresses the network stack by performing a large number of send or receive operations over a single connection. You can specify in the command line the number of megabytes (MB) of data to transmit. The test performs send and receive operations using random buffer sizes until the specified amount of data has been transferred. The test displays a message for each MB of data processed. The test can also display the status of each send or receive call.

You should run the server thread before or in the same command line as the client thread.

Test Prerequisites

Your device must meet the following requirements before you run this test.

There are no hardware prerequisites for Name Resolution Winsock Stress Test.

The following table shows the software requirements for the Name Resolution Winsock Stress Test.




Module that provides functions that generate random numbers, output data, and parse command lines. The netall.dll file must be located in the same directory as the test.


Name Resolution Winsock stress test application


This test has no subtests.

Setting Up the Test

This test has no additional requirements beyond the standard test environment setup.

Running the Test

The Name Resolution Winsock Stress Test does not use the Tux test harness. You must run this test manually via Platform Builder's command line prompt.

The Name Resolution Winsock Stress Test has the following command line options, which you can display via the command: s rsstres2_vX.exe /?

rsstres2_vX [-cIPAddress] [-bBytes] [-wMSWait] [-srutvh] [-mTotBytesLimit]




Specify the server to communicate with. (default: localhost)


Set port to use (default 40000)


Specify number of bytes per send. (randomly determined for each send if not specified)


Set total number of MBytes to transmit. (default: 1)


Time to wait (in milliseconds) between sends/recvs.


Run send thread


Run receive thread


Send and/or receive over datagram (UDP) sockets. [TCP is default]


Set max time for select to wait in seconds. (default: 10)


Set to verbose mode... data recv/send is printed to display.


Set to Deamon mode... recv thread is not closed upon client exit.


Version of IP to use 4, 6, or X (default: X)


local address to bind to for sending (default: implicit bind)


If specified, hard binding is used. Requires local bind for the send thread


Force data corruption check. - both sides have to use it - number of bytes in option b has to be multiple of 4.


Specify Min number of bytes per send.


Specify Max number of bytes per send.


Exit the Process while doing a Send/Receive (only for UDP)


close the socket (only valid with the -k option)


Don't call Select

In addition, you can specify the following command-line options to modify the behavior of the test. Add one of the command-line parameter to:




Redirect output to the console

-fl <filename>

Redirect output to a file

The following tables shows the test cases for the Name Resolution Winsock Stress Test.

Command Line


s rsstres2_vx -r -m2 -u

The following command line on the Windows CE-based device transfers 2 MB of data from a UPD client on the development computer to a server on the local Windows CE-based device.

You must also run the following command line on the development computer: rsstres2_vx -s -m2 -u -c<CE device> -z

Command Line


s rsstres2_vx -r -s -m200 -i4

The following command line on the Windows CE-based device performs a loopback transmission of 200 MB of data using IPv4.

Verifying the Test

During the running of the test, there should not be any consistent failure messages displayed. At the end of the test a summary of the tests run will be displayed.

Troubleshooting the Test

If you specify the computer names or addresses, ensure that they are correct and reachable.

Ensure that the device has an network connection.

If the send/receive fails, you can try adding some delay between iterations or try smaller number of bytes.

See Also

Other Resources

Networking - Ethernet Tests