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
- For server use, allows an external module/application to register handlers for an array of incoming request paths.
- For client use, supports waiting for a response to multiple outstanding requests.
- Runs in a dedicated thread and supports non-blocking timeout handling for a request. A single instance handles both server and client use.
- 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().