bluerhinos / phpMQTT

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

Frequent error reporting: eof receive going to reconnect for good measure #42

Closed kalsolio closed 4 years ago

kalsolio commented 7 years ago

[2017-09-06 15:33:08] local.DEBUG: eof receive going to reconnect for good measure


[2017-09-06 15:32:43] local.DEBUG: ping sent
[2017-09-06 15:32:43] local.DEBUG: not found something so ping
[2017-09-06 15:32:43] local.DEBUG: ping sent
[2017-09-06 15:32:43] local.DEBUG: Recevid: 13
[2017-09-06 15:32:43] local.DEBUG: Fetching: 0
[2017-09-06 15:32:43] local.DEBUG: Recevid: 13
[2017-09-06 15:32:43] local.DEBUG: Fetching: 0
[2017-09-06 15:32:54] local.DEBUG: not found something so ping
[2017-09-06 15:32:54] local.DEBUG: ping sent
[2017-09-06 15:32:54] local.DEBUG: not found something so ping
[2017-09-06 15:32:54] local.DEBUG: ping sent
[2017-09-06 15:32:54] local.DEBUG: Recevid: 13
[2017-09-06 15:32:54] local.DEBUG: Fetching: 0
[2017-09-06 15:32:54] local.DEBUG: Recevid: 13
[2017-09-06 15:32:54] local.DEBUG: Fetching: 0
[2017-09-06 15:32:59] local.DEBUG: Recevid: 3
[2017-09-06 15:32:59] local.DEBUG: Fetching: 54
[2017-09-06 15:33:06] local.DEBUG: Recevid: 3
[2017-09-06 15:33:06] local.DEBUG: Fetching: 32
[2017-09-06 15:33:08] local.DEBUG: eof receive going to reconnect for good measure
[2017-09-06 15:33:08] local.DEBUG: Connected to Broker
[2017-09-06 15:33:08] local.DEBUG: Recevid: 3
SergeyBrook commented 6 years ago

I had the same problem with Mosquitto broker. It seems that Mosquitto expecting to receive ping within timeout period regardless of messages sent to client within this period of time (not tested this behavior on other brokers). In "proc" method, "timesinceping" updated when EVERY type of message received, not only ping response and this causes to delay next ping to broker. This, in turn, cause to timeout on broker side and it forcing to close connection.

Solution: Just remove line 349: $this->timesinceping = time(); in "proc" method and put it in to "ping" method. Additionally, this will resolve the problem with timing, when ping request sent twice every time (you can see it in debug log you posted).

jmarshallpresnell commented 4 years ago

Definitely suggest this gets rolled in. For any retained messages, they are re-received constantly when not needed on each reconnect (an expected operation). For any significantly sized retained messages, this could pose a bandwidth issue with a large number subscribers using this library times the many reconnects they make.

SergeyBrook commented 4 years ago

Opened pull request...