You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that a response to a request from a remote device was being retried 10 or 20 seconds after failing by the TransactionManager. This makes me wonder if it is a good idea to retry responses...
The NCP should retry at the APS/MAC layers - this happens quickly.
If a node has sent a message, and has not received a response within some time (probably in the order of 8 seconds due to sleepy device timing) it will likely give up or resend the request. Either way, it won't then be expecting the response to the original message with the original APS transaction ID. Therefore, re-queuing the response is likely just adding to congestion.
IIRC we already handle DefaultResponses like this - send and forget.
Below is an example - we see transaction 9C being resent much later. Note that this is a filtered log - this is a large network during startup when there is a lot happening (probably too much!).
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I noticed that a response to a request from a remote device was being retried 10 or 20 seconds after failing by the
TransactionManager
. This makes me wonder if it is a good idea to retry responses...The NCP should retry at the APS/MAC layers - this happens quickly.
If a node has sent a message, and has not received a response within some time (probably in the order of 8 seconds due to sleepy device timing) it will likely give up or resend the request. Either way, it won't then be expecting the response to the original message with the original APS transaction ID. Therefore, re-queuing the response is likely just adding to congestion.
IIRC we already handle
DefaultResponse
s like this - send and forget.Below is an example - we see transaction
9C
being resent much later. Note that this is a filtered log - this is a large network during startup when there is a lot happening (probably too much!).The text was updated successfully, but these errors were encountered: