.NET and MQTT

[gvmson]

Does anybody have positive experience using .NET-based clients with MQTT? We tried 2 libraries that are linked to mqtt.org site, got both of the to work after some debugging, but they are both failing under comprehensive testing. I am also looking into Lotus Expeditor, but not sure about it's licensing terms. Any feedback or pointing into "right" direction would be appreciated. 

George

[Nicholas O'Leary]

Hi George,

I can only vouch for the .NET client included in Lotus Expeditor as it
was my team that produced it - although I've not used it very much
myself.

Regards,
Nick

> --
> To learn more about MQTT please visit http://mqtt.org
>
> To post to this group, send email to mq...@googlegroups.com
> To unsubscribe from this group, send email to
> mqtt+uns...@googlegroups.com
>
> For more options, visit this group at
> http://groups.google.com/group/mqtt

[Andy Piper]

Hi George

I'm sure that the Lotus Expeditor client is commercial software so at least there you have the ability to ask the vendor if it does not behave as expected.

Have you been able to contact the authors of the other .NET clients? As it says on the Software page on mqtt.org, the completeness and testedness/stability of any implementation listed there may, unfortunately, vary :-/

Andy

--
Andy Piper | Farnborough, Hampshire (UK)
blog: http://andypiper.co.uk | skype: andypiperuk
twitter: @andypiper | images: http://www.flickr.com/photos/andypiper

On Thursday, 5 April 2012 at 15:38, gvmson wrote:

> Does anybody have positive experience using .NET-based clients with MQTT? We tried 2 libraries that are linked to mqtt.org (http://mqtt.org) site, got both of the to work after some debugging, but they are both failing under comprehensive testing. I am also looking into Lotus Expeditor, but not sure about it's licensing terms. Any feedback or pointing into "right" direction would be appreciated.
>
> George
>

> --
> To learn more about MQTT please visit http://mqtt.org
>

> To post to this group, send email to mq...@googlegroups.com (mailto:mq...@googlegroups.com)

> To unsubscribe from this group, send email to

> mqtt+uns...@googlegroups.com (mailto:mqtt+uns...@googlegroups.com)

[George Michelson]

Andy,

Both of the .NET solutions were not touched for a while (2 years+), so I have not tried to reach out to authors, figuring out they lost interest by now. Both of the implementations "worked" as long as we tried to send a single message or subscribe to a topic, but failed more complicated tests. Actually, even simple tests did not work out of the box, possibly due to the differences in versions of Visual Studio. 

As far as Lotus Expeditor goes, I am having hard time figuring out if I can use it to develop software for re-distribution - I spoke to IBM's sales rep yesterday who was not able to answer that question and product specialist is still trying to reach me. Meanwhile I am trying to get information thru SoftChoice - our software vendor. 

[andyg (@geekscape)]

hi All,

On Thursday, 5 April 2012 at 15:38, gvmson wrote:

Does anybody have positive experience using .NET-based clients with MQTT? We tried 2 libraries that are linked to mqtt.org (http://mqtt.org) site, got both of the to work after some debugging, but they are both failing under comprehensive testing.

Andy Piper wrote:

Have you been able to contact the authors of the other .NET clients? As it says on the Software page on mqtt.org, the completeness and testedness/stability of any implementation listed there may, unfortunately, vary :-/

Perhaps the mqtt.org Software page should have the MQTT client libraries listed in a table that shows ...

- Latest version number and date published
- Some indication of quality, e.g green (known to be good), orange (not so solid), red (needs lots of work)
- Brief comment field that might say "worked as long as we tried to send a single message or subscribe to a topic, but failed more complicated tests"

Given that all the MQTT client libraries implement the specification to a greater or lesser degree, it would be good to make that situation clear.

I'm happy to do extensive testing of the Lua client library (especially if we have some reference tests) and to document what parts of the specification it does and does not implement (those details are already at the top of the Lua client library source code).

As more people use MQTT more seriously, then having robust clients will be fundamental to MQTT on-going success.

cheers andyg (@geekscape)

[Roger Light]

I think there is definite merit in this idea. It may be that the place for it is on the wiki though.

I'd be keen to see some criteria for inclusion on the software page. When there were relatively few implementations every one counted. Now we can afford to be pickier and as Andy says, robustness is important. The liblwmqtt library listed had 5 source code commits over two days in 2009 and nothing since. It can only write to the network. Reading isn't supported. I don't think it benefits anybody having it listed and endorsed. On a wiki page would be another matter though.

Cheers,

Roger

--

[Andy Piper]

I agree that the place for something like this would have to start off as being the wiki - primarily because I don't have time to go through the list on the Software page to try to test everything. We've got the start for such a page for server implementations http://mqtt.org/wiki/doku.php/server_support - that needs a lot of expansion.

I think the client version would need to show which levels of QoS are supported, whether MQTT v3.1 authentication is supported, the last known good date / version number, language/platform specific issues (e.g. does a C# client work on Mono), etc.

Thanks for your support and contributions!

Andy

--
Andy Piper | Farnborough, Hampshire (UK)
blog: http://andypiper.co.uk | skype: andypiperuk
twitter: @andypiper | images: http://www.flickr.com/photos/andypiper

On Friday, 6 April 2012 at 00:38, Roger Light wrote:

> I think there is definite merit in this idea. It may be that the place for it is on the wiki though.
> I'd be keen to see some criteria for inclusion on the software page. When there were relatively few implementations every one counted. Now we can afford to be pickier and as Andy says, robustness is important. The liblwmqtt library listed had 5 source code commits over two days in 2009 and nothing since. It can only write to the network. Reading isn't supported. I don't think it benefits anybody having it listed and endorsed. On a wiki page would be another matter though.
> Cheers,
> Roger

> On Apr 5, 2012 10:37 PM, "andyg (@geekscape)" <an...@geekscape.org (mailto:an...@geekscape.org)> wrote:
> > hi All,
> >
> > On Thursday, 5 April 2012 at 15:38, gvmson wrote:

> > > > Does anybody have positive experience using .NET-based clients with MQTT? We tried 2 libraries that are linked to mqtt.org (http://mqtt.org/) (http://mqtt.org (http://mqtt.org/)) site, got both of the to work after some debugging, but they are both failing under comprehensive testing.
> > >
> >
> >
> > Andy Piper wrote:
> > > > Have you been able to contact the authors of the other .NET clients? As it says on the Software page on mqtt.org (http://mqtt.org), the completeness and testedness/stability of any implementation listed there may, unfortunately, vary :-/
> > >
> >
> >
> > Perhaps the mqtt.org (http://mqtt.org) Software page should have the MQTT client libraries listed in a table that shows ...

> >
> > - Latest version number and date published
> > - Some indication of quality, e.g green (known to be good), orange (not so solid), red (needs lots of work)
> > - Brief comment field that might say "worked as long as we tried to send a single message or subscribe to a topic, but failed more complicated tests"
> >
> > Given that all the MQTT client libraries implement the specification to a greater or lesser degree, it would be good to make that situation clear.
> >
> > I'm happy to do extensive testing of the Lua client library (especially if we have some reference tests) and to document what parts of the specification it does and does not implement (those details are already at the top of the Lua client library source code).
> >
> > As more people use MQTT more seriously, then having robust clients will be fundamental to MQTT on-going success.
> >
> > cheers andyg (@geekscape)
> > --
> > To learn more about MQTT please visit http://mqtt.org
> >

> > To post to this group, send email to mq...@googlegroups.com (mailto:mq...@googlegroups.com)

> > To unsubscribe from this group, send email to

> > mqtt+uns...@googlegroups.com (mailto:mqtt%2Bunsu...@googlegroups.com)

> >
> > For more options, visit this group at
> > http://groups.google.com/group/mqtt
>

> --
> To learn more about MQTT please visit http://mqtt.org
>

> To post to this group, send email to mq...@googlegroups.com (mailto:mq...@googlegroups.com)

> To unsubscribe from this group, send email to

> mqtt+uns...@googlegroups.com (mailto:mqtt+uns...@googlegroups.com)