Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why not put the broker in silo? #1

Open
ElderJames opened this issue Oct 21, 2021 · 6 comments
Open

Why not put the broker in silo? #1

ElderJames opened this issue Oct 21, 2021 · 6 comments
Assignees
Labels
question Further information is requested

Comments

@ElderJames
Copy link

Hi @SeppPenner ,

I was very inspired by this project.

But I have a question, can we make the broker and silo run in the same service? Instead of being a ClusterClient. If this works, the brokers can follow silo in the cluster.

Best Regards.

@SeppPenner SeppPenner self-assigned this Oct 24, 2021
@SeppPenner SeppPenner added the question Further information is requested label Oct 24, 2021
@SeppPenner
Copy link
Owner

You can run the silo host and the MQTT broker part on the same host system or the silo and the MQTT broker part in the same service, but that's not the original idea of the system. If you do that, the way Orleans is intended to be used is broken.
The idea was to have multiple instances of the MQTT broker as "frontend" systems and the data logic in the background within the silos / grains (As described in the image below):

Orleans from https://www.youtube.com/watch?v=_yw9HvJdzBo

If you run the MQTT broker part within the silo service, you don't have a distributed system anymore, but a centralized system. For that use case, you should take a look at the https://github.com/chkr1011/MQTTnet.Server which is a single service system and probably better for that use case.

@ElderJames
Copy link
Author

Thank you for your reply.

I'm still a bit confused. Silo themselves are clustered, but why is the broker running on each silo instance not clustered?

@SeppPenner
Copy link
Owner

The broker can be kind of clustered as well:

grafik

Just by adding multiple instances of the MQTT broker "talking" to one or more silo hosts, the MQTT brokers can be clustered. That was the original idea (As the regular MQTT broker is not able to do clustering on its own). The broker can talk to one silo host (Just for synchronization of the MQTT brokers) or to multiple silo hosts (Synchronization and redundancy).

@ElderJames
Copy link
Author

Thank you for the detailed explanation.

My understanding of clustering is that first the mqtt client should only need to connect to one endpoint, and then implement load balancing at the endpoint to distribute the links to multiple broker nodes. If the connection is disconnected for a period of time and when it is linked again, it is assigned to another node, then the messages from the previous proxy are sent to the client from that node.

At the moment you don't seem to have implemented load balancing with this design.

@SeppPenner
Copy link
Owner

It's not really load balancing as we know it in a classical way, but Orleans offers load balancing (https://dotnet.github.io/orleans/docs/implementation/load_balancing.html). I didn't want to re-invent things and therefore rely on the Orleans standard machanisms :)

@ElderJames
Copy link
Author

Yes, I would also like to take advantage of Orleans' clustering mechanism. Orleans' silo is embedded load balancing, using one of the nodes as a gateway endpoint.
I want the Mqtt Broker to also take advantage of Orleans' cluster implementation for routing Mqtt messages

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants