Hi,

Thank you very much Paul! I completely agree with you and +1 for the
refactoring of the topic hierarchy.

Regarding the reliable delivery in MQTT, I just checked v3.1 specification
[1] and it has three levels of QoS:

*Three qualities of service for message delivery:*
*- "At most once", where messages are delivered according to the best
efforts of the underlying TCP/IP network. Message loss or duplication can
occur. This level could be used, for example, with ambient sensor data
where it does not matter if an individual reading is lost as the next one
will be published soon after.*
*- "At least once", where messages are assured to arrive but duplicates may
occur.*
*- "Exactly once", where message are assured to arrive exactly once. This
level could be used, for example, with billing systems where duplicate or
lost messages could lead to incorrect charges being applied.*

With "Exactly once" it supports reliable delivery, may be this was
misunderstood in above discussions. My apologies for the confusion.

[1]
http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/MQTT_V3.1_Protocol_Specific.pdf

Thanks


On Thu, Sep 4, 2014 at 11:35 AM, Paul Fremantle <p...@wso2.com> wrote:

> Folks
>
> I am not suggesting we move to MQTT necessarily. However, if we want a
> simple protocol with easy native python support, its not bad. STOMP is also
> good. It is pretty limiting that MQTT doesn't support headers. My only
> comment was that we are not actually using headers properly here.
>
> The refactoring of the topic hierarchy and schemas is a good thing to do,
> but it shouldn't be driven by the protocol. If we want to clean this up
> anyway, then I'm +1, but I don't consider it urgent.
>
> Paul
>
> PS MQTT does support reliable delivery. I don't understand the discussion
> that says it doesn't.
>
>
> On 4 September 2014 15:09, Imesh Gunaratne <im...@apache.org> wrote:
>
>> Based on the above discussion, I guess we need to change the the existing
>>> Stratos messaging model to support the Pub/Sub model and MQTT protocol.
>>>
>>
>> I think this statement is not correct, currently we use Pub/Sub model in
>> Stratos messaging system.
>> AFAIU we are looking at two concerns in this discussion:
>>
>> 1. Using hierarchical topics to avoid using headers.
>> 2. Moving to MQTT from AMQP
>>
>> Just to be clear, point 1 and point 2 are two different things, we might
>> not need to move to MQTT to support point 1.
>>
>> +1 for Paul's suggestions to look at MQTT. It seems to be a very light
>> weight messaging protocol compared to AMQP [1] however I can see following
>> limitations:
>>
>> 1. Unreliable (however can make use of TCP guaranteed delivery and
>> ordering) [1], [2]
>> 2. Less support for security (SSL can be used, has username/password
>> support in v3.1 [3])
>> 3. No support for queues (by design, might not be a problem for us now)
>>
>> On high level, MQTT has been designed for resource-constrained devices
>> and low bandwidth, high latency networks.
>>
>> [1]
>> http://blogs.vmware.com/vfabric/2013/02/choosing-your-messaging-protocol-amqp-mqtt-or-stomp.html
>> [2]
>> http://stackoverflow.com/questions/10462297/mqtt-not-reliable-delivery-instead-of-tcp
>> [3]
>> http://mqtt.org/wiki/doku.php/questions?s[]=delivery#qdoes_mqtt_support_security
>>
>> Thanks
>>
>>
>> --
>> Imesh Gunaratne
>>
>> Technical Lead, WSO2
>> Committer & PMC Member, Apache Stratos
>>
>
>
>
> --
> Paul Fremantle
> CTO and Co-Founder, WSO2
> OASIS WS-RX TC Co-chair, Apache Member
>
> UK: +44 207 096 0336
>
> blog: http://pzf.fremantle.org
> twitter.com/pzfreo
> p...@wso2.com
>
> wso2.com Lean Enterprise Middleware
>
> Disclaimer: This communication may contain privileged or other
> confidential information and is intended exclusively for the addressee/s.
> If you are not the intended recipient/s, or believe that you may have
> received this communication in error, please reply to the sender indicating
> that fact and delete the copy you received and in addition, you should not
> print, copy, retransmit, disseminate, or otherwise use the information
> contained in this communication. Internet communications cannot be
> guaranteed to be timely, secure, error or virus-free. The sender does not
> accept liability for any errors or omissions.
>



-- 
Imesh Gunaratne

Technical Lead, WSO2
Committer & PMC Member, Apache Stratos

Reply via email to