anhlephuoc
commented
3 years ago Apart from the Broker response(CONNACK) to the connect() call, phpMQTT does not have any code to receive or send any acknowledgments from/to the MQTT Broker. Consequently it will not be able to handle any transfers at QoS>0. You can get away with sending with QoS=1 and ignore any PUBACK from the broker. However, at the receiving end, for topic QoS>0 the client is required to acknowledge each published packet with a PUBACK (QoS=1) or PUBREC+PUBCOMP (QoS=2). If not the Broker will drop the connection so only the first packet of each connection get delivered. phpMQTT will reconnect automatically, but many packets published between the (re)connections will be lost.
There is also a bug in the function subscribe($topics, $qos = 0). If you set QoS=1, phpMQTT code will add that to the existing header 0x82 code (which is already at QoS=1) which effectively makes the subcribe request QoS=2. This is illegal (QoS must be 1 for this request) so the Broker will terminate the connection immediately. This should not even a choice for the subscribe() request call. Note that this QoS is different from the QoS=0..2 for each topic subscribed which is specified separately.
A lot more code will need to be added if phpMQTT is to usable at QoS > 0. I am not sure if there are any active effort being made in updating this code!
I also notice some code at the end of the proc() function (lines 561..568) which seem to enforce a session timeout to initiate an auto disconnect . This is not required because the Broker will never initiate sending anything so the connection being idle is normal. Potentially this code may cause some data loss, but I have not investigated into this to see if this code is ever executed or not.
shunhua
when I set QOS=1 and I sent 500 messages at one time, I find only a few messages could be accepted.