A useful addition to the net_entity class is to provide a way to apply a function object to all current IO interfaces active for the net entity. For a TCP connector it would allow sending data to the single (if present) TCP connection, for a TCP acceptor it would allow sending to all (0 to N) TCP connections (and for UDP it would be similar to the TCP connector).

A design decision will need to be made to either 1) provide a method that returns a list of active io_interface objects; or 2) provide a method that takes a function object to be invoked with each active io_interface.

By using an internal std::variant, the basic_net_entity class template can become a non-template. This simplifies application logic, allowing generic handling of TCP connectors, TCP acceptors, and UDP entities.

There is a "TODO" in the net_ip/detail/udp_entity_io.hpp file that needs to be analyzed and implemented. The current code only supports IPv4 UDP datagrams, and this needs to be generalized for both IPv4 and IPv6.

The std::expected feature, which is likely to be in C++ 20, adds some significant improvements to the way errors are handled and reported. This is significant in chops--net-ip. This issue is to integrate std::expected (an early non-standard version, probably from Martin Moene) into the codebase and design.

Currently the start_io methods of the basic_io_interface class template offer two ways to start a binary TCP data flow - either with an application supplied message frame, or with fixed size messages. A "simple variable length message" component is defined, which implements a very common use case - binary messages with a fixed size header containing a message length, and a variable length message body.

The "simple variable length message framing" is such as common use case that it should be directly supported by the Chops Net IP core library instead of being offered as a component. Note that this is a specific implementation of the message frame, so start_io can simply use a small functor class and pass it to the generalized start_io call.

An alternative to output queues for outgoing data is to let applications send a message or buffer one at a time with some form of notification when each write completes. This would require a send method that returns a std::future, which resolves when the write completes. Discussion is needed as to whether the application would be completely responsible for buffer lifetime management, or whether we require some form of reference count or move (or similar) for the output buffer.

Chops Net IP would need to track whether a write is in progress or not. The library should prevent applications from more than one write at a time (on a given connection).

Currently the basic_io_interface class template provides (primarily) two sets of operations - methods for starting and stopping io, and sending data. The application code for these two sets of operations is distinct, different, and may be (typically will be) in different subsystems.

By splitting the basic_io_interface class into two classes, it separates the functionality into more logical responsibilities. It also allows a performance improvement for sending data, as the basic_io_output class can keep a pointer or reference to the IO handler, so that a weak_ptr does not have to be locked into a shared_ptr for every send.

Enhance the unit tests with command line processing, so variable amounts of data can be generated.

As of April 2019 outgoing buffers are hard-coded to const-shared-buffer. This could be templatized, allowing application code to use other types for outgoing buffers. However, the hard constraint on the type is that the lifetime of the underlying data buffer must be valid until notification is received within chops-net-ip that the data has been delivered. const-shared-buffer is a reference counted buffer, which satisfies this constraint. Buffers that move may also satisfy this constraint, although some analysis needs to be performed. Static / global data buffers also satisfy the constraint, although then it is up to the application to manage which static / global buffer is being used or not.

Making this design change will affect many portions of the code and API, so this is not a simple or trivial redesign.

Currently the container inside the net_ip class is a std::vector, which is a good default. However, some applications may wish to use a different container, or may wish to use statically allocated memory instead of a dynamic sized container (e.g. in a small embedded environment).

The container type could be a template parameter on the class (changing net_ip into a class template instead of a regular class).

This issue is similar to the other Chops Net IP issues where we are providing more flexibility in the container and buffer types.

There is a "TODO" in the net_ip/detail/tcp_connector.hpp file that needs to be analyzed and implemented as appropriate. Specifically, an error on connect might be due to multiple reasons and different error branches taken. In addition, the handler may be shutting down.

The chops-net-ip API exposes Asio constructs in multiple places (e.g. an Asio endpoint). Consider a very light wrapper over these so that the API is only chops-net-ip (or std). An easy way to accomplish this might be with using declarations.

Shutting down has lingering object cleanup issues. Investigate and improve shutdown logic. This may include using "post to the executor" logic instead of directly calling state change callbacks.

Describe the bug
When the program successfully exits, there are multiple memory allocations that have not been deallocated.

To Reproduce
g++ -std=c++17 -g3 -fsanitize=address (etc)
OR
valgrind --tool=memcheck --leak-check=yes ./a.out

Expected behavior
No memory leaks should be present

Desktop:

• OS: [Ubuntu Linux 13.04]
• Compiler [g++ 7.3]
• Version [1.0]

Currently there is an overload of the make_tcp_connector method in the net_ip class for const char*. This is so that calling make_tcp_connector with two C style strings does not match the make_tcp_connector method that takes a beginning and end iterator. A const char* can be an iterator, and the compiler matches that before doing an implicit conversion and matching the method that takes std::string_view (which is the method that should be matched).

The iterator version of make_tcp_connector can be disabled through std::enable_if matching on const char* (or char*), which then leaves only the std::string_view method as a matching method. This should be implemented to simplify the API.

A "Hello World" type of example tutorial is needed. This fits into the bigger picture of the missing "middle layer" of documentation - tutorials, how-to's, etc.

An in-depth tutorial is needed, explaining the layers of the software, how they fit together, the various flavors of how to use the main pieces of the library. Appropriate diagrams are also needed.

The Chops Net IP library has a set of core classes and functions, the minimum feature set needed for a cohesive library. In addition, there is a "component" directory under "net_ip" that contains classes and functions layered on top of the core set. The functionality in "component" packages up commonly needed use cases.

The code in the "component" directory should be more visible. The directory could be pushed up to be parallel to the "net_ip" directory. Alternatively, the contents could be split out into a separate repository.

Pros and cons:

1. Push "component" directory up one level, keep it in the chops_net_ip repo:

• work to do: small amount of restructuring of production and test (and possibly example) code
• pros: keeps component code in the same repo as core code, bugs and unit tests are tightly integrated
• cons: enhancements and bug fixes in the component code causes churn (more releases, for example) in the chops-net-ip repo.

2. Create a "chops-net-ip-component" repository:

• work to do: create repo, move existing component contents to new directory, change unit tests to not use component classes, only core facilities
• pros: makes a clear delineation between core functionality (in chops-net-ip) and functionality on top of the core classes; changes can be made to component while keeping core unchanged
• cons: unit tests will need some significant changes to not use component functionality

The earlier this decision is made, the better, so comments are very welcome, @tgill880, @oxenran - thanks!

Most of the UDP multicast framework is in place, but much of the implementation is missing.

As of April 2019, the outgoing queue is hard-coded in chops-net-ip (as std::queue). Consider making this more generic by templatizing the outgoing queue container. This will affect many aspects of the API, so this is not a simple or trivial redesign.

The utility-rack repo CMake files need various enhancements (debug / release option, sanitizer options, dependency management, additional CMake file refactoring and improvements). Bring these changes to the chops-net-ip repo.

The TCP connector provides a timeout parameter. However, this does not allow any application customization of how to manage timeouts. A common use case is an "exponential backoff" timeout algorithm, which increases the timeout if the connection attempt fails. This minimizes network traffic in the case where a remote host is not available, but the TCP connector should keep attempting to connect. Other algorithms to manage the timeout value should be allowed.

In addition to allowing the application to vary the timeout value, it should be possible for the application to specify "you've tried enough, quit trying to connect".

This is a better way for a TCP connector to stop connection attempts than another design enhancement - returning bool from the state change notification (which ended up being rejected for many implementation reasons).

A specific implementation of a timeout parameter policy would provide a default timeout policy by Chops Net IP (with some initialization parameters that would be useful for many applications), but the overall policy would be a function object allowing the application complete customization as needed.

Currently the TCP connector will not automatically attempt reconnects after a TCP connection failure. The application code is required to call "start" on the TCP connector net entity. The default behavior should be to automatically reconnect (assuming the reconnect timeout parameter is >0), and if the application does not want reconnects it can call "stop" on the net entity.

This requires careful thought about the use cases (both approaches are present in real world applications) and investigation of example and test code.

Currently the IO State Change function object callback does not return a value. Change the API to return a bool instead. If false, this results in the same as calling stop on the net_entity object. Returning true continues the net_entity processing.

True or false can be returned in both phases of the IO state change - on connection startup as well as connection teardown. Returning false allows the TCP connector to quit attempting to reconnect, or to bring down a TCP acceptor. For UDP net entities it is less useful, as the state change will only be invoked after stop or after an error.

Apps for distributed TCP and UDP testing will be very useful for verifying functional interaction both between operating systems (Windows, Linux, macOS, Raspbian, etc) as well as different hosts running the same operating system.

The first distributed test application will be named "Test Data Blaster" (T-DB) and consists of two (initially) executables - an executable that sends and receives test data, and a monitoring process which receives statistics and status messages and sends a shutdown message when initiated by the user.

The monitoring app is a server (acceptor), and both a C++ and Python version is expected. An initial console mode C++ monitoring app should be written, then later a GUI oriented monitoring app (Python or other similar language).

Initially TCP (only) will be supported, but at some point UDP will be supported.

More details for T-DB is in the README in the chops-net-ip/test/test_data_blaster directory.