New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keepalive timeout for default MQTT Broker is 10s, pubsubclient is default set to 15s? #239
Comments
That is an interesting question. On the other hand we have #223 that says 15seconds is too aggressive and should be lengthened. ¯_(ツ)_/¯ |
The most important is to match server and client. |
Wasn´t personal, sorry. I don´t know who he is. I just meant that the exception could not be the rule and for micro controllers i think that poor network connections will not be the rule, as most of them will be connected to adsl,cable,etc. |
No offense will have been taken. I can assure you of that. The client determines what keepalive is used. Mosquitto defaults are irrelevant to the behaviour of this client - mosquitto must honour what the client says it is going to use. You cannot make any assumptions about a typical client. I have used this in a wide variety of devices and network conditions where different timeouts have been necessary. I am not inclined to change the default value. It had been 15 seconds for 7+ years. If anything, we will make it easier to customise and not rely on editing the header file. |
Strange, because @NonaSuomy opened this because of server <-> client timeouts on 10/15 difference.. I will try here to see if mosquitto 10s conf cause this behaviour |
Humm @knolleary i think i got it the client sets the keepalive part. There is no conf on mqtt conf on server.. it is defined on handshake. |
@knolleary if we could change it in the application code, i.e. over-ride the constant in the MQTT library, that would solve my problem... I can just put the keepalive I want into my app. |
It seems, why 15 seconds works in most cases is because Standard Docs say that the keepalive on the broker will wait for 1.5 times what the client is set to. Basically a buffer zone, so if it waited a few seconds after that because an interrupt or something fired off, ~15s give or take it would drop PubSubClient. Keepalive in the standard documentation is shown as binary 10s, so even though the test went well, can the person above stress test it if they did not, how long did it take for it to actually drop the connection after 15s, was it 16s or 15sx1.5=22.5s? If it obeys what the client tells it (seems like what the doc is saying it should) that would mean my device must have got hung up for more than 22.5s. What happens if there are many clients on the server setting it to 10s because they read that in the docs, does it keep switching on demand for that single ping request session to each keepalive instance device? < Start Documentation > The Keep Alive is a time interval measured in seconds. Expressed as a 16-bit word, it is the maximum time interval that is permitted to elapse between the point at which the Client finishes transmitting one Control Packet and the point it starts sending the next. It is the responsibility of the Client to ensure that the interval between Control Packets being sent does not exceed the Keep Alive value. In the absence of sending any other Control Packets, the Client MUST send a PINGREQ Packet [MQTT-3.1.2-23]. The Client can send PINGREQ at any time, irrespective of the Keep Alive value, and use the PINGRESP to determine that the network and the Server are working. If the Keep Alive value is non-zero and the Server does not receive a Control Packet from the Client within one and a half times the Keep Alive time period, it MUST disconnect the Network Connection to the Client as if the network had failed [MQTT-3.1.2-24]. If a Client does not receive a PINGRESP Packet within a reasonable amount of time after it has sent a PINGREQ, it SHOULD close the Network Connection to the Server. A Keep Alive value of zero (0) has the effect of turning off the keep alive mechanism. This means that, in this case, the Server is not required to disconnect the Client on the grounds of inactivity. Example in the Documentation for a Broker
< / End Documentation > I agree you should have a settable variable in there like for IP/username/password/keepalive as stated above. The other tedious thing is you cannot set the default keepalive value from the config in the standard based Mosquitto broker, should allow you to set a base minimum in the configuration, but I was reading it's only possible to set the keepalive option before you start the server somehow, maybe this was just talking about the client setting it though. It does state below that, that the recommended value should be a few mins.
Wonder why they didn't set a few mins in the example above, seems counter productive. |
In the MQTT protocol, the client determines the keepalive value used on a connection. The broker has no say in it. The only keepalive config option on mosquitto is its bridge keepalive - where it is acting as a client connecting to another broker - https://mosquitto.org/man/mosquitto-conf-5.html |
I can guarantee it is something I am doing wrong causing the over delay can someone point it out to me so I can refactor. I2CMasterBroker
I2CSlaveSensors
It may be that I wait 5 mins (set to 10s for debugging in the code right now) before sending data to the MQTT Broker, but this worked fine when I was not using I2C which the interrupt is probably causing the keepalive timeout or interrupting it when it's about to send delaying it for another 10 seconds somehow. |
@NonaSuomy I'm not going to pick through nearly 1000 lines of code... I have had some reports of interrupts causing issues. I've never had to use the library with interrupts, so I don't know if that is a real issue or not. One suggestion is to add a |
It's only 438 lines in the master where MQTT is concerned and it's well commented probably 50% less without that, another 20% serial debug and pretty linear if you clicked the first shared link it's less scary looking. The second link is for the slave which doesn't deal with MQTT it just tosses the sensor values onto the I2C bus or reads to trigger a relay. Thanks for the tip though was more or less what I was looking for. The areas where I have inserted the PubSubClient stuff does that all look copesetic? The Master basically just grabs sensor values from the I2C bus slaves and then PubSubClient tosses the sensor values to appropriate subscribed topics on the MQTT Broker via Ethernet2. Nothing overly complicated. I will see what millis discovers for timings. |
@knolleary , I know, the thread is a bit older, but concerning timeouts, I have a question. Imagine a MQTT connection has been established between an embedded device and a broker. The embedded device's payload is about 20 MB and should be sent once a minute (just to mention something). Now think about beginning a publish and abruptly pausing the transfer due to necessary operations internally (writing/reading to/from flash, etc.). Let's say this takes half a second or maybe 2 - 5 seconds. Is there a timeout defined somewhere for this case? It's quite clear, that the client is not able to send a PINGREQ because it would interfere with the payload data. Will the broker still be listening without getting the rest of the payload within the keepalive interval? Sure, exceeding the keepalive interval will force a disconnect. Thanks in advance! |
@knolleary , Nick, just wondering if there has been a configuration option added to your pubsubclient library to change the keepalive in code rather than in the .h file? I'm not seeing it anywhere but I could be missing it. I certainly have use cases for this and I'm sure many others too with the advent of IoT and sensors reporting to brokers far less often to conserve power, etc. |
knolleary/pubsubclient#239 So I customized PubSubClient library to set the keepalive under 10 seconds (I will look for a cleaner solution) and added a delay between wifi and mqtt connection checks.
This has to be an option that one can pass/change in run time. Having this hard coded doesn't work for all cases. |
@ayavilevich the latest version of the library allows you to set it. |
@knolleary I hope you can help me. Thx a lot |
@MoHa173 you can increases the keepalive period |
Is this an issue, should this be changed?
I was having timeout and disconnections on broker when I looked into finding a timeout in code, I discovered the default keepalive timeout for Mosquitto is 10s seconds, then I looked at the MQTT_KEEPALIVE in pubsubclient which is default to 15s seconds, I changed this to 10s and never had a timeout problem on the broker again.
The text was updated successfully, but these errors were encountered: