[OASIS Issue Tracker] (MQTT-257) Flow Control

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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

Andrew Banks commented on MQTT-257:
-----------------------------------

Ed,

1) On re connect the number of unacknowledged messages from
   a previous connection needs to count towards the running total
   in Local.TxCredit. 

2) I believe we need to be cautious about restricting when
   a client or server can send DISCONNECT.

   Currently only the Client can send DISCONNECT and some implementations
   of the client try to wait for acknowledgement of existing messages but
   not send new ones before sending DISCONNECT. In fact there are many 
   strategies possible, such as sending all available messages and waiting
   for acknowledgements, or simply sending DISCONNECT freezing the
   session state at the time the client implementation is instructed
   to disconnect.
   
   Some of these tactics lead to delays in the clients terminating or callbacks
   being called after the application writer believes he has finished.
   
   Once we allow the Server to send DISCONNECT and formalize request
   response mechanisms, we need to be careful not to build in
   the possibility of a deadlock where both sides are trying to manipulate their 
   session state so that they can each send DISCONNECT while they are in a
   clean state.  

   Unfortunately it is hard to specify what the client and server are
   allowed to do before they send DISCONNECT because it cannot be distinguished
   from what might have happened anyway. I suggest that we recommend that both
   clients and servers send DISCONNECT without regard to their session state
   and not inhibit the sending of acknowledgments because they intend to send 
   DISCONNECT. We should also point out that Client and Server implementations
   cannot make assumptions the promptness of the other side sending an acknowledgement
   and hence should not wait for one before sending DISCONNECT.   




> 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
(v6.2.2#6258)