Description
Is your enhancement proposal related to a problem? Please describe.
The Connection Manager allows application to control the state of the network interface.
One connectivity mode supported is the one-shot connection, where the manager attempts to connect for a certain duration, but gives up if the connection cannot be found in a certain time period. If the connection is found, it is notified to the system through NET_EVENT_L4_CONNECTED which can trigger an arbitrary number of actions.
For example:
- SNTP time sync
- COAP file downloads/uploads
- Arbitrary socket operations
Each of these actions can occur in software modules entirely unrelated to the code that initially called conn_mgr_connect.
The problem is that once conn_mgr_if_connect is run and succeeds, how does the application know when the network interface can safely be disconnected with conn_mgr_if_disconnect?
Describe the solution you'd like
Ideally this should occur as soon as each module is done with the interface (with a pm_device_runtime_get/put approach) but this would be a very intrusive change throughout the tree.
An alternative is a keep-alive mechanism, where the Connection Manager can be instructed to keep the interface in the connected state until N seconds have passed since a data packet has been transmitted or received over the interface.
While not an optimal solution in terms of power, it is vastly simpler in terms of required software, and all new and existing networking users are automatically supported.
Describe alternatives you've considered
Coordinating all networking interface users and manually disconnecting the interface from the same context that originally called conn_mgr_if_connect. This approach does not scale and requires the introduction of software hooks throughout an application.
Additional context
The question is how to get the knowledge of transmitted/received packets into the Connection Manager. Currently events come in through the net_mgmt API, but that API adds substantial overhead in terms of allocating events and pushing them to queues to be processed in a dedicated thread, when all that needs to happen is a k_work_reschedule when a packet is transmitted or received.