Adding to T-DB README.

Author: cliffg-softwarelibre

test/test_data_blaster/README.md

@@ -1,12 +1,12 @@
 # Test Data Blaster
 
-The Test Data Blaster (T-DB) is an application suite that performs distributed testing, both TCP and UDP (currently the UDP portion is not implemented). There are multiple binaries in the suite:
+The Test Data Blaster (T-DB) is a set of binaries that performs both TCP and UDP distributed testing (currently the UDP portion is not implemented). There are multiple binaries in the suite:
 - Data sender / receiver (DSR), a TCP and (future) UDP version
 - Statistics and logging monitor, a C++ and (future) Python version
 
-A single instance of the monitor shows statistics from the DSR instances. The monitor is also responsible for shutting down the DSRs. Multiple DSR instances are typically running at the same time. Each TCP DSR instance can be configured for multiple TCP connectors and multiple TCP acceptors at the same time. Each (future) UDP DSR can be configured for multiple senders and receivers at the same time.
+Multiple data sender / receiver (DSR) instances are running at the same time (at least two must be running for sending and receiving data). Each TCP DSR instance can be configured for multiple TCP connectors and multiple TCP acceptors at the same time. Each (future) UDP DSR can be configured for multiple senders and receivers at the same time.
 
-The same monitor instance can be run for both TCP and UDP (the messages sent to the monitor from the DSRs specify whether the test data is being sent over TCP or UDP).
+A single instance of the monitor shows statistics from the DSR instances. The monitor is also responsible for shutting down the DSRs. The same monitor instance can be running for both TCP and UDP (the messages sent to the monitor from the DSRs specify whether the test data is being sent over TCP or UDP).
 
 While the DSRs are written in C++, the monitor app can be written in any language (and both a C++ and Python version is expected, with the Python version having a simple GUI display). The monitor message definition is text only, so binary endianness is not a factor.
 
@@ -26,19 +26,19 @@ All of the C++ components can be built using CMake.
 
 ## Internals and Design
 
-Having separate code bases (and executables) for the TCP and UDP DSRs simplifies the command line parameters as well as the internal logic. There is no specific technical reason why the DSR couldn't handle both TCP and UDP, but the DSR command line is complicated enough as is
+Having separate code bases (and executables) for the TCP and UDP DSRs simplifies the command line parameters as well as the internal logic. There is no specific technical reason why the DSR couldn't handle both TCP and UDP, but the DSR command line is already complicated enough.
 
-There is (obviously) common code between all of the T-DB C++ components, some from the `shared_test` directory (i.e. shared with the Chops Net IP unit tests), and some factored out in this (`test_data_blaster`) directory.
+There is (obviously) common code between all of the T-DB C++ components, some from the `shared_test` directory (i.e. code that is shared with the Chops Net IP unit tests), and some factored out in this (`test_data_blaster`) directory.
 
 ### Monitor Process
 
-The T-DB Monitor is run as a server (only). It accepts TCP connections on one port, each connection corresponding to one instance of either a TCP DSR or a UDP DSR.
+The T-DB Monitor is run as a TCP acceptor (server) only. It accepts TCP connections on one port, each connection corresponding to one instance of either a TCP DSR or a UDP DSR.
 
 There are no "begin" or "end" data messages that the monitor has to process, a new incoming TCP connection is the indication that a new DSR instance has started, and the end of the TCP connection is the indication that the DSR instance has ended.
 
 The DSR will not send a monitor message for every test message sent between DSR instances. A "modulo" command line parameter specifies how often a monitor message will be sent (for each test data set). (A modulo of 1 would generate one monitor message per test data set message.)
 
-The monitor process will notify all DSR processes to shutdown by sending a shutdown message through each monitor connection. The monitor process will have a user initiated way to send the shutdown messages and end the monitor process.
+The monitor process will notify all DSR processes to shutdown by sending a shutdown message through each monitor connection. The monitor process will have a user initiated mechanism to send the shutdown messages and end the monitor process.
 
 #### Monitor Message Definition
 
@@ -65,7 +65,9 @@ The shutdown message is the only message sent from the monitor to the DSRs and h
 
 Each DSR instance can start multiple TCP connectors and multiple TCP acceptors as provided via the command line arguments.
 
-If the DSR instance is configured to send messages (send count > 0), messages are sent when a connection is made. For TCP connectors this is when the connect succeeds. For acceptors it is when each incoming connection is made. Each connection will send out the full set of test messages.
+If the DSR instance is configured to send messages (send count > 0), messages are sent when a connection is made. For TCP connectors this is when the connect succeeds. For acceptors it is when each incoming connection is made. Each connection will send out the full set of test messages with a delay between each message (the delay can be 0 for full message blasting).
+
+If the "reply" command line parameter is set, an incoming message is reflected back to the sender.
 
 Degenerate configurations are possible, with infinite message loops or where connection and shutdown timing is not clear. No special coding is in the T-DB to protect for bad configurations.