arobenko
commented
4 years ago The major reason for the deviation is to simplify the implementation and support low memory consumption when compiling client for bare-metal application (which doesn't use dynamic memory allocation).
To the best of my understanding that MQTT-SN was designed for multiple use cases, including widely distributed mesh networks with multiple gateways and/or slow / unreliable I/O link. But I think this is not a typical setup. The typical (IMHO) one is 1 gateway residing in the same machine with MQTT broker and just forwards / translate messages between the protocols. If it's not your case and you do want to put multiple gateways in the same mesh network, then maybe my libraries are not 100% suitable for you.
Quote from spec:
Upon receiving a SEARCHGW message a gateway replies with a GWINFO message containing its id. Similarly, a client answers with a GWINFO message if it has at least one active gateway in its list of active gateways. If the client has multiple GWs in its list, it selects one GW out of its list and includes that information into the GWINFO message.
The intention of the protocol designers is to allow other clients that are already online and monitor existence of available gateways to respond on behalf of the gateway with the available information. In my implementation of the client, the latter doesn't respond with GWINFO on behalf of the gateway, which will respond anyways (or some other client implementation responds on behalf of the gateway)
Similar with my gateway, it is supposed (according to spec) to broadcast its information with GWINFO to save sending of SEARCHGW messages by some clients which just got online, but haven't started their gateway discovery process yet.
My understanding that my deviations from the spec may (not necessarily will) cause extra messages being exchanged and/or gateway discovery may take a bit more time, but there shouldn't be any interoperability problems with other implementations. However, there is only one way to find out, just try it. If you do want to use my libraries in the production environment and require strict adherence to the spec, then I can put some extra effort and implement the required functionality or you can dive into my code and see whether you can do it yourself.
Home it helps. Regards, Alex
What are the reasons/pros/cons of the deviations? Does it affect interoperability with other implementation of MQTT-SN? Is there a way to revert to standard MQTT-SN 1.2 behavior so devices using this implementation mesh with others without any subtle surprise? Thanks!