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-257) Flow Control

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

Ken Borgendale commented on MQTT-257:

If the receiver has packet IDs for which it has sent a PUBREC and not received a PUBREL, then it should decrement its Local.RxMax (again, possibly making this value negative) as it expects to receive either a PUBLISH or PUBREL on that packetID and will increment the credit when it does.  The concept is that for flow control to work the TxCredit of the sender and RxCredit of the receiver must match (with the obvious issues of inflight packets).

I do not see how we can limit the credit to 0-max.  If the current connection has a smaller max than the previous connection, the entire credit could be used up by recovered packet IDs.  We cannot fail to decrement the credit and then increment it when we receive a PUBREL.

If the server responds that it has no previous session, then the client must not take actions which assume the server had an existing session.  It is of course free to re-publish any messages but there is no QoS=2 guarantee in this case since the QoS=2 guarantee requires that the client and server maintain matching state.  Note that unless the client sets CleanStart=0 the server assumes that if it has state the client does as well.  

> Flow Control
> ------------
>                 Key: MQTT-257
>                 URL: https://issues.oasis-open.org/browse/MQTT-257
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: futures
>    Affects Versions: 5
>            Reporter: Peter Niblett
> Developers sometimes ask if there's a way to slow down an MQTT message sender to stop it sending PUBLISH packets faster than the receiver (be it a server or client) is able to process them.
> The receiver can apply back pressure at the TCP/IP level (if it's a TCP/IP transport) or - for QOS 1 and QOS2 - it can delay sending acks so that eventually the sender's inflight message window will fill up, but these mechanisms are a bit crude, and the receiver has no in-band way of letting the sender know what rate is acceptable to it. 
> We need to decide whether this is a problem that affects a significant number of existing or envisaged real-life applications (as opposed to performance and stress tests)

This message was sent by Atlassian JIRA

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