How to run an mqtt-repl?

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
User avatar
tve
Posts: 59
Joined: Wed Jan 01, 2020 10:12 pm
Location: Santa Barbara, CA
Contact:

Re: How to run an mqtt-repl?

Post by tve » Sat Jan 25, 2020 10:01 pm

OK, couldn't wait, had to look... Section 4.6 "Message Ordering" of MQTT3.1.1 (http://docs.oasis-open.org/mqtt/mqtt/v3 ... c398718105) says "When it re-sends any PUBLISH packets, it MUST re-send them in the order in which the original PUBLISH packets were sent (this applies to QoS 1 and QoS 2 messages)" and further (non-normative comment explaining that message duplication may occur) "For example a publisher might send messages in the order 1,2,3,4 and the subscriber might receive them in the order 1,2,3,2,3,4.".

All this assumes that both clients (the one running on the board and the one on the "computer") use QoS 1 (or 2)

User avatar
pythoncoder
Posts: 3925
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: How to run an mqtt-repl?

Post by pythoncoder » Sun Jan 26, 2020 10:05 am

tve wrote:
Sat Jan 25, 2020 4:19 pm
I agree in general about the short message size, however, MQTT in this case is over TCP, which is a reliable byte stream, with a max packet/segment size, and with selective retransmission (IIRC LwIP does support that). TCP also has a max retransmission count, so it will eventually give up.
TCP is reliable in principle, but it can't overcome the limitations of physics. A radio link is inherently unreliable: in extremis one endpoint can move out of range of the other. At the MQTT level the qos==1 guarantee applies to the message as a whole, and the entire message will be retransmitted on error. So the statistical behaviour in the presence of an imperfect link seems inescapable.

I'm not criticising your use of long messages: if your link is reliable they should present no problems.
Peter Hinch

Post Reply