Skip to content

TestTCPConnect and TestTCPListen

Jump to bottom
jtluka edited this page Sep 10, 2013 · 3 revisions

1. Basic description

These two test modules are very similar and implement the client and server side of one test working with TCP connections. You can of course use only one of these tests if you have the other side of the TCP connection covered by something else. Due to similarity of these test modules, this page will contain the documentation of both.

TestTCPConnect spawns client(s) connecting to TCP port(s) defined by either port or port_range option. When connected, the client sends random bursts of random data to server. If cont option is set the connections are initiated again and data is sent to server until interrupted by the controller.

TestTCPListen spawns server(s) listening for TCP connection(s) on port(s) defined by port or port_range options. When client connects to the port, server reads the data sent and close the connection when no more data is available. If cont option is set the connection is reopened and server reads data again.

These test modules can be used to test the performance of the network under heavier loads of TCP traffic or to test the behaviour of a server machine when higher numbers of concurrent clients are connecting.

2. Options

Options for both of these test modules are very similar but there are slight differences.

The options accepted by TestTCPConnect are:

addr address to connect to. This option is mandatory.
port port to send data to. Either this option or the option port_range MUST be specified.
port_range ports to send data to, expects two values separated by either a comma or a hyphen. Either this option or the option port MUST be specified.
sleep sleep time between bursts, if undefined, the bursts are immediate
cont sets continuous mode of connecting, if set connections are infinitely re-spawned when closed.

The options accepted by TestTCPListen are:

addr address to bind to. This option is optional, if undefined listen on all ifaces.
port port to listen on. Either this option or the option port_range MUST be specified.
port_range ports to listen on, expects two values separated by either a comma or a hyphen. Either this option or the option port MUST be specified.
cont if set the listening port is reopened when the connection is closed

3. Usage Example

Since these modules nicely complement each other, the easiest way to use them is in one task. In the following recipe snippet we first run the server part and then follow it with the client part of the test. Both of these commands are being run in the background, this is because the modules are designed to test TCP connections while you manipulate other parts of the network at the same time.

<run module="TCPListen" machine="testmachine1" bg_id="test">
    <options>
        <option name="addr" value="{ip(testmachine1, testifc1)}"/>
        <option name="port_range" value="10000-10010"/>
        <option name="cont" value="True"/>
    </options>
</run>
<run module="TCPConnect" machine="testmachine2" bg_id="test2">
    <options>
        <option name="addr" value="{ip(testmachine1, testifc1)}"/>
        <option name="port_range" value="10000-10010"/>
        <option name="sleep" value="0.1"/>
    </options>
</run>
<wait machine="testmachine2" bg_id="test2"/>
<intr machine="testmachine1" bg_id="test"/>

4. Results

Using the commands from the previous section in a command sequence, you will receive similar results as in the following table.

29/01 09:55:57|       (127.0.0.1) INFO: Executing command: [type (test), machine_id (testmachine1), value (TCPListen), bg_id (test)]
29/01 09:55:55| (192.168.122.109) DEBUG: Running in background with id "test", pid "5987"
29/01 09:55:57|       (127.0.0.1) DEBUG: Result: {'passed': True}
29/01 09:55:57|       (127.0.0.1) INFO: Executing command: [type (test), machine_id (testmachine2), value (TCPConnect), bg_id (test2)]
29/01 09:55:56|  (192.168.122.30) DEBUG: Running in background with id "test2", pid "3118"
29/01 09:55:57|       (127.0.0.1) DEBUG: Result: {'passed': True}
29/01 09:55:57|       (127.0.0.1) INFO: Executing command: [type (wait), machine_id (testmachine2), value (test2)]
29/01 09:55:56|  (192.168.122.30) DEBUG: Waiting for background command with id "test2", pid "3118"
29/01 09:55:56|  (192.168.122.30) DEBUG: Waiting for workers ...
29/01 09:56:05|  (192.168.122.30) INFO: Connect: Finished ...
29/01 09:56:05|  (192.168.122.30) DEBUG: PASSED
29/01 09:56:06|       (127.0.0.1) DEBUG: Result: {'passed': True}
29/01 09:56:06|       (127.0.0.1) INFO: Executing command: [type (intr), machine_id (testmachine1), value (test)]
29/01 09:56:05| (192.168.122.109) DEBUG: Interrupting background command with id "test", pid "5987"
29/01 09:55:55| (192.168.122.109) DEBUG: Waiting for workers ...
29/01 09:56:05| (192.168.122.109) DEBUG: Listen: terminate called
29/01 09:56:05| (192.168.122.109) INFO: Handled 11 TCP connections.
29/01 09:56:05| (192.168.122.109) DEBUG: PASSED
29/01 09:56:06|       (127.0.0.1) DEBUG: Result: {'res_data': 'Handled 11 TCP connections.', 'passed': True}
29/01 09:56:06|       (127.0.0.1) INFO: Result data: 'Handled 11 TCP connections.'

If you are seeing less connections being handled than you expect, you can look into the logging information of each slave, where there is more detailed information about individual connections being received or refused.

Clone this wiki locally