I encountered an issue while using the MQTT protocol for device-to-device communication. The MQTT code uses version 1.5.9. Suppose Device A hosts the broker, and both the subscriber and publisher run in the same process (named “tt”). When the “tt” process starts, it connects to the local broker by sequentially calling the following APIs: mosquitto_lib_init, mosquitto_new, mosquitto_tls_set, mosquitto_username_pw_set, mosquitto_disconnect_callback_set, mosquitto_message_callback_set, and mosquitto_connect. Finally, it calls mosquitto_loop_forever to handle messages. All message publications use QoS 1 or QoS 2, ensuring execution in the thread where mosquitto_loop_forever resides.
Initially, everything works fine, but after running for a period, the callback function set by mosquitto_disconnect_callback_set is triggered with rc=14 (i.e., MOSQ_ERR_ERRNO). Tracing deep into the MQTT library, I found that the net__read function calls SSL_read, which returns a negative value. After calling SSL_get_error, the error sequence is first errno=EGAIN, then errno=EPROTO. Additionally, calling net__print_ssl_error produces no output. What could be the cause of this?
I’d like to add some supplementary information: The probability of the disconnect callback being triggered is low when the number of messages is small, but high when the number of messages is large. After upgrading the MQTT library to version 1.6.2, disconnections no longer occur when the number of messages is small. However, when the number of messages is large, disconnections from the broker still happen, though the frequency is lower compared to version 1.5.9.
i think i found the reason: mosquitto_loop_forever is called but mosquitto_threaded_set is not called , 