Handles unhandled-addressed-messages by generating an OIR reply. #798
Conversation
This is needed to avoid generating OIR replies due to missing handlers.
src/openlcb/IfImpl.hxx
Outdated
| /// matching the MTI / mask of any existing instantiated handler will end up | ||
| /// here. | ||
| /// | ||
| /// THe standard requires that when an addressed message is not handled by a |
| iface()->addressed_message_write_flow(), STATE(fill_oir)); | ||
| } | ||
|
|
||
| Action fill_oir() |
There was a problem hiding this comment.
Could we add Doxygen header blocks to this method, and the others that are undocumented in this file?
src/openlcb/IfImpl.hxx
Outdated
| /// This is an addressed message handler that catches errors (OIR and TDE) but | ||
| /// ignores them. While this sounds not super useful, it ensures that these | ||
| /// messages never trigger the UnhandledAddressedMessageHandler. | ||
| class NullErrorHandler : public IncomingMessageStateFlow |
There was a problem hiding this comment.
This does seem super not useful because the party that initiated the interaction will not be notified, it just times out. Should we have some way of notifying the initiator of the interaction? Perhaps at least file this as an enhancement request issue?
There was a problem hiding this comment.
Handlers that are registered are independent of each other, even if they listen to the same MTI. So if a particular component wants to know about OIR and TDE, it can (and should) register handlers for them. There are some examples of this, such as the PIPClient: https://github.com/bakerstu/openmrn/blob/master/src/openlcb/PIPClient.hxx#L159
There can be more than one handler for a given MTI. If there are multiple handlers for OIR/TDE, then they will each get the message (in a separate Buffer).
As a conclusion, the existence of this component has nothing to do with whether any other component chooses to listen to and act on OIR/TDE. It only needs said other component to write the code for handling the error messages. Note that this is typically interesting for client/UI components, not for services. Most of our code is service implementations.
There was a problem hiding this comment.
I actually deleted this handler and replaced it with an if (mti != OIR && mti != TDE) in the other handler. This has the same result but takes less RAM and FLASH space.
incoming unhandled error message (OIR and TDE).
* master: (76 commits) Fixes some compile errors in nucleo and bracz.acc. ESP-IDF CMakeLists (#800) BLE Basic Infrastructure (#788) Handles unhandled-addressed-messages by generating an OIR reply. (#798) Adds factory reset handler to linux:io_board. (#797) Fixes a standards compliance issue with the alias conflict handler. (#793) Bug fixes in DataBuffer (#791) Fixes race conditions in HubDeviceSelect. (#795) Fixes missing translation of enums when reading the security mode from a simplelink profile. (#796) Fixes flaky IfCanStress.test. (#794) Pin esp32 platform to 2.0.x (#792) Fixes detecting EOF in the memory config protocol handler. (#789) Adds a new hub application using DirectHub (#761) High-performance hub component for dealing with many sockets and high throughput (#760) Fix build of esp8266 train implementation. Removes unnecessary includes that might not exist on an embedded compiler. Fix compilation of TempFile under esp8266. Add libatomic to esp8266 nonos target. Fix compile errors in time_client app. Fixes in file memory space: (#786) ...
This PR fixes a stadnards compliance issue. The standard requires that when an addressed message arrives for a node which is not equipped for handling said message (including any unknown but addressed MTI arriving), then an Optional IOnteraction Rejected (OIR) message has to be sent back to the originating node, identifying that this target node is not able to handle that message.
Fixes some bugs exposed by this behavior.