CocoaMQTT should as possible as promise the message arrival

[andyd0]

I thought this might be due to broker or server but those seem to be ok. I know...

1. Messages are being generated as I see it in Xcode print messages

2. I can see the device connect / disconnect from the broker - this happens regardless of whether messages are sent or not

Is there something that would prevent messages from being sent?

[HJianBo]

No. The CocoaMQTT doesn't prevent any message when it has connected successfully!

Could you pls provide more log or code? or check the broker has received those messages?

[andyd0]

I'll check on logs - I was told that the broker would not block messages. I thought it was AWS at first blocking high rate of messages but then replicated the issue locally. I'll try to get logs though tonight / tomorrow

[andyd0]

When you say logs, what in particular are you referring to? I refactored my code to use the methods didConnect and didConnectAck - both of these show that I have connected to the server and that the connection has been acknowledged.

But the messages are not always sent. I now noticed that I need to close out of the app completely and then reopen for messages to work properly again.

Mosquitto logs do not show any error besides the occasional socket error when the device is disconnecting. I'm using mosquitto -v which should log everything and I don't see any other errors besides this. Here is an example of the log where the connection / disconnection does occur but no messages are received...

1533742635: Socket error on client , disconnecting. 1533742637: New connection from IP on port 1883. 1533742637: New client connected from IP as client (c1, k60). 1533742637: Sending CONNACK to client (0, 0) 1533742638: Received DISCONNECT from client 1533742638: Client disconnected.

The only definite is that when the messages are not being received, fully closing the app and reopening it will then fix the issue. I am using disconnect - should this not be enough to ensure closing / reopening app isn't necessary?

Also could there be any issues with sending messages at a high rate and / or disconnecting / reconnecting quickly? The latter is because of testing ... not real world. The former - device is sending 30 messages per second.

[andyd0]

Another thing I noticed...

Sending PUBACK to client (Mid: 34)

Mid: 34 - after disconnecting and reconnecting, the message id is continued (i.e. it will be Mid: 35 after a new connection). Should this not be reset after the device disconnects? I'm not sure if the issue that I'm having is due to some sort of connection hold between the server and client

Thought this could be because of keepAlive but setting that to 0 does not help

[HJianBo]

sorry, I can't reproduce it. It is always successfully sent and received messages between local Mosquito server using the following code:

let timer = Timer(timeInterval: 0.02, repeats: true) { (t) in
                self?.mqtt!.publish("sometopic", withString: "somemsg", qos: .qos1)
            }
RunLoop.main.add(timer, forMode: .commonModes)

after disconnecting and reconnecting, the message id is continued

It is a normal activity for CocoaMQTT. The connection will be cut when disconnect called. don't worry about that!

Could you send a demo program to help reproduce it? Thanks!

Mail: [email protected]

[andyd0]

Ok thank you! I'll be sending a simplified version of the app that still has the same issue.

[dmhts]

Hey @HJianBo ,

Could you please explain what this https://github.com/emqtt/CocoaMQTT/commit/2418271bfb8c243132326957943653e87466a891 hotfix is about?

At the moment it only breaks the things, it leads to missing messages if a broker goes down and then comes back. All the messages that are being enqueued during the interval while the broker is down (storing in silos) are just emptied on the next connect. It's definitely not the expected behaviour.

[HJianBo]

@dmhts Yes! It's very bad behavior. I will fix that and plan to add a persistent module to store these unacknowledged/unsent messages.

CocoaMQTT should as possible as promise the message arrival. It will be fixed in the next version. Thanks for your remind!

[dmhts]

@HJianBo Thank you!