MQTTnet
MQTTnet copied to clipboard
Server: Is there an option in the server to just get the messages that you subscribed to before?
Describe your question
@chkr1011 Is there an option in the server to just get the messages that you subscribed to before? There is, of course, InterceptingPublishAsync which can be used like this, but this will get all messages that are published to the server.
private async Task Run()
{
var mqttFactory = new MqttFactory();
var mqttServerOptions = new MqttServerOptionsBuilder().WithDefaultEndpoint().Build();
using (var mqttServer = mqttFactory.CreateMqttServer(mqttServerOptions))
{
await mqttServer.StartAsync();
mqttServer.InterceptingPublishAsync += this.InterceptPublish;
await mqttServer.SubscribeAsync("Test", "a/b/#");
await mqttServer.StopAsync();
}
}
private async Task InterceptPublish(InterceptingPublishEventArgs args)
{
// Handle some published data here.
args.ProcessPublish = true;
}
Which project is your question related to?
- Server
@chkr1011 Do you have a proposal for this without intercepting all the messages?
Sorry but I don't fully understand the question. Do you want to get all messages which are only subscribed for a certain client ID? So you subscribe to "A" and "B" from client side, and you want to see only those somewhere else in the server? But only those and not "C" messages?
Sorry but I don't fully understand the question. Do you want to get all messages which are only subscribed for a certain client ID? So you subscribe to "A" and "B" from client side, and you want to see only those somewhere else in the server? But only those and not "C" messages?
Exactly like that, yes. I mean, the server can subscribe as well using the SubscribeAsync method, but in contrary to the client, there is no handler to get exactly only the matching messages. Something like this as it is on the client side:
mqttClient.ApplicationMessageReceivedAsync += e =>
{
Console.WriteLine("Received application message.");
e.DumpToConsole();
return Task.CompletedTask;
};
If you ask me, there are only 2 options that make sense:
- Remove
SubscribeAsyncfrom the server side handlers as subscribing doesn't make sense at all without the ability to get only the subscribed messages (I would say). - Add
ApplicationMessageReceivedAsyncto the server side handlers as well to allow to get only the messages theserver's client(If we can name it like that) has subscribed to.
@SeppPenner, as best I can tell, to your first point, the SubscribeAsync on the server is not for the server to subscribe to and receive messages, but rather for the server to subscribe a client to a topic so the client can receive messages. I use this often when my clients are interested in the type of message (rather than the topic it was delivered on) and if I change the data service (source/publisher) of certain content to publish at a different topic, I can make 1 change on the server rather than reconfigure each client since the client does not care about the topic it is published on, only the content/type. I also use it when a client publishes a certain type of message that should then cause other clients to subscribe to a certain topic. Yes, this can be done on each of the clients, but it can also be done this way.
There could be another SubscribeAsync() method without the client_id parameter, or allow that parameter to be null, to create a server subscription. I utilize the existing events to parse each incoming message handled by the broker to determine if it's interesting and then act on it if so - basically created my own version of what you are seeking - so I am interested in seeing something similar for the broker to reduce my programming burden in the future :)
I currently have the same issue that I want to subscribe to specific topics on the server (not necessarily bound to a specific client). It seems that there are only two ways to do this at the moment:
- Filter all incoming publish messages with an own message handler
- Connect with a client to the broker and subscribe to the specific topics
@SeppPenner How did you solve the problem in your specific situation?
@Octoate I used option 1 for now, but there's no alternative yet.
@Octoate I used option 1 for now, but there's no alternative yet.
Thanks. I guess I will go this way, too.