Hi Ian
Looks like I was too fast with raising the bug. I think the problem is a result of my "wrong use" of the library API.
I tried to find out why the Socket_getReadySocket does not return 0 but always a socket even though there was no network traffic at that time. I found that my process had beside the 3 used sockets some "leaked" sockets:
sudo lsof -a -p <pid>
...
MqttSnGW 5632 root 12u IPv4 14541 0t0 TCP PiTwo:44388->
104.40.130.232:1883 (CLOSE_WAIT)
MqttSnGW 5632 root 14u IPv4 19362 0t0 TCP PiTwo:44666->
104.40.130.232:1883 (ESTABLISHED)
MqttSnGW 5632 root 15u IPv4 14985 0t0 TCP PiTwo:44403->
104.40.130.232:1883 (CLOSE_WAIT)
MqttSnGW 5632 root 16u IPv4 19365 0t0 TCP PiTwo:44667->
104.40.130.232:1883 (CLOSE_WAIT)
MqttSnGW 5632 root 17u IPv4 19371 0t0 TCP PiTwo:44669->
104.40.130.232:1883 (ESTABLISHED)
MqttSnGW 5632 root 18u IPv4 19427 0t0 TCP PiTwo:44674->
104.40.130.232:1883 (CLOSE_WAIT)
MqttSnGW 5632 root 19u IPv4 19446 0t0 TCP PiTwo:44676->
104.40.130.232:1883 (CLOSE_WAIT)
MqttSnGW 5632 root 20u IPv4 19488 0t0 TCP PiTwo:44680->
104.40.130.232:1883 (CLOSE_WAIT)
MqttSnGW 5632 root 21u IPv4 19505 0t0 TCP PiTwo:44682->
104.40.130.232:1883 (CLOSE_WAIT)
MqttSnGW 5632 root 22u IPv4 19543 0t0 TCP PiTwo:44686->
104.40.130.232:1883 (ESTABLISHED)
...
I then found out that in some situation my code destroyed (MQTTClient_destroy) a connected client without a prior call to MQTTClient_disconnect which results in the 'leaked' sockets. I changed my code so it ensures it always disconnects the client prior to destroying them and the 'leaked' sockets are gone. The gateway now runs for more that one day and the CPU usage is still normal and the Socket_getReadySocket return 0 when there is no network traffic. So I'm quite confident that the problem is gone.
I will add this information to my bug report and leave it to you to decide if the library should handle a destroy without prior disconnect or if this is the responsibility of the library user.
Regards
