Modification of the Thread message header

[QuentinD]

Hello

In my project, I am using the Thread network. I can communicate with all the devices on the network but there is a particular case that I don't know how to solve.

I have device '1' sending a confirmable message to device '2'. To resolve this request, device '2' needs time so I would like device '2' to send an ack and then later it will send the response. My problem is that I can't remove/add message ID and token to my messages.

I would like to be able to include the message ID in my first message (ack) and then the token in my second message. I tried the "otCoapMessageInitResponse(...)" function but it includes the token and the message ID in my frame and I can't remove either of them.

I also tried to create a new frame (otCoapNewMessage() + otCoapMessageInit()) and there I can add the token (otCoapMessageSetToken()) but I did not find a function to add an ID message...

Do you know how I should go about defining the content of my messages?

Thanks

[Simonr]

Hi

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

[QuentinD]

Thank you very much !