User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
Of course, we (the OASIS standardization body) have fixed that in
the MQTT specification (the session present flag), so we could
consider a similar solution for MQTT-SN.
Ian
On 04/06/2016 02:59 PM, Paul Kierstead
wrote:
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,