When a request is sent to receive multiple blocks by setting this config parameter(NUM_OF_BLOCKS_REQUESTED), ota agent should not request data blocks(/publish other data block requests) after receiving single data block. The subsequent request for data blocks should be sent after receiving the requested num of blocks.
As per my understanding and older ota implementation, it should behave as explained below:
If ota agent task fails to receive the specified blocks after a while(use a timer to timeout if needed) only then submit the new request.
Right now the request to receive another block is triggered immediately after receiving one data block.
Is this intended?
Another question is about out of order block reception. Does DATA_TYPE_JSON handle out of order reception. I do not see a bitmap for JSON data type but it is present in DATA_TYPE_CBOR
Yes - This is due to the OTA agent library having the ‘request momentum’ which it tracks. The idea behind this is to keep as many requests in flight as possible to most quickly download the OTA update. I wasn’t around for this libraries writing but I would think the idea was to download as quickly as possible as IoT connectivity can be intermittent.
Where are you seeing this? I must not be searching the right term in the library. Looking through the old library it appears that the control messages - think job document, control flow messaging - is done through JSON messages. The actual OTA file appears to be passed over only CBOR. This would explain why the bitmap is only used for CBOR packages as only these OTA file blocks need to be sequenced.
I do not see otaconfigMAX_NUM_REQUEST_MOMENTUM being used anywhere. And the request are submitted after receiving the previous one. So there is no momentum being monitored.
Request momentum was something in the old OTA agent library. It is not present in any of the modular OTA examples.
Now I see when you were asking
Right now the request to receive another block is triggered immediately after receiving one data block.
Is this intended?
that you were talking about the new, modular OTA agent example. In this case, I don’t think significant time was put into request pattern optimization. The OTA agent example is more supposed to showcase how you could implement something along the same lines as the old OTA agent with the modular OTA libraries.
I’ll create a Github issue so that we do not forget this request but it might be a little while before we get to implementing it.
I don’t believe either data type have a bitmap to deal with multiple blocks coming in unordered. As mentioned on Bitmap in Modular OTA example, I’ve come up with this code change which has a quick and dirty way of handling multiple blocks.
At the end of the day - these OTA agent orchestrator example exists to showcase how you could implement something along the same lines as the old OTA agent with the modular OTA libraries.
We don’t recommend using the OTA agent pattern given in our previous library OR in the OTA agent orchestrator example. If you can describe your use case in some detail we should be able to point you in a better direction for how to accomplish device OTA updates.
My use case is to perform OTA within an acceptable time as the firmware binary is a bit large(around 5MB) and by acceptable time, I am trying to achieve full OTA within 10 minutes.
With a turn around time of ~1.8 sec for each blocks, the total time is way too large ~40 minutes. And an iot device might reconnect in between, might have a slower connection and it becomes practically impossible to OTA.
Is your network speed slow here? You could always request larger blocks so that you have a smaller portion of the total OTA transmission time being spent on network round trip transit.
It is also reasonable to create an OTA orchestrator which requests many data blocks at once and then handles them as they come in. Your orchestrator would need further enhancements to the rough bitmap-based multiblock solution I have posted above.