The CoAP client and server currently create and manage their own internal receive tasks when they are opened or started.
In some integration scenarios, receive handling is already performed outside of the library. In that case, the library should not create, cancel, or compile its internal receive tasks.
Current behavior
The CoAP client and server always create internal receive tasks:
coapclient_open() creates a receive task using osal_task_create().coapserver_listen() creates a receive task using osal_task_create().coapclient_stop() cancels the receive task using osal_task_cancel().coapserver_stop() cancels the receive task using osal_task_cancel().
The internal receive task functions are also always declared and compiled.
This makes it difficult to integrate the CoAP layer into applications where receiving is handled externally, for example by an application-specific task, event loop, scheduler, or platform integration layer.
Proposed change
Introduce a compile-time macro:
When this macro is defined, the CoAP client and server should not create, cancel, declare, or compile their internal receive tasks.
The internal receive task handling should be included only when USE_EXTERNAL_RECV_TASKS is not defined.
Affected areas:
- CoAP client receive task declaration
- CoAP client receive task creation
- CoAP client receive task cancellation
- CoAP client receive task implementation
- CoAP server receive task declaration
- CoAP server receive task creation
- CoAP server receive task cancellation
- CoAP server receive task implementation
Motivation
Some platforms or applications already operate receive handling outside of the CSMP/CoAP library.
In such cases, the library should provide a way to disable its internal receive tasks and allow the surrounding application to control how incoming packets are received and passed into the CoAP processing logic.
This improves integration flexibility and avoids duplicate receive loops or tasks.
Expected impact
When USE_EXTERNAL_RECV_TASKS is not defined, the existing behavior should remain unchanged.
When USE_EXTERNAL_RECV_TASKS is defined:
- the CoAP client does not create or cancel an internal receive task,
- the CoAP server does not create or cancel an internal receive task,
- the internal receive task functions are not compiled,
- receive handling is expected to be performed externally by the application or platform integration layer.
This is intended as a compile-time integration option and should not affect existing builds that do not define the macro.
The CoAP client and server currently create and manage their own internal receive tasks when they are opened or started.
In some integration scenarios, receive handling is already performed outside of the library. In that case, the library should not create, cancel, or compile its internal receive tasks.
Current behavior
The CoAP client and server always create internal receive tasks:
coapclient_open()creates a receive task usingosal_task_create().coapserver_listen()creates a receive task usingosal_task_create().coapclient_stop()cancels the receive task usingosal_task_cancel().coapserver_stop()cancels the receive task usingosal_task_cancel().The internal receive task functions are also always declared and compiled.
This makes it difficult to integrate the CoAP layer into applications where receiving is handled externally, for example by an application-specific task, event loop, scheduler, or platform integration layer.
Proposed change
Introduce a compile-time macro:
USE_EXTERNAL_RECV_TASKSWhen this macro is defined, the CoAP client and server should not create, cancel, declare, or compile their internal receive tasks.
The internal receive task handling should be included only when
USE_EXTERNAL_RECV_TASKSis not defined.Affected areas:
Motivation
Some platforms or applications already operate receive handling outside of the CSMP/CoAP library.
In such cases, the library should provide a way to disable its internal receive tasks and allow the surrounding application to control how incoming packets are received and passed into the CoAP processing logic.
This improves integration flexibility and avoids duplicate receive loops or tasks.
Expected impact
When
USE_EXTERNAL_RECV_TASKSis not defined, the existing behavior should remain unchanged.When
USE_EXTERNAL_RECV_TASKSis defined:This is intended as a compile-time integration option and should not affect existing builds that do not define the macro.