publishing mqtt message issue

[Gene]

Thinking is good.
Btw what do you mean hg is using a wildcard topic? Topic can be configured.

g.

[Wibo]

Hi Gene,

when HG subscribes it subscribes with #, it wants to see every message.
I know the current design needs it this way.

Let's say I want to use the same broker with an unique topic and send 5000 msg/s.
Every subscribed RPi and other weaker brothers will die.

It's not that I want to send so much data, it's just that I can remotely kill an RPi running HG just by sending a lot of messages to an mqtt broker.

Regards,
Wibo.

[Gene]

I understand that HG or whatever application subscribing # would receive lot of messages and so subject to flooding.
That's why I'm telling you that you can change the topic 

Cheers,
g.

[Wibo]

Hi Gene,

just a status update...
Writing my own software to accomplish my goal.
Later on I can start communicating with HG.
I'm still using MqttDotnet and it has surprising features.
I'm still in a early alpha phase, let you now when I have results.

Regards,
Wibo.

[Wibo]

Hi Gene,

have the results of the Dutch jury.

In the beginning the results were amazing, I had MqttDotnet running in my own project.
After some serious testing on win7 and writing some extensions like auto reconnect, I could disconnect network cables stop and start mqtt broker. Disconnecting network cables for not to long (30s) didn't result in lost messages, killing the broker did result in lost messages, but I can live with that.
The whole setup was self healing, auto reconnecting, etc.

I started testing on RPi and the results where dramatic.
After getting my own bugs out (thrown exceptions differ under mono) the MqttDotnet library acted terribly when disconnected. disconnecting network cables long enough or taking down the broker resulted in:
Not able to reconnect, unless the process was restarted.
Having a workerthread deep in MqttDotnet going nuclear eating all CPU cycles from one core untill the process was restarted.

While investigating the possible cause I saw to many TODO: in the multithreading area and other disturbing code.

Given up on MqttDotnet...

Spent 2 days to see if Microsoft Azure could be something, but I have a feeling that won't be a winner on RPi

Investigating ZeroMQ right now...
http://zeromq.org/intro:read-the-manual

Let you know the results...

Regards,
Wibo.

[Wibo]

Hi Gene,

I dropped ZeroMQ after playing with it for a week.
In fact there were 2 dotNet libraries and one of them was unstable.
The other one clrzmq was very stable, very modular, very mono/RPi compatible.

The problem was that I had to write to much code and needed a very good understanding of the library design. I didn't want to spend so much time in writing a simple broker and implementing heart-beat and reconnect code.

So past week I researched RabbitMQ.
This one seems promising!

I already have more features and more stability in a week then with any of the 4 other libraries I tested.
Last night it sent 50 million messages at a rate of 1000msg/s without loosing any message.
It's still premature to say RabbitMQ is the best message queue solution for dotNet that also works on RPi.

I'm going to use the Rabbit dotNet client in my software, until now I only used it from a test program. Really hope this will be the one, already spend to much time on communication.

I'll let you know the results...

Summary of RabbitMQ attached

Regards,
Wibo.

[maxflax]

Wondering how this turned out with RabbitMQ, Started using MQTT for my hg setup to communicate between hg system but after adding a couple of devices it started to throw exceptions "An element with the same key already exists in the dictionary." So the NMQTT isn't working very well and it restarts the connection a couple of times each minute.