Retrieve large amount of data from a Client on a memory limited device

[akrenz]

Hello everyone,
I have a memory limited device and want to retrieve a large amount of data via a "single" read/GET request.

To be more specific: I am trying to download a trace buffer (64kBytes in size) from an embedded device. For this I want to use object ID 20 (Log Event).

For this I wanted to use raw block-wise transfer which is working perfectly fine for Write Requests to the Device (firmware Update).
But it looks like it does not work for read/GET requests.

Is this expected to be supported by wakaama in any way? As far as I can see the client tries to malloc() the required amount of memory for the whole response (which is impossible on my device). It is also not possible to somehow indicate that the response must be done in a blockwise manner.

So I am currently trying to implement this on my own, but I am a little bit confused. Regarding who is initating the blockwise transfer in this case.

According to RFC 7959 (https://www.rfc-editor.org/rfc/rfc7959#section-2.1) a blockwise transfer from the Server should be done with BLOCK1 option for the GET request and the client responds with BLOCk2 responses.

• Should the Server at all indicate via BLOCK1 that it expects the read/GET to be done via blockwise transfer
• or should the Client automatically respond with BLOCK2 if the response is larger then the CHUNK_SIZE
  ?

As far as I understand section 2.3 of the RFC, the responder (in this case the Client) should automatically respond with BLOCK2 indicating that the response comes in blocks.

[sbernard31]

I can only answer about specification/RFC, someone else will maybe answer about specific point about Wakaama.

Maybe obvious but just in case, some clarification :

BLOCK1 is about transferring large payload in a request (e.g. PUT or POST)
BLOCK2 is about transferring large payload in a response (e.g. GET)

In CoAP :

• the client is the peer sending the request
• the server is the peer sending the response.

LWM2M client act as a CoAP client (e.g. register operation) but also as a CoAP server. (e.g. write operation)
This is also true for the LWM2M server.

So better to always prefix client/server by LWM2M or CoAP to avoid confusion.

In case of a LWM2M Read Request (CoAP GET request). LWM2M server acts as a CoAP client. LWM2M client as a CoAP server.

As you want to transfer a large payload of a response of CoAP GET request, BLOCK2 should be used.

Should the Server at all indicate via BLOCK1 that it expects the read/GET to be done via blockwise transfer

No, in that case you should not use BLOCK1.
But a CoAP client (in that case LWM2M server) can use BLOCK2 in the initial request to express the preferred block size :

To influence the block size used in a response, the requester MAY
also use the Block2 Option on the initial request, giving the desired
size, a block number of zero and an M bit of zero. A server MUST use
the block size indicated or a smaller size.

(source : https://www.rfc-editor.org/rfc/rfc7959#section-2.4)

or should the Client automatically respond with BLOCK2 if the response is larger then the CHUNK_SIZE

This is the common case but we see just above that the CoAP client also can ask for block2 transfer giving a small block size.

HTH

[LukasWoodtli]

I'm not so familiar with the client side of Wakaama. As far as I know, there is no raw BLOCK2 support there. I'ts also not always possible to implement. Some data types need to know the whole payload before it can be serialized.