gcoap Features

gcoap uses nanocoap for base CoAP structs and functionality. In general, gcoap provides a higher-level interface to CoAP than nanocoap. The main differences are gcoap's single CoAP messaging hub approach and also a consistent, simple API for client requests and server responses.

Single CoAP messaging hub

1. For server use, allows an external module/application to register handlers for an array of incoming request paths.
2. For client use, supports waiting for a response to multiple outstanding requests.
3. Runs in a dedicated thread and supports non-blocking timeout handling for a request. A single instance handles both server and client use.
4. In effect, provides a single listening port, which supports RFC 6282 UDP port compression.

In other words, gcoap provides a single, reusable access point for CoAP messaging. On the server side, we were inspired by the Python microframeworks like Bottle or Flask. gcoap provides gcoap_register_listener() for an application to register resources. In contrast, as a server nanocoap is designed for a single, dedicated application. All resource callbacks must be specified within a single const array in the nanocoap_server example. On the client side, gcoap tracks a configurable number of open requests in an array. In contrast, nanocoap is focused on handling one request at a time in the nanocoap_get() function in nanocoap_sock.c.

Simple high-level API

• A payload-based request/response includes an ...init(), write the payload, and ...finish().
• A simple, no-payload request/response is a single function call.
• Consistent API between request and response.
• User is never expected to write a CoAP option for simple cases, at the cost of an extra memmove().