I would say retry with 3.1 whether you
get a connack back or not (maybe not if the connack says something
other than "invalid protocol" like "not authorized").
This is because some 3.1 servers, deliberately or accidentally,
didn't send back the negative connack before closing the
connection. People felt freer to implement parts of MQTT
differently to the 3.1 spec, if they didn't agree, because it
wasn't a standard.
On 28/01/14 15:17, Marc L Cohen wrote:
I would be quite happy with
that direction. I do like the idea of trying 3.1.1 first and
then retrying with 3.1 if it fails (with a CONNACK... do you
retry even if you don't get a CONNACK? Not sure about that.)
with an option to try with 3.1 first (must have that....).
Marc L. Cohen
(512) 286-5744 (T/L 363-5744)
FAX (512) 973-4293
---01/28/2014 08:58:07 AM---Mark, Dominik, I don't want to
break existing applications (at least for 6 to 12 months
From: Ian Craggs
Date: 01/28/2014 08:58 AM
Subject: Re: [paho-dev] MQTT 3.1.1 support
for Paho clients
Sent by: paho-dev-bounces@xxxxxxxxxxx
I don't want to break existing applications (at least for 6 to
12 months :-) . This means that 3.1 must be the default for now
if we don't automatically fall back. And yes, having a new
major version of the clients could enable us to switch the
If we do automatically fall back, then having 3.1.1 as the
default is the obvious choice, as most, if not all servers will
support 3.1 as well as 3.1.1. If you try 3.1 first you will be
stuck with that. The downside is an extra connect cycle.
I prefer the option "try 3.1.1 first and automatically try 3.1
under the covers if that fails". Then applications don't have
to change, and they can connect easily to either 3.1 or 3.1.1
servers (assuming other differences in the protocol versions are
minimal). And as I said we can have a connect option to turn
off automatic fall back if you don't want it.
paho-dev mailing list