Closed spinarr closed 7 years ago
DpaHandler strictly checked the response according: If the response is asynchronous, i.e. it is not a response to the previously sent request, then the response code is marked by the highest bit set (STATUS_ASYNC_RESPONSE). If the flag isn't set it is considered as an error and the response is not passed to async handling.
It is always considered as async. BTW does it have simillar ASYNC flag?
DpaAsyncMessage is considered as high prio - in my understanding these messages are sent from nodes to inform about important unpredictable (that's why async] events within the network - reset of a node, wake up of a node triggered by move sensor or smoke detection, etc.
The message is sent to handling regardless of a pending transaction. It is not necessary to buffer it in this case as a user of clibdpa (daemon) has to register independent call-back function. It is in responsibility of the user to queue the messages to be sent to messaging systems (MQTT, MQ, ...)
Implemented via ac3d8bed1df66ba9e0251ebffbbadd6a50ecaf87 Note it is branch feature/AsyncProcessing @spinarr please verify in your deployment (TR producing async msgs)
{
"ctype": "dpa",
"type": "raw",
"request": "03 00 09 01 ff ff 00 00 00 04 04 ff 40 00 00 04 00",
"request_ts": "2017-10-02 13:24:59.539494",
"response": "",
"status": "ASYNC_REQUEST"
}
Sometimes I see ERROR_TIMEOUT for synchronous communication when there is ASYNC message at the same time. Looking into it.
Regarding ERROR_TIMEOUT there were missing DPA responses so there were sometimes RF collisions between coming DPA response and DPA async request in the test scenario.
I did not see anything else, any error message in the log.
It is fine for now.
There is only little improvement needed in json serializer for async_request. This is done in iqrf-daemon project.
There is no buffering if the transaction is in a progress right now. Will be improved.