Skip to content
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

Inaccurate keepalive timeout processing #6

Closed
jpwsutton opened this issue Feb 4, 2016 · 1 comment
Closed

Inaccurate keepalive timeout processing #6

jpwsutton opened this issue Feb 4, 2016 · 1 comment

Comments

@jpwsutton
Copy link
Member

migrated from Bugzilla #485807
status ASSIGNED severity normal in component MQTT-C for 1.2
Reported in version unspecified on platform PC
Assigned to: Ian Craggs

On 2016-01-13 23:07:42 -0500, Peng Liu wrote:

In current implementation, the interval that client sends PINGREQ to broker is not the same as the "keepalive interval" specified for the connection. For example, if we specify the interval to be 5 seconds, the real interval could be 7 seconds. This behavior can lead to timeout error in some broker, e.g. mosquitto.

I guess the "keepalive interval" should be set to large value, what is the recommended value for it?
Thanks.

On 2016-01-14 06:38:42 -0500, Ian Craggs wrote:

The reason for setting the keepalive interval to a short period would be to limit the amount of time to discover that a socket has been disconnected (under certain circumstances). It is possible for a socket to continue accepting data for a time after an error has occurred. In this case, the ping request is sent to force a response from the server, to check that packets are actually reaching that server. If there is no response to the pingreq after a "reasonable" amount of time then the client can assume the socket connection is no longer working, and try a new one.

When keeping a connection alive, the MQTT server should also allow a grace period on ping requests before disconnecting the client. This is to allow for network or client processing overheads or timing variances. 50% is a common grace period -- you could check what Mosquitto uses. Of course, the shorter the keepalive interval the larger the percentage error could easily be, and could give rise to the sort of error you are seeing.

To balance the requirements, the most common keepalive interval we use is 60 seconds.

On 2016-01-14 14:47:55 -0500, Peng Liu wrote:

Hi Ian, thanks for your clear explanation.

Yes, you are right, 50% is a common grace period. The inaccuracy of 2 seconds is not big deal for 60s keepalive interval, but for short interval (e.g. 4 seconds) it is. Do you think we need to change the implementation to minimize the inaccuracy? I have this question because I am aware of another mqtt client implementation (mqtt.js) follow the keepalive interval parameter strictly.

@icraggs
Copy link
Contributor

icraggs commented May 31, 2016

I think that a short interval less than 30 seconds (for instance) for keepalive is not a usual requirement. It is an issue if the sender has a small grace period - but for now I want to close this issue. If this is really a problem then we need to look at the specific use case - which version of the client was used, and in what mode, for instance.

@icraggs icraggs closed this as completed May 31, 2016
@frett27 frett27 mentioned this issue Jun 29, 2020
Lazzaretti pushed a commit to ce-rust/paho.mqtt.c that referenced this issue Nov 8, 2020
Removed newlines from log messages
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants