Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Too many messages lost. #112

Open
anhlephuoc opened this issue Oct 1, 2020 · 1 comment
Open

Too many messages lost. #112

anhlephuoc opened this issue Oct 1, 2020 · 1 comment

Comments

@anhlephuoc
Copy link

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
Copy link
Author

anhlephuoc commented Oct 13, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant