bluerhinos / phpMQTT

a simple php class to connect/publish/subscribe to a MQTT broker
Other
765 stars 461 forks source link

Too many messages lost. #112

Open anhlephuoc opened 3 years ago

anhlephuoc commented 3 years ago

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...

anhlephuoc commented 3 years ago

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.