-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
When remote bridge is not sending notifications to, the server only issues $SYS/broker/connection/../state for disconections, not connections #2016
Comments
Not sure whether this is related to #1488 in some way. |
Bridge notifications are carried out by the broker initiating the bridge connection only. The broker that receives the bridge connection doesn't know anything about the connection other than it set a non-standard bit in one of the CONNECT flags, which is what Mosquitto uses to trigger some bridge configuration for a connection (these configuration modes are now available to all clients as standard in the MQTT v5 spec). So in theory, yes, we can guess that a bridge has connected and hence publish a status message for it. But this only works for MQTT v3.1.1 and earlier bridges, we can't detect MQTT v5 bridges in the same way. Further, we don't know if the bridge connection we have detected is going to send its own status message, and if it isn't, what the topic for the status should be. We could potentially publish a status message using the client id as the identifier in the topic, but this would be different than what the bridge currently uses. |
I don't understand what you mean by having to "guess". I'm guessing you are referring to this code in handle__connect:
So I suppose you mean that when there is a new connection, mosquitto cannot necessarily know (e.g. when using MQTT v5) that the connection is a bridge (i.e. another broker as opposed to a direct simple client). Regarding my request, I'm not particularly concerned about knowing whether the connection is a bridge or not, but rather that a given client (bridge or not) has connected, and to be able to subscribe to a topic so as to receive notifications when that client is connected/disconnected, along with its clientid / username. It seems like that would be a generally useful facility to have. Are there any technical barriers to providing that (i.e. as described in the preceding paragraph or something to that effect)? Interesting side note (regarding "bridge" vs "connection" terminology in the topic):
cf. https://mosquitto.org/man/mosquitto-8.html
|
Yes, exactly. Even when an MQTT v3 client connects that has the most significant bit of the protocol byte set, we still don't know it is a bridge, it could just be a client that doesn't want its own messages redelivered to it.
I agree, it is useful. The way this is usually implemented is that each client sets a Will message to publish a I don't really want to implement what you propose into the broker, but it's an ideal candidate for a plugin. I've just pushed a commit that includes an example plugin to do this: 0087431 - this uses a new plugin event MOSQ_OPT_CONNECT. |
When a remote bridge is configured (by default) to send notifications to the server bridge, the server publishes a $SYS/broker/connection/../state '1' message corresponding to that bridge. When that remote bridge is killed (kill -9), the server publishes a $SYS/broker/connection/../state '0' message corresponding to that bridge, even though it (presumably) has not received the $SYS message form the remote broker (since it was hard killed). That is good, but makes the following behaviour seem bad/surprising:
When a remote bridge is configured to not send notifications to the server bridge (e.g. by setting 'notifcation_topic' to something that doesn't go to the server), the server does not publish $SYS/broker/connection/../state '1' when that remote bridge connects, and neither does it report when that remote bridge goes offline (via hard kill).
This seems undesirable, because the server should be able to publish the connected / disconnected state of a remote bridge without having to have received any specific message from the client. The logs show that it already knows when the remote bridge gets connected and disconnected.
In stead, it seems desirable that the server should report remote broker connectivity state changes via publishing a $SYS/broker/connection/../state message for the remote broker when it detects it connecting or disconnecting (and not based on receiving an explicit notification message from the remote broker).
The text was updated successfully, but these errors were encountered: