Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mosquitto-dev] 答复: A non-centralize Mosquitto cluster design.

Hi Osawa,

No problem, but I need some time to make sure every line of code goes well such as the link list add & remove,  memory allocate & free, to prevent potential crash and memory leak since I wanna make it as a product. Then I will do the benchmark. Could you share some benchmark tools? I have use Tsung but seems it is not flexible to simulate my IoT scenario.

Btw, could you share some material about iot.mosquitto and MQTTv5? I got nothing on the internet.

BRs,
Jianhui

在 2017年12月7日,23:12,Tatsuzo Osawa <tatsuzo.osawa@xxxxxxxxx> 写道:

Hi Jianhui,

Great work! Could you prepare some benchmarks of your cluster?

Regards,
Tatsuzo


2017-12-07 22:35 GMT+09:00 zhan jianhui <hui6075@xxxxxxxxxxx>:
Hi Osawa,

 update the design slide for non-centralize cluster, now the retain msg
seems work as well under functionality test.

 i will keep working with this:)


BRs,

Jianhui

________________________________
发件人: mosquitto-dev-bounces@xxxxxxxxxxx <mosquitto-dev-bounces@xxxxxxxxxxx>
代表 Tatsuzo Osawa <tatsuzo.osawa@xxxxxxxxx>
发送时间: 2017年12月2日 8:09:01
收件人: General development discussions for the mosquitto project
主题: Re: [mosquitto-dev] A non-centralize Mosquitto cluster design.

Hi Jianhui,

I agree with you.
The bridge which I said includes the broadcasting pattern.I guess
extending broadcast features based on current bridge configuration and
implementation can be understood easily.

Regards,
Tatsuzo


2017-12-03 0:36 GMT+09:00 zhan jianhui <hui6075@xxxxxxxxxxx>:
Hi Osawa,

I am Jianhui who is the sponsor of this topic, and this is my new account
since my previous mailbox cannot receive eclipse mail list immediately.

Certainly the cluster could be created by bridge, but as I sad that
centralized architecture strongly depend on the high availability of the
central(bridge) node, we tried to use the standby bridges, but it often
crashed due to the heavy message forwarding.
Also, another scheme is that the bridge can be configured for each node as
a
non-centralized architecture, but the static topic forward strategy inside
each bridge is not flexible. So whatever extend the bridge feature or
create
a new cluster, the key is non-centralize, balance the forwarding load to
each of the node.

Currently my cluster can work properly while Pub & Sub on different nodes.
Later I would like to give the performance testing reports and the
benchmarks about this cluster. As you said, really a huge modification, a
lot of work is waiting for me:)

I guess creating cluster features by extending current bridge is a good
idea.
See also:
https://dev.eclipse.org/mhonarc/lists/mosquitto-dev/msg01590.html

Could you show the outcome by some performance benchmarks if you already
had?

If the outcome is effective, worth to proceed.
Then you should make a plan to divide the whole creation into some
steps and make each PR in order to accept by committers step by step.
Because your creation is too huge to confirm the properly.
The core features of broadcasting SUB and Traffic cycle avoidance as
extending bridge may be the first PR. Further performance improvement
and supporting persistence inter clustering nodes are may be laters.

Regards,
Tatsuzo

2017-12-02 0:30 GMT+09:00 èåè <hui6075@xxxxxxx>:
Hi all,
 I am try to renovation my MQTT cluster which use Mosquitto as the
broker,
our Subscriber and Publisher are intelligent household electrical
appliances
and Mobile phones, the actual scenario is that each appliances subscribe
some topics after network configuration as Subscriber, and almost no
longger
subscriber for new topics. As Publisher, the appliances may report its
status each several minutes.
I have deployed two cluster schemes,
1. use Mosquitto bridge. But the bridge often crash due to heavy traffic;
2. each appliance push message to a webserver, and the webserver
broadcast
the PUBLISH messages to each nodes in the cluster, this is also not a
good
cluster design.

 So I am thinking for a new kind of Mosquitto cluster architecture,
which
is non-centralization, means there is no leader node inside the cluster.
 Attached is the architecture design presentation and implemented code,
could you give me some advise?
P.S my codes are wrapped with #ifdef WITH_EPOLL_V2 and #ifdef
WITH_CLUSTER,
currently only implement on raw MQTT, I means without websockets and
TLS/SSL.





_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from
this list, visit
https://dev.eclipse.org/mailman/listinfo/mosquitto-dev




_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from
this list, visit
https://dev.eclipse.org/mailman/listinfo/mosquitto-dev
_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/mosquitto-dev

_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/mosquitto-dev
_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mosquitto-dev

Back to the top