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] Commented: (MQTT-103) Normative meaning of Keep Alive = 0


    [ http://tools.oasis-open.org/issues/browse/MQTT-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=35949#action_35949 ] 

Andrew Banks commented on MQTT-103:
-----------------------------------

Peter, I think this also needs a non normative comment to say 

"If the client sets Keepalive 0, the client is still allowed to send PINGREQ to test liveness of the server and the network. The server  is still obliged to send a  PINGRESP in resposne as described in 3.12.4"

> Normative meaning of Keep Alive = 0
> -----------------------------------
>
>                 Key: MQTT-103
>                 URL: http://tools.oasis-open.org/issues/browse/MQTT-103
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: core
>            Reporter: Peter Niblett
>            Priority: Minor
>
> The specification currently says "A Keep Alive value of zero (0) has the effect of turning off the keep alive mechanism", but we have no numbered normative statement assigned to that.  I think we should have one - but that means we have to be more precise about what we mean by Keep Alive of 0. 
> I assume we would want Server administrators to be able to terminate connections to Clients at any time, regardless of whether keep alive intervals have expired or not, so we need to make sure that the wording does not preclude this.
> Would we want a Server to be able to terminate the connection to a Keep Alive = 0 client that does not send QoS 1 or QoS 2 acknowledgements? 
> Assuming the answer is no, here are some suggestions
> a) The Server MUST NOT disconnect the Client on the grounds of inactivity
> b) The Server MUST NOT disconnect a Client which fails to send control packets regularly
> c) A client can keep its Network Connection open for an indefinite period of time without sending any control packets. A Server MUST NOT disconnect a Client for doing this.
> If we want to allow the Server to enforce its own timeout on PUBACK / PUBCMP then  we could use a sentence similar to the one above but either
> i) Make the MUST NOT into a SHOULD NOT
> ii) Change "Control Packet" into "PUBLISH packet"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


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