Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Python Paho with ssl disconnects and never reconnects

Hi Roger,

I believe the notion of retrying a PUBLISH (unless at connection restart), was removed from MQTT 3.1.1.  Whether it's a violation of the protocol to do so...  I can't see how it could be really.

Ian

On 05/20/2015 03:16 PM, Roger Light wrote:
Hi Dumitru,

The client should disconnect from the server and call the disconnect callback if it doesn't receive a PINGRESP after keepalive seconds from sending the PINGREQ. This check is carried out in the loop_misc() function.

If the broker doesn't send a PUBACK the client will keep on retrying to send a PUBLISH at intervals until (hopefully!) the broker replies.

Cheers,

Roger



On Wed, May 20, 2015 at 2:52 PM, Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
So it's a bug if the client doesn't signal connection lost when the pingresp is not received within a "reasonable" amount of time.

Can you raise one? https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Paho

There's no definitive action to be taken if PUBACKS are not received.  If the client library has the notion of a "maximum inflight message window" it could refuse to accept new messages.

Ian



On 05/20/2015 02:39 PM, Dumitru Melenteanu wrote:
The scenario you are describing is what I would expect to happen. What actually happens is that the client will happily continue working even if it doesn't receive a PINGRESP. I don't see any kind of sign in the logs and, after a look in the source code, there doesn't seem to be any logging where the reconnection code should kick in. (client.py: function loop_forever -> line 1292). Btw, I forgot to mention I am using loop_forever, if that is any help.

Also, the messages are being sent with QoS 1. The client doesn't seem to be worried that there is no ACK from the server.



On 05/20/2015 04:18 PM, Ian Craggs wrote:

So, with a keepalive timeout of 60 seconds, the client should send out an MQTT ping request after 60 seconds with no other inbound and outbound traffic, and then if the connection is not working at that point, there will be no ping response from the server, and the client library should call connection lost.

I'm hoping the description of that scenario would help you/us identify whether this is a server or client problem.

You could set the keepalive value to lower than 60 if you would like TCP disconnections to be recognized quicker.

Ian


On 05/20/2015 02:07 PM, Dumitru Melenteanu wrote:
I tried a timeout value of 60 and 120 seconds. There were problems with both.

On 05/20/2015 04:00 PM, Ian Craggs wrote:
Hi,

the keepalive timeout setting is intended to allow the MQTT client to spot that TCP connections have disappeared.   What value are you using?


On 05/12/2015 04:38 PM, Dumitru Melenteanu wrote:
Hi. I've been using paho to send messages from a stranded device with a 3g connection. The connection is relatively stable, but not that good, meaning that there are casual disconnects. Most of the times there is no problem, but sometimes the application doesn't reconnect, although it keeps sending messages, thinking that it is still connected.

I'm using RabbitMQ with the mqtt-plugin as broker; I can see in the logs ``ssl_upgrade_error,timeout``. There is no message in the application logs about it losing connections and it doesn't seem to care that there is no PUBACK message, even if I'm using QOS level 1. It reconnects after a restart.
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev


_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev


_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev

--
Ian Craggs
icraggs@xxxxxxxxxx                 IBM United Kingdom
Paho Project Lead; Committer on Mosquitto

_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev



_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev

-- 
Ian Craggs                          
icraggs@xxxxxxxxxx                 IBM United Kingdom
Paho Project Lead; Committer on Mosquitto


Back to the top