mosquitto-users team mailing list archive

[Roger Light <roger@xxxxxxxxxx>]

Hi Damiano,

> Indeed, if I understand correctly the protocol definition, it says that
> PUBLISH messages don't contain this client ID field -- and that's this kind
> of messages that are forwarded to MQTT "consumers".
>
> Now, my question is: doesn't that somewhat contradict with the common use
> case of this protocol, i.e. "where the network is expensive, has low
> bandwidth or is unreliable".

I'm not sure how you draw that conclusion. Adding in the sending
client id would require more bandwidth and in most cases you probably
don't care where the message came from. If you do, add it in to the
payload.

> Maybe a workaround would be to have a modified broker which would alter the
> payload of PUBLISH messages before forwarding them. And that would have to
> be done inside the broker as the information is only known to it.

You could of course do this, but it wouldn't be MQTT any more :)

> That makes me wondering if there's an easy way in the Mosquitto broker to
> plug in some programmable hooks, to modify / monitor message exchanges for
> example? I don't think so. So what do you think of the idea of adding some
> Lua scripting capability into the Mosquitto broker? The runtime library is
> compact and it's a very popular scripting engine for this kind of work.

There isn't any way of doing this at the moment, but it's certainly
something I'll be considering in the future. Many situations can be
dealt with using a client local to the broker but sometimes the
internal state is required.

> By the way, this whole "client ID discussion" make me think on how to choose
> a "proper" ID. Basically, what was the goal of the authors of MQTT when they
> added this "client ID" field?
> What would be a intelligent use of it? How to avoid ID collisions, etc?
> There must a reason why it's in the spec :-)

The client id is unique and used to allow persistent/durable clients
(with clean session set to false) to reconnect and recover their
subscriptions and/or queued messages. In MQTTv3 it could also be used
as a crude form of authentication by only allowing clients with a
particular id prefix to connect, but this has largely been superceded
by the username/password options in MQTTv3.1. As far as selecting a
"proper" ID, I'd go with anything that's sufficiently random (unless
you're using clean session==false) or has particular meaning for you.
Don't go for anything that solely relies on the time the id is
generated to avoid collisions. The mosquitto libraries (next version)
generate random IDs for you if you don't provide one.

Cheers,

Roger