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.
Ian
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
MessageSight Test/Development
Internet:mlcohen@xxxxxxxxxx
also at:teddybbear@xxxxxxx
(512) 286-5744 (T/L 363-5744)
FAX (512) 973-4293
Ian Craggs
---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
<icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
To: paho-dev@xxxxxxxxxxx,
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
Mark, Dominik,
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
default.
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.
Ian
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
|