MQTT 3.1.1 specification:
4.4
Message Delivery Retry
When a Client reconnects with CleanSession set
to 0, both the Client and Server MUST re-send any unacknowledged
PUBLISH Packets (where QoS > 0) and PUBREL Packets using
their original Packet Identifiers [MQTT-4.4.0-1]. This
is the only circumstance where a Client or Server is REQUIRED to
redeliver messages.
Non normative comment
Historically retransmission of Control Packets was required to
overcome data loss on some older TCP networks. This might remain a
concern where MQTT 3.1.1 implementations are to be deployed in
such environments.
MQTT 3.1 specification:
4.2. Message delivery retry
Although
TCP normally guarantees delivery of packets, there are certain
scenarios where an MQTT message may not be received. In the case
of MQTT messages that expect a response (QoS >0 PUBLISH,
PUBREL, SUBSCRIBE, UNSUBSCRIBE), if the response is not received
within a certain time period, the sender may retry delivery. The
sender should set the DUP flag on the
message.
The
retry timeout should be a configurable option. However care must
be taken to ensure message delivery does not timeout while it is
still being sent. For example, sending a large message over a
slow network will naturally take longer than a small message
over a fast network. Repeatedly retrying a timed-out message
could often make matters worse so a strategy of increasing the
timeout value across multiple retries should be used.
When
a client reconnects, if it is not marked clean session, both the client
and server should redeliver any previous in-flight messages.
Other
than this "on reconnect" retry behaviour, clients are not
required to retry message delivery. Brokers, however, should
retry any unacknowledged message.
So even in 3.1, clients weren't required to retry except on
reconnect. 3.1.1 still allows it, but lowers the emphasis further.
As I said previously, my experience has shown it to be undesirable
in practice.
Ian
On 08/08/2017 17:05, Paolo Patierno
wrote:
Thank Ian,
I lost this change from MQTT 3.1 to 3.1.1 and my .Net
implementation has this feature still there.
Working on the native Vert.x MQTT client I was re-thinking about
that and all the related problems but then I checked the Paho
Java. You reply fixed the problem at the beginning :)
No need for such implementation.
Can you point me to the MQTT 3.1 paragraph spec where the
retried are described for on going sessions and the where MQTT
3.1.1 remove that please ?
Thanks
Paolo
The retry while a session is active behaviour was removed
from MQTT 3.1.1 (versus MQTT 3.1). In 3.1.1 the only time
retries are attempted are at reconnection time.
In practice, I found that this behaviour caused more problems
than it solved. The usual reason for acks taking a long time
would be an overloaded system, which retrying only
exacerbated.
Ian
On 08/08/2017 16:38, De Alti,
Cristiano wrote:
Hi guys,
am I right saying that the Eclipse Paho Java
implementation doesn't have a built in feature for
retrying.
I mean, for example, if a QoS 1 packet is sent (and
it's alive in the outbound qos1 queue) but the related
PUBACK isn't received after a certain "timeout", the
client doesn't resend the same PUBLISH packet with
duplicate = true but it just continues to wait for the
ack.
The re-send is active "only" in case the client goes
down and the state is recovered from a persistent
storage so the PUBLISH is re-sent.
Is that right ?
Thanks,
Paolo Patierno
Senior Software Engineer (IoT)
@ Red Hat
Microsoft
MVP on Windows Embedded & IoT
Microsoft Azure Advisor
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
