[OASIS Issue Tracker] Commented: (MQTT-71) Are messages order within Topic+Qos or within Qos

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

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

Raphael Cohen commented on MQTT-71:
-----------------------------------

Nick,

I'm not sure I quite understand the implications. I *think* I understand what you want to do is clock-hash based on topic name, so you can hand off to a worker w/o sync? I do want to be certain that one can implement a broker that uses hardly any threads at all - and that:-

(a) doesn't need to be thread-per-connection (as you point out)
(b) doesn't need to have worker threads per client
(c) can be implemented as nothing more than a wrapper around epoll (not poll et al which are defunct) or with libev / libevent. Java 7's NIO2 async comms is a red herring, as it only is truly async on Solaris - everything else is faked using threads, a bit like Posix AIO... (which is also broken, but I digress).

I'd like a (d), that lets one use things like splice / vsplice in Linux for throughput and proxies, too, but that's probably asking too much.

What am I worried about is if we require a design that has to use a large buffer per client to 're-order' received messages. How does your suggestion work out - as you understand it - if a client sends 2 messages:-

QoS 2, Topic A, Message 1
QoS 2, Topic A, Message 2

Now the asks happen, and, bizarely, Message 2 finishes the ack interactions first.

So, with your suggestion, does the broker wait until acks for Message 1 happen to preserve order (or not)? I'm worried that it does we have a problem when the acks are very delayed - or the separation very large. In my previous life, problems like this were solved as 'ordered from the point a message is _signed off_', rather than 'ordered from the point of initial receipt'. If we go for the former, then it's trivial for most implementation kinds to support 'ordered within a topic name'. In the latter, I'm worried.

Any thoughts?


> 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