When remote bridge is not sending notifications to, the server only issues $SYS/broker/connection/../state for disconections, not connections

[twegener-embertec]

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).

[twegener-embertec]

Not sure whether this is related to #1488 in some way.

[ralight]

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.

[twegener-embertec]

So in theory, yes, we can guess that a bridge has connected

I don't understand what you mean by having to "guess".
Every time a remote bridge connects, a "New bridge connected from" message appears in the mosquitto server log.

I'm guessing you are referring to this code in handle__connect:

		if((protocol_version&0x7F) == PROTOCOL_VERSION_v311){
			context->protocol = mosq_p_mqtt311;

			if((protocol_version&0x80) == 0x80){
				context->is_bridge = true;
			}
		}else if((protocol_version&0x7F) == PROTOCOL_VERSION_v5){
			context->protocol = mosq_p_mqtt5;

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):
On the https://github.com/mqtt/mqtt.org/wiki/SYS-Topics page it mentions:

$SYS/broker/bridge/#: When bridges are configured to/from the broker, common practice is to provide a status topic that indicates the state of the connection. This is provided within $SYS/broker/bridge/ by default. If the value of the topic is 1 the connection is active, if 0 then it is not active.

cf. https://mosquitto.org/man/mosquitto-8.html

$SYS/broker/connection/#
    When bridges are configured to/from the broker, common practice is to provide a status topic that indicates the state of the connection. This is provided within $SYS/broker/connection/ by default. If the value of the topic is 1 the connection is active, if 0 then it is not active. See the Bridges section below for more information on bridges.

[ralight]

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).

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.

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)?

I agree, it is useful. The way this is usually implemented is that each client sets a Will message to publish a 0 to the appropriate topic on the event that it disconnects, and after it has successfully connected, it sends a message to the same topic with a 1. This is exactly what the bridge notifications do, but other clients can do it as well. Is there a reason why this isn't sufficient?

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.