net: coap_client: streaming blockwise payloads

[bdunlay]

Is your enhancement proposal related to a problem? Please describe.

How can clients stream large payloads in blockwise uploads that otherwise could not fit in memory alone?

Today, the CoAP client initiates blockwise uploads strictly when the payload is larger than the configurable CONFIG_COAP_CLIENT_MESSAGE_SIZE, iterating on blocks of a fixed size offset in a buffer pointer. The payload pointer and size are provided in the initiating request.

Users may wish to not hold large payloads in memory, and instead stream them chunk by chunk.

Describe the solution you'd like

One solution might be to add a new member to the coap_client_request struct, something like coap_client_get_payload_t below, which if assigned would fill a buffer to a maximum length and return the number of bytes written. The payload would be written directly to the TX buffer.

/* returns >= 0 for number of bytes written, < 0 for error */
typedef int (*coap_get_payload_t)(uint8_t *payload, size_t len, void *user_data);

Example:

int get_my_payload(uint8_t *payload, size_t len, void *user_data) {
    struct my_ctx *ctx = user_data;
    return fs_read(ctx->my_file, payload, len);    
}

struct coap_client_request req = {
    .payload_cb = get_my_payload,
    .payload = NULL,
    .len = my_file.size,
    .user_data = ctx,
    ...
};

Describe alternatives you've considered

n/a

[boaks]

Today, the CoAP client initiates blockwise uploads

from other implementations (java Eclipse/Californium) this may be considered with two different modes/approaches:

• transparent (for payload, which exceeds a single request but is still rather small). Here the "stack" takes core of the blockwise stuff.
• application aware for payloads, which may get pretty large, e.g. firmware.

AFAIK, both works with the zephyr coap-client as well. You may just provider the block-options by the application and transfer then the payload split in small chunks.

Anyway two words from a couple of years experience:

• for small/medium payload, which fits in a small number of requests and takes only a few seconds to transfer, both BLOCK1 (PUT/POST) and BLOCK2 (GET/POST) works well.
• for larger payload it may be required to consider pauses and resuming such transfers. That works simpler for BLOCK2 (GET), but for BLOCK1 it was always much more pain, considering, that the identity may change with the ip-endpoint. The most servers I know will therefore cancel a stale BLOCK1 transfer in order to save resource and with that, a BLOCK1 resume will fail.