Well, in terms of the spec, the whole clean=false thing is very flawed, IMO, because the server cannot inform the client on loss of state. So, if your broker went down hard, and -- for example -- was replaced, all the clients reconnect with clean=false, all the subscriptions would be lost until the clients are restarted, or whatever you need to do to them to make the re-subscribe. If you have thousands of clients, this seems wildly impractical; it seems like a fundamental design flaw, and no sane person would ever connect clean=false and hope the broker has remembered your subscriptions, because there is no way to know if it didn't. That requires more trust in infrastructure then I normally have :) MQTT-SN makes this worse by throwing the will stuff into the mix, and totally confusing the **** out of everything by having will=false *actually* mean use stored will if clean=false, and if you don't want a will you *actually* have to say will=true and set them blank (if clean=false). Counter-intuitive and very prone to error.
BUT, given we are implementing a spec, not re-writing it.... OTOH, IIRC the will topic/msg is the only client state that survives cross connections in the the gateway, so it would be nice to do away with them.
you are correct, I was thinking of limiting the state that the
gateway had to store. Subscriptions after all don't have to be
remembered by the gateway - those can be left up to the MQTT
broker. If we take the word of spec exactly, I suppose there's no
way of avoiding some state in the gateway. As soon as state is
mentioned, then I start thinking about persistence.
Ian
On 04/06/2016 01:10 PM, Paul Kierstead
wrote:
From the spec:
In MQTT-SN the meaning of a “clean session” is extended
to the Will feature, i.e. not only the subscriptions are
persistent, but also the Will topic and the Will message.
If a client uses Clean=false, Will=false, the gateway uses
any stored will topic/msg for a connect. The XXXUPD ones allow
the stored to be changed at any time, so the SN client can
store its will topic/msg on the gateway instead of remembering
it for the next connect. Even a transparent gateway has to
store some state per client, and these allow that state to be
manipulated. I think it was probably overkill on the part of
the spec, but in the context of the spec, it does make sense,
and it is pretty easy to implement as you had to store the
Will topic and message anyway.
yes, for this sort of transparent gateway, WILLTOPICUPD and
WILLMSGUPD do not make much sense. The only option I can
think of is that the gateway stored that information for the
next connect, but I don't think that's something we want to
do.
For an aggregating gateway, like RSMB, it would make sense,
because the firing of the will message is the responsiblity
of the gateway.
For your implementation, I think it's fine for the gateway
to return a not supported return code (0x03) for
WILLTOPICUPD and WILLMSGUPD.
Ian
On 04/06/2016 08:43 AM, Tomoaki Yamaguchi wrote:
Hi,
I almost done the coding of MQTT-SN
gateway and start debugging now on.
But, I have no idea how G/W handles
WILLTOPICUPD and WILLMSGUPD.
I don't know G/W should keep Will topic and
Will Message or not.
Those seem use less for G/W. MQTT
protocol dose not have those messages.
if the client wants update those, it's enough
to reconnect with updated will topic or will
message.
In what situation we need those messages?
welcome any comments.
tomoaki
At this point G/W does not support WILlTOPICUPD,
WILLMSGUPD, WILLTOPICRESP, WILLMESGRESP,