Modification of the Thread message header

RE: Modification of the Thread message header

QuentinD — Tue, 14 Feb 2023 10:22:38 GMT

No you can close.

RE: Modification of the Thread message header

Simonr — Tue, 14 Feb 2023 09:59:46 GMT

Can we close this case then, or are there any follow-up questions from your end?

Best regards,

Simon

RE: Modification of the Thread message header

QuentinD — Mon, 13 Feb 2023 13:30:39 GMT

Thank you very much !

RE: Modification of the Thread message header

Simonr — Fri, 10 Feb 2023 07:11:42 GMT

Finally we have a thorough answer for your Quentin:

The proper flow of a separate response in CoAP for an application can be as follows (based on https://www.rfc-editor.org/rfc/rfc7252#section-5.2.2). This is also what we recommend:

Obtain token from received request
Create new message
Initialize message as ACK response with an empty message code. Use a function to set the same Message ID as in the request. According to the below code brief this also sets the same token, although that shouldn't matter when the initialized ACK response is empty.
Send ACK as a response to request (message ID is matching the request).
Process the proper response
Create new message
Set message token to be the same as obtained from the request
Add payload to the message if necessary
Initialize the message, this time not as a response. It should be of type CON or NON with the proper code
Send a message as a new request (where the token is matching the request).

Some more information about the flow and a helpful illustration showing how the token and message ID should match can be found here: https://www.rfc-editor.org/rfc/rfc7252#section-2.2

From client's side, the client should send the request, and after receiving an empty acknowledgement message, wait for new request message from server with a matching token.

Here is some pseudocode showing an example that only covers the most important points (the rest must be implemented according to your application's needs:

void processLongerResponse(otMessage *request, otMessageInfo *message_info)
{
        const uint8_t *token = otCoapMessageGetToken(request);
        uint8_t tokenLen = otCoapMessageGetTokenLength(request);
 
        otMessage *response1 = NULL;
 
        response1 = otCoapNewMessage(instancePtr, NULL);
 
        otCoapMessageInitResponse(response1, request, OT_COAP_TYPE_ACKNOWLEDGMENT, OT_COAP_CODE_EMPTY);
 
        // send ACK as response, for example using otCoapSendResponse(). hint: use message_info
 
        // process proper response
 
        otMessage *response2 = NULL;
 
        response2 = otCoapNewMessage(instancePtr, NULL);
 
        otCoapMessageSetToken(response2, token, tokenLen);
        // add payload to respone2 if needed
 
        otCoapMessageInit(response2, OT_COAP_TYPE_CONFIRMABLE, OT_COAP_CODE_VALID);
 
        // send as request, for example using otCoapSendRequest(). hint: usemessage_info
}

Best regards,

Simon

RE: Modification of the Thread message header

QuentinD — Wed, 08 Feb 2023 14:02:11 GMT

Ok
Thank you for your follow up

RE: Modification of the Thread message header

Simonr — Wed, 08 Feb 2023 13:42:41 GMT

I'm very sorry about the delay, but I wanted to let you know that we're still looking into this. It has taken longer than anticipated to get to the bottom of this and find a satisfactory reply for you.

Again, thank you for your patience!

Best regards,
Simon

RE: Modification of the Thread message header

QuentinD — Fri, 27 Jan 2023 09:01:23 GMT

Ok thank you

RE: Modification of the Thread message header

Simonr — Fri, 27 Jan 2023 08:18:37 GMT

Hi again Quentin

I'm sorry about the delayed response, but I haven't heard back from the developers on this yet, and have bumped the internal ticket again. I'll get back to you as soon as I hear from you.

Best regards,

Simon

RE: Modification of the Thread message header

QuentinD — Fri, 20 Jan 2023 10:26:47 GMT

Hello

I use nRF5 SDK for Thread and Zigbee.

Yes I know I could try to find an alternative to solve the problem but as it seems to me that the protocol allows to do it like that, I wanted to know if your SDK allowed it too.
What did your experts say?

Thank you

RE: Modification of the Thread message header

Simonr — Fri, 20 Jan 2023 09:52:52 GMT

Hi Quentin

Okay, so since you use SEGGER, I assume you're using the nRF5 SDK for Thread and Zigbee? Or are you using the nRF Connect SDK? You might need to send a confirmable request, that is ACKed to start processing, and then send a new request when you expect the processing to be complete.

Best regards,

Simon

RE: Modification of the Thread message header

QuentinD — Thu, 19 Jan 2023 09:12:18 GMT

Hello

I use SEGGER Embedded Studio for ARM V5.60a

The duration of time to respond to the message is variable but we are talking here about several seconds minimum (when device '2' receives the request, it must query several other devices on the network in order to retrieve information).

Just for your information on how the CoAP protocol works, I advise you to read pages 33 to 35 of the documentation (www.rfc-editor.org/.../rfc7252 )
When a device '1' sends a confirmable message to a device '2', this message must be acknowledged with the same message ID so that the device '1' does not automatically retransmit this message: it is why I have to quickly acknowledge the confirmable message in order to have a multiple messages retransmissions.
When we send a confirmable message to retrieve information (GET), we add a token in this message so that we can identify that the message received (containing this same token) is the response to a message we sent.

Thank you

RE: Modification of the Thread message header

Simonr — Thu, 19 Jan 2023 08:16:13 GMT

Hi Quentin

Sorry about the late response but I have to ask internally to get a good answer. I'm still waiting for a reply from our experts, but in the meantime. Can you add some details on what SDK and SDK version are you using for development? What exactly is it that takes time to resolve with your confirmable message, and how much time are we talking about here?

As an update from what I've been able to find. I'm not so sure you can split up the token and message ID, but rather send the confirmation message with the same ID as the ACK. I still need to hear from the experts to confirm whether this is the case though.

Best regards,

Simon