Hi,
I am having a MQTTnet broker/server which provides MQTT service to multiple teams and each team has its own users, devices, topics, ....
First idea is to force the devices to publish/subscribe to a unique topic like: > /team_name/device_label
Another idea came to my mind: instead of forcing devices to set a unique topic in the whole broker to be separated in multiple teams, I prefer the topic to be defined by user freely and unique in its own team, like: /device_label
I tried to change the topic with WithApplicationMessageInterceptor on application message published to set the topic internally in the broker and it is working.
Then I tried to do the same on subscription with WithSubscriptionInterceptor, but it is not connecting to the defined topic.
Here is the simplified code and I am testing with MQTTBox as client:
static async Task Main(string[] args)
{
var optionsBuilder = new MqttServerOptionsBuilder()
.WithDefaultEndpoint()
.WithApplicationMessageInterceptor(ctx =>
{
ctx.ApplicationMessage.Topic = "abc";
ctx.AcceptPublish = true;
ctx.CloseConnection = false;
})
.WithSubscriptionInterceptor(ctx =>
{
ctx.TopicFilter.Topic = "abc";
ctx.AcceptSubscription = true;
ctx.CloseConnection = false;
})
.WithDefaultEndpointPort(1883);
var mqttServer = new MqttFactory().CreateMqttServer();
await mqttServer.StartAsync(optionsBuilder.Build());
Console.WriteLine("Press any key to exit.");
Console.ReadLine();
await mqttServer.StopAsync();
}
As you see, if you publish in ANY topic, it will be published in abc topic. But, the subscribers are not able to subscribe to abc topic.
Am I doing wrong, or my approach is not correct, or there is an issue in broker?
Thanks
Hi,
this was not intended to work in that way. The only reason why this is possible at all is that the topic property of the topic filter is not immutable so you can set it to a different value.
But I got your point and it is quite easy to support it properly. So I will make this an official feature 馃槃
I will release this in the next version 3.0.3.
Best regards
Christian
Perfect, thank you so much.
Do you think that using this feature may cause a problem in future? Do you have any recommendation to my usecase?
Well if that makes sense or not is your decision. I would rather not do it in this way because the client in the end doesn't know what is subscribed if the server alters everything. On the other hand that is maybe not important. If you have such a fixed environment you can also subscribe automatically from server side without even using the subscribe at a client. But in that case you will loose a lot of flexibility on client side.
Hi @chkr1011 ,
When I am using MQTTnet client to subscribe to the topic it is working in version 3.0.4. But, when I am using other MQTT applications, they are not getting the published message and they have to subscribe to the exact topic and TopicFilter interceptor does not apply.
I have tested MQTTLens and MQTTBox to subscribe as a client/subscriber.
Thanks
But it is called also for these applications?
I am just simulating IoT devices and I am testing with some standard applications like them.
Hi,
I am observing the same issue.
Is there any solution or workaround available?
Thanks
Most helpful comment
Hi,
this was not intended to work in that way. The only reason why this is possible at all is that the topic property of the topic filter is not immutable so you can set it to a different value.
But I got your point and it is quite easy to support it properly. So I will make this an official feature 馃槃
I will release this in the next version 3.0.3.
Best regards
Christian