purpose of max_repubs?

In mqtt_as’ MQTT_base you have a _max_repubs config variable which defaults to 4. It governs how often publish republishes a message on the existing connection (https://github.com/peterhinch/micropython-mqtt/blob/master/mqtt_as/mqtt_as.py#L361). I’m a bit puzzled: what is the value of republishing on the same connection? I.e., given that the connection is TCP-based, what kind of error does this try to overcome. It seems to me that if no ACK is received on the connection then there’s no point resending on the same connection.

[peterhinch]

I think this should be set in context.

Changes related to connectivity outages require a great deal of time consuming testing. In the past such testing threw up many surprising edge cases, in one instance involving my sending hardware to Australia for Damien to evaluate. That one remains unresolved.

At one point, embarrassed by the complexity of the code, I started a new project with the sole purpose of finding a minimal solution to a resilient socket-like connection. The end result, after a lot of work and in collaboration with @kevinkk525 , demonstrated that the complexity was actually required.

Every so often a network guru emerges declaring some of the code to be unnecessary. I fully accept that it is an empirical solution: arguably this is both a strength and a weakness.

I would greatly welcome someone with a deep grasp of networking issues and a willingness to tackle the underlying libraries, backing up their statements with fixes and enabling us to simplify the module. It is beyond my capabilities. Proving such an effort would involve much testing.

In the meantime this solution has the merit of empirical resilience on ESP8266, ESP32 and Pyboard D platforms. It may be that this particular value can be set to zero without ill-effects. It is user-configurable, feel free to set it to zero and re-test on all platforms at the limits of range.

[tve]

Great, thanks for making this nice library available! I’m trying to add streaming publish capability and it’s not trivial, but that’s why I have gone with a fine toothed comb through the code. I’m also only interested in esp32 at the moment (maybe I’ll try esp8266 but my tolerance for non-https has pretty much reached zero and I don’t think MP + https is practical on the esp8266). In any case, I’ll stop bothering you with github issues.