CoAP-over-DTLS server front-end - binds a UDP port to a pool of DtlsConn + the CoAPs bridge. More...

#include "protocore_config.h"

Detailed Description

CoAP-over-DTLS server front-end - binds a UDP port to a pool of DtlsConn + the CoAPs bridge.

The socket / per-peer glue on top of pc_coaps_process(): it owns a fixed pool of DtlsConn handshake engines, binds the CoAPs UDP port (5684, coaps://) through the transport layer (pc_udp), routes each inbound datagram to the connection for its peer address (a new peer opens a pool slot), drives the DTLS 1.3 handshake and its retransmission timer, and hands established application records to pc_coap_server_process() through pc_coaps_process(). CoAP resources are registered with the existing pc_coap_server_add_resource() API; this module only carries them over DTLS, so a plaintext CoAP server (pc_coap_server_begin on :5683) and this secured one can run side by side over the same resources.

Threading (ESP32): pc_udp delivers datagrams on the lwIP thread, but the handshake engines must run on the server loop, so the UDP handler only copies each datagram into a lock-free ingest ring; pc_coaps_server_poll() (called from the loop) drains the ring, runs pc_coaps_process(), fires the PTO retransmission timer, and reaps idle or failed connections. The engines therefore only ever run in one context. On host builds there is no UDP; datagrams are injected with pc_coaps_server_ingest() and replies captured through an output sink, so the whole server is host-testable by shuttling byte buffers to an in-test DTLS client, exactly like pc_dtls_conn and pc_coaps_process themselves.

Constrained-friendly: unlike the HTTP/3 pool this is not PSRAM-gated - a small DtlsConn pool fits internal DRAM, which is the whole point of CoAP. Raise PC_COAPS_MAX_CONNS for more simultaneous peers (each slot is one DtlsConn handshake engine plus its per-connection key material).

Author: Douglas Quigg (dstroy0)

Date: 2026

Definition in file coaps_server.h.