D7AP: switch from SLAVE_PENDING_MASTER to MASTER instead of IDLE #131
Conversation
A gateway may start sending data while a dialog with one of the nodes is still active. In this case the D7AP switches to D7ASP_STATE_SLAVE_PENDING_MASTER. When the dialog in the slave session completes, the master session would stay pending forever. This in turn would mean the ALP layer would 'leak' a transfer (completion callback never fires, command would never get deallocated). This patch modifies the D7ASP state machine so that D7ASP_STATE_SLAVE_PENDING_MASTER switches to D7ASP_STATE_MASTER as soon as the slave dialog closes. So for I have never been able to get a succesfull response to this master transaction, but at least the ALP layer recovers to a useable state.
| d7ap_stack_signal_slave_session_terminated(); | ||
|
|
||
| switch_state(D7ASP_STATE_MASTER); | ||
| d7ap_stack_signal_active_master_session(current_master_session.token); |
There was a problem hiding this comment.
As far as I can see now, this if not necessary is we would switch to D7ASP_STATE_PENDING_MASTER here (which is also accurate now that the slave dialog is terminated) and then call schedule_current_session(), which would flush the fifo's, activate the master dialog and call d7ap_stack_signal_active_master_session().
It is then basically the same logic as in the if (current_master_session.state == D7ASP_MASTER_SESSION_PENDING_DORMANT_TRIGGERED) branch, so the condition can just be expanded to include the (d7asp_state == D7ASP_STATE_SLAVE_PENDING_MASTER) condition I think?
|
Thanks for your bringing this up! You are right, the current code does not seem to handle the scenario of a master session being started while a slave session is in progress. I do wonder why you have not been able to get a successful response to the master transaction. Do you have any idea where it fails? Is the master request transmitted successfully? It would be good to add this scenario to the testsuite by the way. Not sure yet if it is easy to reproduce or too time-sensitive |
|
I'm also not sure why the master transaction failed, so far my assumption was that maybe it was not sent properly (collision with incoming unsolicited data?). I'm not familiar with the test suite but that sounds very interesting. It is indeed a bit timing-sensitive, but in our scenario we would almost always catch this situation: We had one node sending multiple unsolicited packets to our gateway. Our gateway would start a master transaction almost immediately after receiving the first packet. The next unsolicited packet from the node would then almost 100% conflict with the master transaction. |
In our application we have onee DASH7 node acting as a gateway, which both transmits (background) data and receives unsolicited data from other nodes. When both happen at the same time, something goes wrong as described below.
A gateway may start sending data while a dialog with one of the nodes is still active. In this case the D7AP switches to
D7ASP_STATE_SLAVE_PENDING_MASTER.When the dialog in the slave session completes, the master session would stay pending forever. This in turn would mean the ALP layer would 'leak' a transfer (completion callback never fires, command would never get deallocated).
This patch modifies the D7ASP state machine so that
D7ASP_STATE_SLAVE_PENDING_MASTERswitches toD7ASP_STATE_MASTERas soon as the slave dialog closes. So far I have never been able to get a successful response to this master transaction, but at least the ALP layer recovers to a usable state.