MQTT and Outlier Applications

46 views
Skip to first unread message

Leif Zars

unread,
Jul 11, 2017, 10:21:51 AM7/11/17
to MQTT
I am new to MQTT and am wondering about the following three types of applications, and how they would be handled with MQTT.

Case 1: Devices require 1 to 5 minutes for round trip ping.
Case 2: Device Sleeps for 1-6 hours then comes online sync.
Case 3: Network is not TCP/IP based.

Case 1 is a a challenge because the cost of a transaction is up to 5 minutes, can MQTT handle acks at the high latency? What is the transaction overhead of MQTT? In other words once a subscription exists would there only need to be 1 transaction per transfer? Can multiple subscriptions be handled in a batched transfer mode?

I have read a bit about the KeepAlive, and it seems that it is issues by the embedded client. Can I just set this to 5 min and expect everything to work properly?


Case 2: if A device is offline for hours and then comes online for seconds, can MQTT handle this high level of disconnection? Will it queue up requests efficiently and wait for the incoming connection.

Case 3: if the network is not TCP/IP can I use MQTT? Do I have to create a TCP/IP to Network X bridge ? Is this a good ideal? Would the embedded client need work to accommodated a none TCP/IP network?


Thanks Leif

Vardharajulu

unread,
Jul 12, 2017, 1:34:02 AM7/12/17
to MQTT
Hi Lief,
MQTT can Handle your three types of applications.

case 1: 
a) High latency ack is implementation specific. MQTT Broker does not delete the message until receive ack and ack waiting time is not mentioned in the spec. 
b) If subscription exists, then one publish message per transfer. 
c) Yes MQTT subscribe more than one topics in single subscribe packet.
d) According to spec you can set 16-bit keep alive period in secs. That means MQTT broker can wait for 1.5 times of keepalive to terminate the connection. You can send any control packet to reset the keep alive timer. If you don't want to keep alive means set zero to keep alive and the broker doesn't disconnect you until DICONNECT control packet received.

Case 2: yeah, connection with clean session set to zero can restore the previous session of the client. 

Case 3: MQTT is a connection oriented protocol. Large size publish packet need to be arrived in sequence so MQTT is applied over TCP. You can choose MQTT-SN and use Bluetooth or UDP.

with regards,
Vardharajulu K N
Technical Architect,
Bevywise Networks, India

Leif Zars

unread,
Jul 12, 2017, 10:25:24 AM7/12/17
to MQTT
Thanks,

MQTT-SN looks like the best option for me.

Thanks for the feed back again a big help.

Leif
Reply all
Reply to author
Forward
0 new messages