You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Even on a local machine, too many subscribed topic messages are not delivered. I know Qos==0 so there is no guarantee, but this is within local machine delivery should be 100%. A concurrent 'mosquitto_sub' receives everything without trouble.
The problem is probably because of the many timeouts, reconnect, and sleeps ... so phpMQTT can receive a burst of messages then loses a burst of messages.
Messages are likely to be lost during the (re-)connections but phpMQTT seems to reconnect every second or so.
For example if debug is enabled this is reported:
Thu, 01 Oct 2020 10:59:49 +0100: Connected to Broker
Thu, 01 Oct 2020 10:59:49 +0100: eof receive going to reconnect for good measure
Thu, 01 Oct 2020 10:59:49 +0100: Connected to Broker
Thu, 01 Oct 2020 10:59:50 +0100: eof receive going to reconnect for good measure
Thu, 01 Oct 2020 10:59:50 +0100: Connected to Broker
Thu, 01 Oct 2020 10:59:50 +0100: eof receive going to reconnect for good measure
Thu, 01 Oct 2020 10:59:50 +0100: Connected to Broker
Thu, 01 Oct 2020 10:59:50 +0100: eof receive going to reconnect for good measure
Thu, 01 Oct 2020 10:59:50 +0100: Connected to Broker
etc...
The text was updated successfully, but these errors were encountered:
Further investigation with a protocol analyser (wireshark) connected indicate the following problems:
phpMQTT closes connection too liberally when it detect some problems. MQTT uses(require) reliable TCP protocol or equivalent. So when a problem is detected it is not likely because underlying recoverable communication glitch which may be resolved be a warm reconnection. I have found the following problem to cause the same outcome:
a) Broken physical link (real comms problem requiring user intervention).
b) Multiple client connections with same ID. (eg: multiple instances of same test program with hardcoded clientID). The Broker will simply drop the connection.
c) Incorrect QoS for Subcribe request cause the Broker to just disconnect.
d) may be more ...
In all the cases above, the reconnection will simply fail again, causing lots of confusing error messages. These problems are not recoverable by retrying. The user/programmer will need to correct the problem. It will be more useful for this to indicate to the calling program, or just simply exit() with some useful error.
Even on a local machine, too many subscribed topic messages are not delivered. I know Qos==0 so there is no guarantee, but this is within local machine delivery should be 100%. A concurrent 'mosquitto_sub' receives everything without trouble.
The problem is probably because of the many timeouts, reconnect, and sleeps ... so phpMQTT can receive a burst of messages then loses a burst of messages.
Messages are likely to be lost during the (re-)connections but phpMQTT seems to reconnect every second or so.
For example if debug is enabled this is reported:
Thu, 01 Oct 2020 10:59:49 +0100: Connected to Broker
Thu, 01 Oct 2020 10:59:49 +0100: eof receive going to reconnect for good measure
Thu, 01 Oct 2020 10:59:49 +0100: Connected to Broker
Thu, 01 Oct 2020 10:59:50 +0100: eof receive going to reconnect for good measure
Thu, 01 Oct 2020 10:59:50 +0100: Connected to Broker
Thu, 01 Oct 2020 10:59:50 +0100: eof receive going to reconnect for good measure
Thu, 01 Oct 2020 10:59:50 +0100: Connected to Broker
Thu, 01 Oct 2020 10:59:50 +0100: eof receive going to reconnect for good measure
Thu, 01 Oct 2020 10:59:50 +0100: Connected to Broker
etc...
The text was updated successfully, but these errors were encountered: