MQTT-SN QoS 1 messages without CONNECT

[Benjamin Damm]

Hello,

Could an MQTT-SN client send a PUBLISH at QoS 1 without ever having done a CONNECT?

What I'm looking for is similar to the "QoS -1" case, but with a confirmation, whereby the client will repeatedly send a PUBLISH (up to some pre-determined give-up time) until the MQTT-SN gateway confirms with a PUBACK that contains the same MsgID as the PUBLISH.

I see no need for a CONNECT to occur ahead of this.  If the MQTT-SN client is not using will topics, then what is the purpose of CONNECT?

The reason I want to avoid CONNECT is because I don't want to maintain state for millions of clients.  I actually do have millions of devices that want to send MQTT-SN messages, but I want to do this in a way that makes the MQTT-SN Gateway & its backing MQTT broker as simple and lean as possible.  Any precent for this, and are there any MQTT-SN gateways that support this?

Thanks,

-Ben

[Tomoaki Yamaguchi]

Hi Benjamin

> what is the purpose of CONNECT?

Client declares a KeepAlive duration.

2017/02/03 5:38 "Benjamin Damm" <benjami...@gmail.com>:

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+unsubscribe@googlegroups.com.
To post to this group, send email to mq...@googlegroups.com.
Visit this group at https://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

[Ranjith Kumar Diraviyam]

HI, 

The requirement looks good.  The MQTT spec should have an option for acknowledgement as part of the QoS -1. 

We have nearly completed our Gateway for our Broker as per the Spec.  We can add an option like this to our GW. 

Cheers , 

Ranjith 
Bevywise Networks.

[Benjamin Damm]

Right, but then KeepAlive is for... WillTopic.  Or, persistent session - but I don't need persistent session in this case.  The idea is to field millions of publishers without having each publisher ping the server every 15 seconds (or even every minute, or every hour.)  Nor should the server need to maintain state for each of the publishers, either within the MQTT-SN Gateway, nor within the underlying OS, other than the DTLS shared secret & session ID.  DTLS does not require the keep-alive.

[Alex Robenko]

I would advice looking at it as CLIENT ---(mqtt-sn)---> GATEWAY ---(mqtt)---> BROKER setup, rather than a direct mqtt-sn connection to the broker. The MQTT protocol (between gateway and broker) requires client to be properly connected to the broker (i.e. to send CONNECT request first) to be able to publish. Even if your client doesn't send an explicit CONNECT request, the gateway must do it on client's behalf. I suppose the gateway application can be implemented and configured to perform proper connection to the broker upon first message received from the client.

However, to the best of my knowledge and understanding, the QoS=-1 was introduced to support very thin clients with a significant ROM size limitation. Such clients are most probably very simple sensors, that send only single type of the message with their sensor reading. If you care about the acknowledgment for the sent messages (using QoS=1), then probably your client is not very thin, and there is little effort involved in actually sending CONNECT request prior to sending messages with QoS=1.

I also understand your "millions of clients" problem and desire to avoid expensive housekeeping of maintaining the list of available clients. However, the QoS=1 requires broker/qateway to send acknowledgement packets (PUBACK messages) back to the sender. How are your going to know to whom you need to send it without maintaining a list of connected clients?
I suppose you can make your clients to use different "topicId + msgId" pairs in their PUBLISH messages and gateway not differentiating between the clients and treating all of them as a single one that sends different messages. The gateway can broadcast the PUBACK messages to the whole network and every client ignoring irrelevant packets. However, if I'm not mistaken the MQTT-SN protocol doesn't allow sending multiple PUBLISH messages with QoS>0 from single client prior to receiving acknowledgment to the first one, which forces you to somehow differentiate between clients.

The bottom line, you have the following options:

1. Stick with QoS=-1 for all of your clients and having aggregating gateway that has a single connection to the broker and republishes the received messages without expecting anything back.
   
2. Use proper connection with the clients and full housekeeping of connected clients.
3. Invent a new custom protocol that supports your needs (MQTT-SN doesn't seem to do so) and implement your own gateway with mqtt bridging.
   

[Benjamin Damm]

We're going for the approach of a thin gateway that can hold just enough context to service the many clients. I'm migrating from a system that already has a custom protocol, and the uniqueness of it is the main problem.

Benjamin Damm
Platform Architect
Web: http://ssni.com