UDP Test

This simple socket-based UDP client/server pair is intended to test the integrity of a UDP network connection using various sizes of data. It can be particularly useful in cases where there are DFS connectivity problems that seem network-related. If you see dramatic failures in this pair of test programs, then you may have network issues that are hurting DFS; but if the test programs work well, then the network is probably good enough for DFS.

The following files are provided:

The C code here should build on Solaris or on AIX with the supplied Makefiles or on Windows from the Visual C++ project files. There are also pre-built client and server binaries for all three operating systems.

To start the server, just run it like "sizeServer.xxx 1234", where "xxx" is either "aix" or "sol" or "win", depending on your server platform, and where 1234 is a port number for the server to use. Then start the client like "sizeClient.yyy server-machine-name 1234" where "yyy" is either "aix" or "sol", or "sizeClient.win server-machine-ipaddress 1234". The client will do writes of size 256 bytes, then 512, 1024, ..., 8192 bytes to the server; the server will respond by sending the data straight back to the client. The client will verify the integrity of the data when it returns. The whole thing is pretty simple-minded, but it can still serve as a basic continuity test with UDP writes of various sizes.

Sample output:

1. Start the server on an AIX machine (named cspool34, IP address 9.38.205.34): 

   # sizeServer.aix 6060 
   Server will listen on port 6060

2. Start the client (a Solaris machine with IP address 9.38.203.129): 

   # sizeClient.sol cspool34 6060
   Client connecting to 9.38.205.34, port 6060
   Client using local port 41684
   Size 256, iteration 1 of 3, character b...
     sent 256 bytes...
     received 256 bytes...
     content checks out.
   Size 256, iteration 2 of 3, character c...
     sent 256 bytes...
     received 256 bytes...
     content checks out.
   Size 256, iteration 3 of 3, character d...
     sent 256 bytes...
     received 256 bytes...
     content checks out.
   Size 512, iteration 1 of 3, character e...
     sent 512 bytes...
     received 512 bytes...
     content checks out.
   ...
   Size 4096, iteration 1 of 3, character n...
     sent 4096 bytes...
     received 4096 bytes...
     content checks out.
   Size 4096, iteration 2 of 3, character o...
     sent 4096 bytes...
     received -1 bytes...
     *** no data available to read
     received -1 bytes...
     *** no data available to read
   Size 4096, iteration 3 of 3, character p...
     sent 4096 bytes...
     received 4096 bytes...
     content checks out.
   ...
   Size 8192, iteration 3 of 3, character s...
     sent 8192 bytes...
     received 8192 bytes...
     content checks out.
   Done: 1 total errors; 17 successes (44288 bytes).

3. You'll see the following on the server while step 2 is in progress: 

   Received 256 bytes (first byte is 'b')...
     from 9.38.205.15 port 41684...
     sent 256 bytes back.
   Received 256 bytes (first byte is 'c')...
     from 9.38.205.15 port 41684...
     sent 256 bytes back.
   Received 256 bytes (first byte is 'd')...
     from 9.38.205.15 port 41684...
     sent 256 bytes back.
   Received 512 bytes (first byte is 'e')...
     from 9.38.205.15 port 41684...
     sent 512 bytes back.
   ...
   Received 4096 bytes (first byte is 'n')...
     from 9.38.205.15 port 41684...
     sent 4096 bytes back.
   Received 4096 bytes (first byte is 'o')...
     from 9.38.205.15 port 41684...
     sent 4096 bytes back.
   Received 4096 bytes (first byte is 'p')...
     from 9.38.205.15 port 41684...
     sent 4096 bytes back.
   ...
   Received 8192 bytes (first byte is 's')...
     from 9.38.205.15 port 41684...
     sent 8192 bytes back.

Note in the sample output above that one of the server's 4096-byte replies to the client seems to have gotten lost in the ether.

The server will stay up after the client has finished; you can use control-C to stop the server. For best results though, you should run the client three or four times against the same server before killing the server, to make sure you're getting consistent results. A high percentage of errors (say, more than 20%) or errors with a pattern to them (say, writes of a certain size always fail in one or both directions) may indicate network problems. But occasional intermittent failures, like the one in the example above, are no cause for concern -- they're normal when using UDP. (The DCE/DFS RPC facility is aware of this and will use acknowledgements and retries to work around it, like TCP does.)

Addendum: modified client to accept an optional third argument, the client-side port to use. Like this: 

   C:\>sizeClient.win 9.38.205.103 5050 2020
   Client connecting to 9.38.205.103, port 5050
   Client using local port 2020
   Size 256, iteration 1 of 3, character b...
     sent 256 bytes...
     received 256 bytes...

and on the server, you'll see something like: 

   Received 256 bytes (first byte is 'b')...
     from 9.38.198.36 port 2020...
     sent 256 bytes back.

This is useful in environments where firewalls restrict the allowable range of ports that are available to the client.