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-71) Are messages order within Topic+Qos or within Qos


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

Nick O'Leary commented on MQTT-71:
----------------------------------

In my opinion, your scenario ("bizarrely, Message 2 finishes the ack interactions first.") is not something that should ever happen in a conforming implementation of the protocol and is not onerous to achieve.

If a broker is entirely single threaded then message ordering within topic/qos just happens. On each 'cycle' of processing an epoll event, it reads a packet from the network, initiates onward delivery** and then queues up the ack to be sent back before processing the next epoll event. It is impossible for a single threaded broker operating like this to ack messages, within a particular QoS, out of order. There is no need to re-order messages - they keep themselves in order. This is exactly how RSMB operates.

((** this is where it is vital we are clear that 'initiate onward delivery' does not mean complete all of the subsequent PUBLISH  flows to subscribers of the topic. It means the server has queued up the message for delivery to the subscribers in whatever implementation-specific method makes sense - and that the onward delivery will occur in some future cycle))

Where it gets hairy is when you do have the luxury of multiple threads that start processing the packets from a particular client in parallel. The choices are:

1. use the thread-per-connection model, ensuring only one worker active per connection. This maintains order within QoS levels across all topics. This is what MicroBroker does
2. use multiple threads per connection, ensuring only one worker active per connection/topic. This maintains order within QoS/Topic. This is what, I believe, MessageSight does.

So, we have three separate implementations, RSMB, MicroBroker and MessageSight, that each use a different thread model, assures ordering (at the very least, within QoS/Topic) and none of which requires a large buffer to re-order messages.


> Are messages order within Topic+Qos or within Qos
> -------------------------------------------------
>
>                 Key: MQTT-71
>                 URL: http://tools.oasis-open.org/issues/browse/MQTT-71
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: core
>            Reporter: Andrew Banks
>
> The input specification states 
> •	With an in-flight window greater than 1, message ordering can only be achieved within the QoS level.
> Should we state that 
> messages with the same Qos and Topic Name are delivered in order
> or
> messages with the same Qos regardless of Topic Name are delivered in order

-- 
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]