OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] (MQTT-278) Server initiated ping

    [ https://issues.oasis-open.org/browse/MQTT-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60841#comment-60841 ] 

Ed Briggs commented on MQTT-278:

I'm unclear of the advantage of a server-initiated PINGREQ given that

1. The Client must send a PINGREQ if it does not send other commands within the keep alive period

2. The server MUST disconnect the client if it does not receive a control packet within 1.5 times the keep
alive period. (this places an upper bound on how long a server can be uncertain about client connectivity)

3. The server is permitted to impose an inactivity timer of it's choosing and disconnect the client at any time
(line 547, 548) so even if client pings are disabled (keep alive period = 0), so there is an upper bound on inactivity
even in this case 

Thus it seems that even without a server-initiated PING, the server can detect an unresponsive client within
1.5 times the ping time out. Further, if PINGREQs continue to arrive, that means that PINGRESPs were delivered.  So
this detects the problem of a TCP half-close.

In passing, in practice I encounter MQTT systems with large subscriber populations for which PINGREQ/RESP
traffic processing is sizable, and may dominate (in terms of numbers of messages/sec) the traffic.  Adding a server
initiated PINGREQ could double that, and it's not clear (to me) this provides better behavior than what is available
with client initiated PINGREQ,  and (possibly) TCP/IP keep alive messages.

> Server initiated ping
> ---------------------
>                 Key: MQTT-278
>                 URL: https://issues.oasis-open.org/browse/MQTT-278
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: futures
>            Reporter: Ken Borgendale
> The MQTT 3.1.1 spec allows the client to send a PINGREQ to the server which has the dual affect of telling the server that the client is still up, and telling the client that the server is still up. 
> Change to also allow the server to also send a PINGREQ to the client. 
> While a server is often informed when a client connection is terminated, it has no method to check this if it is not informed. 
> Also change PINGRESP to be allowed from client to server. 
> While we are at this, we should clarify the expected behavior of either side if they receive a PINGRESP without having send a PINGREQ. My suggestion is that it should be ignored but there is currently no text (normative or not) to indicate what should be done 

This message was sent by Atlassian JIRA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]