Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Items for Paho Roadmap



On Mon, 9 Nov 2015 at 07:23 Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Maybe you could open a bug, if you haven't already, describing the oddball things?

Not knowing the culture here, I'm always hesitant to open bugs for things which are not quite bugs, but are more related to defensive programming and robustness. Here is an example:

MQTTSNString allows a pointer+len or a null-terminated style cstring. It does not have a constructor which sets the values. However, if the user does not set all values, thinking one takes precedence over the other, they will get conflicting results. For example, writeMQTTSNString(...) will favour the lenstring style; if that field is set, it will ignore the value of the cstring. However, MQTTSNstrlen(...) favours cstring; if that field is set, it will ignore the lenstring style. So if only one of the fields is initialized, you'll get varied results because different functions favour different fields. This is not exactly a bug -- the calling code should have initialized both -- but it makes debugging difficult, especially since there is no ctor.

There are some more style issues; it would be nice if pointers which are only read from were const. 

Those are the ones off the top of my head.... I should probably take notes. If those are the sorts of things you would rather have bugs logged for, I'm happy to do so. If those are the sorts of things which just aggravate you, I don't want to to that :)
 

Have you looked at this gateway? https://github.com/ty4tw/MQTT-SN



I did, and tried it out. My client, not surprisingly, was sending lots of garbage to it, and it seemed to get in a 'stupid' state fairly easily under those conditions. I looked at the code it it appeared it would take some time to figure out, and in the interests of learning the protocol I wrote a python gateway. Well, am writing, it works on a very basic level and is easy to plug lots of debugging into to see where my client is insane. It should also, hopefully, scale reasonably well. Once it has Publish and subscribe at dos 1, I'll probably call it enough for the moment; currently it handles publish, and will do the subscribe, but not the publish back to the client yet, which isn't too hard, especially for non-wild card subscribes (where you don't need to register topics to the client). Once I get it all working well and feel very comfortable with the client, I may well revisit the above gateway, though my target platform for the gateway is plenty powerful enough to run the python one (pi or BBB)

PK

Back to the top