search

Sub-IoT / Sub-IoT-Stack

Sub-IoT: Open Source Stack for Dash7 Alliance Protocol
https://sub-iot.github.io/Sub-IoT-Stack/
Other
150 stars 90 forks source link

D7AP: switch from SLAVE_PENDING_MASTER to MASTER instead of IDLE #131

Open sjorsdewit opened 2 years ago

sjorsdewit commented 2 years ago

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_MASTER switches to D7ASP_STATE_MASTER as 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.

glennergeerts commented 2 years ago

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

sjorsdewit commented 2 years ago

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.