Merge pull request #57 from connectivecpp/develop

doc updates, tweaked tcp connector test sizes

Author: cliffg-softwarelibre

doc/CMakeLists.txt

@@ -939,7 +939,6 @@ FILE_PATTERNS          = *.c \
                          *.qsf \
                          *.jpg \
                          *.png \
-                         *.svg \
                          *.ice
 
 # The RECURSIVE tag can be used to specify whether or not subdirectories should

doc/Doxyfile

@@ -15,9 +15,9 @@ The secondary criteria includes:
 - Highly scalable
 - Bi-directional data flow
 
-## Asio and C++ Networking TS
+## Asio and C++ Networking Standardization
 
-Asio provides the foundation and underlying asynchronous model for Chops Net IP. The C++ Networking TS is still in development, awaiting standardization and modularization of core components such as executors. Chops Net IP provides usage and abstraction advantages as outlined in the overview documentation.
+Asio provides the foundation and underlying asynchronous model for Chops Net IP. C++ standardization efforts for networking have been ongoing for years (over a decade), with a major part of the effort working on `std::execution` (which covers many areas besides networking). If a C++ networking standard becomes official, Chops Net IP and Asio will likely change accordingly.
 
 ## ACE
 

doc/lib_comparison.md

@@ -60,7 +60,7 @@ Even though an implicit state transition table exists within the Chops Net IP li
 
 Pro tip - Chops Net IP follows the implicit state model of the Asio library (and similar libraries) where state transitions are implemented through chaining function objects on asynchronous operations. Developers familiar with implicit or explicit state transition models will be familiar with the application model defined for Chops Net IP. Chops Net IP insulates the application from the intricacies of the Asio library and simplifies the state transition details.
 
-![Image of Chops Net IP objects and states](object_states_diagram.png)
+[Click for image of Chops Net IP objects and states](object_states_diagram.png)
 
 ## Constraints
 
@@ -132,9 +132,9 @@ Future versions of the library may have more move semantics and less reference c
 
 Most of the Chops Net IP public classes (`net_entity`, `basic_io_interface`, `basic_io_output`) use `std::weak_ptr` references to the internal reference counted objects. This means that application code which ignores state changes (e.g. a TCP connection that has ended) will have errors returned by the Chops Net IP library when trying to access a non-existent object (e.g. trying to send data through a TCP connection that has gone away). This is preferred to "dangling pointers" that result in process crashes or requiring the application to continually query the Chops Net IP library for state information.
 
-![Image of Chops Net IP Tcp Acceptor internal](tcp_acceptor_internal_diagram.png)
+[Click for image of Chops Net IP Tcp Acceptor internal](tcp_acceptor_internal_diagram.png)
 
-![Image of Chops Net IP Tcp Connector and UDP internal](tcp_connector_udp_internal_diagram.png)
+[Click for image of Chops Net IP Tcp Connector and UDP internal](tcp_connector_udp_internal_diagram.png)
 
 Where to provide the customization points in the API is one of the most crucial design choices. Using template parameters for function objects and passing them through call chains is preferred to storing the function object in a `std::function`. In general, performance critical paths, primarily reading and writing data, always use function objects passed through as template parameters, while less performance critical paths may use a `std::function`.
 
@@ -147,10 +147,9 @@ Many of the public methods that call into internal handlers use a `std::future`
 ## Future Directions
 
 - Strand design and support will be considered and likely implemented, allowing thread pools to be used for a given `net_ip` instance, instead of limiting it to a single thread.
-- Older compiler (along with older C++ standard) support is likely to be implemented, depending on availability and collaboration support.
+- Older compiler (along with older C++ standard) support may be implemented, depending on availability and collaboration support.
 - The outgoing queue container is likely to become a template parameter. This would allow circular buffers (ring spans) or other data structures to be used instead of the default `std::queue` (which is instantiated to use a `std::deque`).
 - The reference counted outgoing buffer type is likely to become a template parameter, allowing applications to use a different reference counting scheme, or a wrapper over some form of static memory (the requirement will be that the memory is valid while the write is in progress). Alternatively, a generic copy and move, versus reference counting, may be supported in future versions.
-- Containers used internally in Chops Net IP (other than the outgoing queue) may also be templatized. These include the container used in the TCP acceptor for TCP connection objects, and the container used in the `net_ip` object that holds all of the network entities.
 - SSL or TLS support may be added, depending on collaborators with expertise being available.
 - Additional protocols may be added, but would be in a separate library (Bluetooth, serial I/O, MQTT, etc). Chops Net IP focuses on TCP, UDP unicast, and UDP multicast support. If a reliable UDP multicast protocol is popular enough, support may be added.
 

doc/overview.md

@@ -1,12 +1,11 @@
 # Chops Net IP Release Status
 
-## Release 1.0
+## Release 1.x
 
-Release 1.0 is under development, expected in the first part of 2020. The functionality is already well tested under g++ and clang++ on Linux, MacOS, and Raspbian, but needs additional testing on other compilers and platforms including VC++ on Windows.
+(Fill in details.)
 
 ### Next Steps, ToDo's, Problems, and Constraints:
 
-- The CMake files (CMakeLists.txts, etc) are working but enhancements and improvements are needed. CMake is relatively new for the Connective C++ team and enhancement requests are welcome.
 - Code coverage tools have not been used on the codebase.
 - The Doxygen annotation is mostly complete, but additional tutorial content is needed.
 

doc/release.md

@@ -128,9 +128,10 @@ void start_stop_connector(asio::io_context& ioc, int interval, chops::net::err_w
   auto r1 = conn_ptr->start( no_start_io_state_chg, 
                              chops::net::make_error_func_with_wait_queue<chops::net::tcp_io>(err_wq));
   REQUIRE_FALSE(r1);
-  std::this_thread::sleep_for(std::chrono::milliseconds(interval));
+  std::this_thread::sleep_for(std::chrono::milliseconds(interval+500)); // at least half second pause
   auto r2 = conn_ptr->stop();
   REQUIRE_FALSE(r2);
+  std::this_thread::sleep_for(std::chrono::milliseconds(interval+200)); // pause for part of a sec
   auto r3 = conn_ptr->start( no_start_io_state_chg, 
                              chops::net::make_error_func_with_wait_queue<chops::net::tcp_io>(err_wq));
   REQUIRE (r3);
@@ -367,8 +368,8 @@ TEST_CASE ( "Tcp connector test, var len msgs, two-way, interval 30, 1 connector
 TEST_CASE ( "Tcp connector test, var len msgs, two-way, interval 0, 1 connector, many msgs", 
            "[tcp_conn] [var_len_msg] [two_way] [interval_0] [connectors_1]" ) {
 
-  perform_test ( make_msg_vec (make_variable_len_msg, "Yowser!", 'X', 50*num_msgs),
-                 make_fixed_size_msg_vec(50*num_msgs),
+  perform_test ( make_msg_vec (make_variable_len_msg, "Yowser!", 'X', 30*num_msgs),
+                 make_fixed_size_msg_vec(30*num_msgs),
                  true, 0, 1,
                  std::string_view(), make_empty_variable_len_msg() );
 
@@ -447,8 +448,8 @@ TEST_CASE ( "Tcp connector test, CR / LF msgs, two-way, interval 10, 5 connector
 TEST_CASE ( "Tcp connector test, CR / LF msgs, two-way, interval 0, 10 connectors, many msgs", 
            "[tcp_conn] [cr_lf_msg] [two_way] [interval_0] [connectors_10] [many]" ) {
 
-  perform_test ( make_msg_vec (make_cr_lf_text_msg, "Yes, yes, very fast!", 'F', 50*num_msgs),
-                 make_fixed_size_msg_vec(50*num_msgs),
+  perform_test ( make_msg_vec (make_cr_lf_text_msg, "Yes, yes, very fast!", 'F', 30*num_msgs),
+                 make_fixed_size_msg_vec(30*num_msgs),
                  true, 0, 10, 
                  std::string_view("\r\n"), make_empty_cr_lf_text_msg() );
 
@@ -468,7 +469,7 @@ TEST_CASE ( "Tcp connector test, LF msgs, one-way, interval 0, 15 connectors",
            "[tcp_conn] [lf_msg] [one_way] [interval_0] [connectors_15]" ) {
 
   perform_test ( make_msg_vec (make_lf_text_msg, "Excited fast!", 'F', 6*num_msgs),
-                 make_fixed_size_msg_vec(5*num_msgs),
+                 make_fixed_size_msg_vec(6*num_msgs),
                  false, 0, 15,
                  std::string_view("\n"), make_empty_lf_text_msg() );
 
@@ -477,8 +478,8 @@ TEST_CASE ( "Tcp connector test, LF msgs, one-way, interval 0, 15 connectors",
 TEST_CASE ( "Tcp connector test, LF msgs, two-way, interval 0, 15 connectors, many msgs", 
            "[tcp_conn] [lf_msg] [two_way] [interval_0] [connectors_15] [many]" ) {
 
-  perform_test ( make_msg_vec (make_lf_text_msg, "Super fast!", 'S', 40*num_msgs),
-                 make_fixed_size_msg_vec(40*num_msgs),
+  perform_test ( make_msg_vec (make_lf_text_msg, "Super fast!", 'S', 25*num_msgs),
+                 make_fixed_size_msg_vec(25*num_msgs),
                  true, 0, 15, 
                  std::string_view("\n"), make_empty_lf_text_msg() );