O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

What's the Right Messaging Standard for the IoT?

11.119 visualizações

Publicada em

Different messaging and data sharing standards, such as AMQP, CoAP, DDS, MQTT, and REST have been proposed as candidate for addressing the data sharing challenges of the Internet of Things (IoT) and the Industrial Internet (I2).
In technical forums and social media there is no lack of passionate discussions that praise the merits of one standard over the other. Yet, to date, there are little or perhaps no analysis that look at the details of the different standards and perform an in depth, qualitative, analytic and empirical evaluation.

This presentation, will (1) introduce the key standards that are being proposed for the Internet of Things and the Industrial Internet, such as AMQP, CoAP, DDS, MQTT and REST, (2) present a qualitative comparison that highlights the different features provided by the various standards, (3) present an analytic comparison looking at the efficiency and scalability of the various protocols and (3) report the results of an empirical evaluation comparing the actual performances of the various standards.

Publicada em: Tecnologia
  • CAP PROTOCOL?
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • Dear Van Bart,

    Thanks for your comments, those will help me clarify a few
    misconceptions about DDS. As such I'll answer your 3 points and
    then add some further remarks.

    1. The code example on slide #59 is simply showing what is
    needed to write a sample when using MQTT/ProtoBuf vs. using
    DDS. This comparison is precise and accurate as in DDS that's
    only what you have to do -- just create/update the sample and
    call the write operation on the data writer. Concerning your
    comments on the QoS settings, beware that the latest DDS
    Standard API introduces the concept of a QoS provider to allow
    external QoS configuration through URIs. Thus your application
    does not have to be bothered at all with configuring QoS.

    2.a Perhaps you guys had implemented old language bindings. I
    urge you to take a look at the tutorial available at
    http://bit.ly/dds-tutorial-cxx where you'll learn about the new
    C++ API for DDS. Notice that this is now a standard API that
    has been available since 2010. Thus the argument that the DDS
    API is hard is simply out of date.


    2.b Concerning discovery, I can't comment about the
    implementation you were using. What I can share with you is
    that our DDS implementations are often deployed in WLAN and even
    on narrow-band radio-links. I should also mention that the
    discovery protocol can be run as a peer-to-peer protocol or can
    be brokered. For an example of how this can be done with DDS you
    may want to take a look at Vortex Cloud
    (see http://slidesha.re/1qMVPrq). In general, you should realise
    that the DDS wire-protocol which is by nature peer-to-peer can
    be easily brokered when it makes sense. Thus DDS gives you
    choices! Once again take a look at Vortex Cloud.

    3. Again I can't comment on your implementation. What I can say
    is that an implementation can adapt the rate at which it sends
    SPDP (which, BTW, should not be sent very frequently) and even
    heart-beats (sent only by reliable Writers when running on
    UDP/IP) can be piggy-backed on data packets... Once again, I
    don't know how the DDS you used was implemented. But we have
    DDS running very well on mobile devices.

    Beside that, as you discovered in the Vortex Cloud Slides, when
    useful we can broker DDS, in fact we can do even more than
    that. Applications can transparently communicate with each other
    either peer-to-peer or via Vortex-Cloud depending on their
    network connectivity and/or bootstrap-locators.


    In summary, I think that the point you have raised are not
    applicable to DDS per se as a technology but perhaps stem from
    the assumptions made by a particular implementation or from
    the (mis-)use of that implementation.

    Hopefully, these up-to-date information will help you in
    re-evaluate the role of DDS and the advantages it provides over
    MQTT.

    Recall, that DDS is at the foundation of some very complex and
    large-scale systems ranging from power management, to
    hydroelectric power generation, Telemetry for Space Lauch
    Systems, Air Traffic Control and Management, etc. The technology
    has proven in the last few years to have an amazing capability
    of being adapted to different environments. Yet, the secret to
    adaptability lies in the implementation. This is why we have
    different DDS implementation targeting different environments,
    such as Vortex Café, Vortex Web, Vortex Enterprise and Vortex
    Lite.

    A+
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • Although I agree DDS is more powerful, has more features (like filtering, streaming, RPC... etc), I'd like to mention 3 remarks:

    1. The comparison between the number of code lines (slide 59) needed for MQTT vs DDS is a bit over-simplified. The reason is that DDS (and I never used the DDS implementation you tested myself, but another one), configures a lot under the hood for you. The data-writer used in the DDS code sample needs to be configured as well, QOS applied on it... etc. The ping data class (a POJO representation of the data that will be transmitted) is also not counted in.

    2. I have worked for 2 years on a simplified API (called Qeo made by Technicolor and needed because the DDS core API is quite complex and simply not usable by most application programmers). My biggest concern was the discover-ability on LAN and WLAN networks, Keep in mind that DDS uses multicast/broadcast packets to offer it's discovery feature, using keep-alive packets as well, My experience is that a WLAN network with above 5 connected DDS devices start to break down, resulting in DDS entities not being able to discover and hence not being able to communicate with each other.

    3. Power consumption. We had DDS running on mobile (android/ios) devices and I can tell you that it was a disaster. Battery drainage due to constant keep-alive messaging etc... The fact that DDS does not use a broker (which seems to be a big advantage at first), is actually the core reason of this battery issue.

    This being said, I switched to using MQTT because of the 3 issues mentioned. The fact that I have to use a broker (which is not needed in DDS) and have to do my own serialization (JSON is not rocket science), is acceptable for most cases, considering the battery argument,
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • Although I agree DDS is more powerful, has more features (like filtering, streaming, RPC... etc), I'd like to mention 3 remarks:

    1. The comparison between the number of code lines (slide 59) needed for MQTT vs DDS is a bit over-simplified. The reason is that DDS (and I never used the DDS implementation you tested myself, but another one), configures a lot under the hood for you. The datawriter used in the DDS code sample needs to be configured as well, QOS applied on it... etc. The ping data class (a pojo representation of the data that will be transmitted) is also not counted in.

    2. I have worked for 2 years on a simplified API (called Qeo made by Technicolor and needed because the DDS core API is quite complex and simply not usable by most application programmers). My biggest concern was the discover-ability on LAN and WLAN networks, Keep in mind that DDS uses multicast/broadcast packets to offer it's discovery feature, using keep-alive packets as well, My experience is that a WLAN network with above 5 connected DDS devices start to break down, resulting in DDS entities not being able to discover and hence not being able to communicate with each other.

    3. Power consumption. We had DDS running on mobile (android/ios) devices and I can tell you that it was a disaster. Battery drainage due to constant keep-alive messaging etc... The fact that DDS does not use a broker (which seems to be a big advantage at first), is actually the core reason of this battery issue.

    This being said, I switched to using MQTT because of the 3 issues mentioned. The fact that I have to use a broker (which is not needed in DDS) and have to do my own serialization (JSON is not rocket science), is acceptable for most cases, considering the battery argument,
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui

What's the Right Messaging Standard for the IoT?

  1. 1. What is right messaging/data-sharing standard for the IoT? Angelo Corsaro, PhD Chief Technology Officer angelo.corsaro@prismtech.com
  2. 2. Internet of Things (IoT) Flavours
  3. 3. Copyright PrismTech, 2014 Internet of Things Flavours Wikipedia: Interconnection of uniquely identifiable embedded computing-like devices within the existing Internet infrastructure Internet of Things (IoT) was the term used to describe any kind of application that connected and made “things” interact through the internet It is now clear that there are at least two kinds of IoT, Consumer IoT (CIoT) and Industrial IoT (IIoT) The CIoT and IIoT follow the [Collect | Store | Analyse | Share] architecture, yet they have some key differences that is important to understand
  4. 4. Copyright PrismTech, 2014 Consumer Internet of Things (CIoT) The Consumer Internet of Things (CIoT) represents the class of consumer-oriented applications where: Devices are consumer devices, such as smart appliances, e.g. refrigerator, washer, dryer, personal gadgets such as, fitness sensors, google glasses, etc. Data volumes and rates are relatively low Applications are not mission or safety critical, e.g., the failure of fitness gadget will make you, at worse, upset, but won’t cause any harm CIoT applications tend to be “consumer centric”
  5. 5. Copyright PrismTech, 2014 Industrial Internet of Things (IIoT) The Industrial Internet of Things (IIoT) represents industry-oriented applications where: Devices are machines operating in industrial, transportation, energy or medical environment1 Data volumes and rates tend to be from sustained to relatively high Applications are mission and or safety critical, e.g. the failure of a smart grid has severe impact on our life and economy, the misbehaving of a smart traffic system can threaten drivers IIoT applications tend to be “system centric” 1 The list of application domains is supposed to give examples and is not exhaustive
  6. 6. The IoT Data Pipeline
  7. 7. Copyright PrismTech, 2014 Collect | Store | Analyse | Share Collect the data from the cyber-physical world Depending on applications this could be: - Sensor data - Market Data - Web page statistics - ...
  8. 8. Copyright PrismTech, 2014 Collect | Store | Analyse | Share Organise , Store/Cache the data for on-line and off-line processing
  9. 9. Copyright PrismTech, 2014 Collect | Store | Analyse | Share Make sense of the data Detect short term / long term trends ...
  10. 10. Copyright PrismTech, 2014 Collect | Store | Analyse | Share Distribute Analytics -- or any other kind of clues about the data -- to applications that are supposed to act, display, publish, store, etc.
  11. 11. Copyright PrismTech, 2014 Data Sharing in IoT Efficient and scalable Data Sharing is a key requirement of practically any IoT system The degree of performance required by the data sharing platform varies across Consumer and Industrial Internet on Things applications Several standards have been proposed to address this key need of the IoT world
  12. 12. Data Communication Standards
  13. 13. Copyright PrismTech, 2014 Top Contenders The most discussed and promoted standards for the IoT are currently (in alphabetical order) AMQP, CoAP, DDS and MQTT
  14. 14. Copyright PrismTech, 2014 Advanced Message Queueing Protocol (AMQP) Originally defined by the AMQP consortium as a messaging standard addressing the Financial and Enterprise market AMQP is an OASIS standard that defines an efficient, binary, peer-to-peer protocol for for transporting messages between two processes over a network. Above this, the messaging layer defines an abstract message format, with concrete standard encoding https://www.oasis-open.org/committees/amqp/
  15. 15. Copyright PrismTech, 2014 Constrained Application Protocol (CoAP) CoAP is an IETF RFC defining a transfer protocol for constrained nodes and constrained (e.g., low-power, lossy) networks, e.g. 8-bit micro-controllers with small amounts of ROM and RAM, connected by Low-Power Wireless Personal Area Networks (6LoWPANs). The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialised requirements such as multicast support, very low overhead, and simplicity for constrained environments.
  16. 16. Copyright PrismTech, 2014 Data Distribution Service (DDS) DDS is the Object Management Group standard for data-centric publish subscribe DDS is based on a fully distributed architecture and is equipped with a Dynamic Discovery Service that provide information about “who” and “what” is available DDS comes with a rich set of QoS that control data availability, resource usage, e.g. network, memory, etc., and traffic prioritisation The DDS standard family has recently been extended with RPC, Security, Web Integration
  17. 17. Copyright PrismTech, 2014 Message Queueing Telemetry Transport (MQTT) MQTT was defined originally by IBM in the mid 90’s as a lightweight protocol for telemetry MQTT supports a basic publish/subscribe abstraction with three different level of QoS MQTT has recently gained much attention as a potential candidate for data sharing in the IoT
  18. 18. Copyright PrismTech, 2014 Main Characteristics Transport Paradigm Discovery Content Awareness Data! Encoding Security AMQP TCP/IP Point-to-Point Message Exchange No None Defined TLS CoAP UDP/IP Request/Reply (REST) Yes None Defined DTLS DDS UDP/IP TCP/IP Publish/Subscribe Request/Reply Yes Content-Based Routing, Queries Defined TLS, DTLS, DDS Security MQTT TCP/IP Publish/Subscribe No None Undefined TLS
  19. 19. Copyright PrismTech, 2014 Focus… DDS and MQTT are the two protocol gaining more traction as candidate for the IoT DDS applications are today mostly in IIoT while MQTT applications in the CIoT The reminder of this presentation will focus on DDS and MQTT
  20. 20. Protocol Analysis
  21. 21. Copyright PrismTech, 2014 MQTT v3.1.1 MQTT is a Client Server publish/subscribe messaging transport protocol The protocol was designed for constrained environments and communication in Machine to Machine (M2M) and Internet of Things (IoT) contexts where a small code footprint is required and/or network bandwidth is at a premium MQTT transports opaque data and does not define a mechanism to express the payload encoding MQTT is a session oriented protocol — uses the transport connection to identify the session — that and runs over TCP/IP and WebSockets
  22. 22. Copyright PrismTech, 2014 MQTT v3.1.1 MQTT provides three quality of service for message delivery: - At most once: messages are delivered according to the best efforts of the operating environment. Message loss 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: messages are assured to arrive but duplicates can occur. - Exactly once: messages 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.
  23. 23. Copyright PrismTech, 2014 DDS v1.2 The family of DDS standards define an API for peer-to-peer, data-centric, publish/ subscribe and an efficient interoperability wire protocol (DDSI) for disseminating data The DDS standard was designed to address the requirement of a wide range of applications ranging from resource constrained embedded systems to large scale Consumer and Industrial Internet of Things (IoT) Systems DDS provide a rich set of QoS providing control on: - Data Availability: reliability and availability (for late joiners) of published data - Resource Usage: memory and bandwidth utilisation - Timeliness: data prioritisation and end-to-end traffic differentiation
  24. 24. Copyright PrismTech, 2014 DDS v1.2 DDS is data centric, as such: - Supports an extensible payload encoding scheme and supports natively multiple encodings, such as CDR (binary and efficient), PCDR (extensible, binary and efficient), JSON and XML - Supports content filtering and queries. Where content filters are used to route information while queries are used to efficiently select received data DDS can operate on both best effort transports such as UDP/IP as well as reliable transports such as TCP/IP
  25. 25. Copyright PrismTech, 2014 Reliability in DDS and MQTT At Most Once (*) Assumptions: At Least Once Exactly Once* - The network can temporarily becoming unavailable - No application crashes Eventual! Exactly Once* MQTT QoS = 0 QoS = 1 QoS = 2 N.A. DDS Reliability = BEST_EFFORT History = Any DDS doen’t deliver duplicates Reliability = RELIABLE History = KEEP_ALL Reliability = RELIABLE History = N
  26. 26. Message Structure
  27. 27. Copyright PrismTech, 2014 MQTT Message Structure MQTT messages are composed by: Fixed header: included in every message Variable Header: Included in some packets. Its content depends on the packet kind Payload: Included in some packets | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+ | Fixed Header | +-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+ ~ Variable Header ~ +-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+ ~ Payload ~ +-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+
  28. 28. Copyright PrismTech, 2014 MQTT Fixed Header The MQTT fixed header has a length that can vary from 2 to 5 bytes The first two nibbles represents the message type and packet specific control flags From the second byte starts the remaining packet length. This uses a “variable-length-encoding” that can take up to 4 bytes | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+ | message type | Control Flags | +-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐+ ~ Remaining Length (1-­‐4 bytes) ~ +-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+
  29. 29. Copyright PrismTech, 2014 DDSI Message Structure A DDSI message is composed by a Header and a sequence of Sub- Messages The structure of DDSI message make the protocol extensible as new sub message can be added w/o jeopardising backward compatibility Each receiver only interprets the sub-messages it understands 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ | Header | +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ | Submessage | +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ ~ … ~ +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ | Submessage | +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+
  30. 30. Copyright PrismTech, 2014 DDSI Header The header is composed by 4 bytes magic Protocol version Vendor identifier Identifier of the participant that has produced the message (GUID-Prefix) - A participant may have multiple communication end-points (e.g Data Reader and Data Writers) - Each endpoint is identified by a 4 bytes ID, leading to 16 bytes GUID for identifying any communicating entity in the system 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ | 'R’ | 'T' | 'P' | 'S' | +-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+ | ProtocolVersion version | VendorId vendorId | +-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+ | | + + | GuidPrefix guidPrefix | + + | | +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+
  31. 31. Sending Data…
  32. 32. Copyright PrismTech, 2014 MQTT Publish Message Fixed Header DF: Duplication Flag QoS = 0, 1, 2 R: Retain Topic Name (Variable Header) The length depends on the string chosen by the application It is likely, that to avoid collisions, users will give relatively long names such as: -­‐ com/acme/myapp/mytopic Message ID Only present for QoS=1,2 and used to uniquely identify messages Payload Contains the data, but no information on the serialisation format | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+ | message type | DF| QoS | R | +-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐+ ~ Remaining Length (1-­‐4 bytes) ~ +-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+ | Topic Name Length MSB | +-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+ | Topic Name Length LSB | +-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+ | | ~ Topic Name ~ | | +-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+ | Message ID MSB | +-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+ | Message ID LSB | +-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+ | | ~ Payload ~ | | +-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+-­‐-­‐-­‐+
  33. 33. Copyright PrismTech, 2014 DDS Data Message INFO_TS Submessage This is required when source time-stamp is used to order samples coming from different sources DATA Submessage Provides information on the origin and possibly the destination of the message Sequence number Potentially some inline QoS and parameters 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ | 'R’ | 'T' | 'P' | 'S' | +-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+ | ProtocolVersion version | VendorId vendorId | +-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+ | | + + | GuidPrefix guidPrefix | + + | | +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ | INFO_TS |X|X|X|X|X|X|0|E| octetsToNextHeader | +-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+ | | + Timestamp timestamp + | | +-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+ | DATA |X|X|X|X|X|D|Q|E| octetsToNextHeader | +-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+ | Flags extraFlags | octetsToInlineQos | +-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+ | EntityId readerId | +-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+ | EntityId writerId | +-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+ | | + SequenceNumber writerSN + | | +-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+ ~ ParameterList inlineQos [only if Q==1] ~ +-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+ ~ SerializedPayload serializedPayload [only if D==1 || K==1] ~ +-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐+
  34. 34. Overhead Analysis
  35. 35. Copyright PrismTech, 2014 Message Size Proto QoS Data Message Size (bytes) Transport Overhead (bytes) MQTT 0 (2 to 5) + 2 + length(TopicName) + length(Payload) TCP/IP(v4): 20-40 MQTT 1,2 (2 to 5) + 2 + length(TopicName) + 2 length(Payload) TCP/IP(v4): 20-40 DDS DestinationOrder = DestinationTimestamp 44 + length(Payload) UDP/IP(v4): 8 TCP/IP(v4): 20-40 DDS DestinationOrder = SourceTimestamp 56 + length(Payload) UDP/IP(v4): 8 TCP/IP(v4): 20-40
  36. 36. Copyright PrismTech, 2014 MQTT Topic Name The MQTT topic name is included in every PUBLISH message, this it is important to understand its structure In general Topic name have the format: - com/mycompany/app/deviceKind/deviceID Notice that the device or appliance ID is useful to include to to be able to subscribe to the flow coming from a specific device, e.g. the refrigerator, as opposed to all instance of a given device As such the length of the topic name, in real applications is on the order of tens of bytes
  37. 37. Copyright PrismTech, 2014 20 Character MQTT Topic Name Proto QoS Data Message Size (bytes) IP (v4) Headers Total Overhead (bytes) MQTT 0 (2 to 5) + 2 + 20 + length(Payload) IP: 20-40 TCP: 20-40 min = 20 + 20 + 24 = 64 [TCP/IP] max = 40 + 40 + 27 = 107 [TCP/IP] MQTT 1,2 (2 to 5) + 2 + 20 + 2 length(Payload) IP: 20-40 TCP: 20-40 min = 20 + 20 + 26 = 66[TCP/IP] max = 40 + 40 + 29 = 109 [TCP/IP] DDS DestinationOrder = DestinationTimesta mp 44 + length(Payload) IP: 20-40 UDP: 8 TCP: 20-40 min = 20 + 8 + 44 = 72 [UDP/IP] max = 40 + 8 + 44 = 94 [UDP/IP] min = 20 + 20 + 44 = 84 [TCP/IP] max = 40 + 40+ 44 = 124 [TCP/IP] DDS DestinationOrder = SourceTimestamp 56 + length(Payload) IP: 20-40 UDP: 8 TCP: 20-40 min = 20 + 8 + 56 = 84 [UDP/IP] max = 40 + 8 + 56 = 106 [UDP/IP] min = 20 + 20 + 56 = 96 [TCP/IP] max = 40 + 40+ 56 = 136 [TCP/IP]
  38. 38. Copyright PrismTech, 2014 TCP/IP DDSI Streaming When running DDSI over TCP/IP one can transform a stream of DDSI messages into a single streamed message This allows to drop the headers… 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ | Header | +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ | Submessage | +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ | Header | +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ | Submessage | +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ | Header | +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ | Submessage | +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ | Header | +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ | Submessage | +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ | Submessage | +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+ | Submessage | +-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+-­‐+
  39. 39. Copyright PrismTech, 2014 DDSI Streaming Over TCP/IP Proto QoS Data Message Size (bytes) IP (v4) Headers Total Overhead (bytes) MQTT 0 (2 to 5) + 2 + 20 + length(Payload) IP: 20-40 TCP: 20-40 min = 20 + 20 + 24 = 64 [TCP/IP] max = 40 + 40 + 27 = 107 [TCP/IP] MQTT 1,2 (2 to 5) + 2 + 20 + 2 length(Payload) IP: 20-40 TCP: 20-40 min = 20 + 20 + 26 = 66[TCP/IP] max = 40 + 40 + 29 = 109 [TCP/IP] DDS DestinationOrder = DestinationTimesta mp 24 + length(Payload) IP: 20-40 TCP: 20-40 min = 20 + 20 + 24 = 64 [TCP/IP] max = 40 + 40+ 24 = 104 [TCP/IP] DDS DestinationOrder = SourceTimestamp 36 + length(Payload) IP: 20-40 TCP: 20-40 min = 20 + 20 + 36 = 76 [TCP/IP] max = 40 + 40+ 36 = 116 [TCP/IP]
  40. 40. Copyright PrismTech, 2014 Summary MQTT makes a lot of effort to maintain header very compact, yet the Topic-Name included in the Variable Header of every PUBLISH introduces back a lot of overhead In real applications the overhead of DDS when running on UDP/IP is very close to the MQTT overhead When DDS runs over TCP/IP in streaming mode has lower overhead than MQTT, e.g. those using real topic names Thus in summary, MQTT gives away loads of protocol features not to gain so much in efficiency.
  41. 41. Performance Evaluation
  42. 42. Copyright PrismTech, 2014 Performance Evaluation The protocol analysis has already revealed that DDSI wire efficiency, for data transfer, is comparable to that of MQTT Yet, the structure of the two protocols is very different and that may impact the performance over the network due to protocol processing This session, will focus mostly on measuring efficiency, by looking at the end-to-end latency of both protocols
  43. 43. Copyright PrismTech, 2014 General Info To evaluate the efficiency of both DDS and MQTT we will use the traditional latency test for data sizes going from 32 to 16K bytes For evaluating MQTT we have used Mosquitto (www.mosquitto.org) in combination with the Eclipse PAHO MQTT Java Client Library As a DDS implementations we have used the Vortex platform The payload had the same time for both the DDS and the MQTT test. For MQTT the payload was serialised using Google Protocol Buffers All tests were written in Java/Scala, in addition the various products were ran in their “out-the-box” configuration
  44. 44. Copyright PrismTech, 2014 Mosquitto Open Source (BSD licensed) message broker that implements the MQTT v3.1 and v3.1.1 www.mosquitto.org Mosquitto Broker
  45. 45. Copyright PrismTech, 2014 Eclipse paho The Paho project provides open-source client implementations of open and standard messaging protocols aimed at new, existing, and emerging applications for Machine-to-Machine (M2M) and Internet of Things (IoT) http://www.eclipse.org/paho/
  46. 46. Copyright PrismTech, 2014 The Vortex Platform Vortex enable seamless, ubiquitous, efficient and timely data sharing across mobile, embedded, desktop, cloud and web applications OpenSplice Enterprise
  47. 47. Copyright PrismTech, 2014 The Vortex Platform One Standard, One set of Tools, One Goal — Ubiquitous Data Sharing VORTEX Web VORTEX Lite VORTEX Cloud Private Clouds VORTEX Gateway VORTEX Tools • Insight • Record/Replay • Tuner • Tester • Configurator OpenSplice Enterprise VORTEX Café
  48. 48. Copyright PrismTech, 2014 DDS Test Scenario Vortex Café Peer-to-Peer Latency Measure the roundtrip for sending data from ping to pong and back and divide by two to obtain the latency Ping Pong
  49. 49. Copyright PrismTech, 2014 DDS Test Scenario Vortex OpenSplice Peer-to-Peer Latency Measure the roundtrip for sending data from ping to pong and back and divide by two to obtain the latency Ping Pong
  50. 50. Copyright PrismTech, 2014 DDS Test Scenario Vortex Café Latency when brokered by Vortex Cloud Measure the roundtrip for sending data from ping to pong and back and divide by two to obtain the latency Ping Pong
  51. 51. Copyright PrismTech, 2014 MQTT Test Scenario MQTT Latency for QoS = 0 Measure the roundtrip for sending data from ping to pong and back and divide by two to obtain the latency Mosquitto Broker Ping Pong MQTT Java Client MQTT Java Client
  52. 52. Copyright PrismTech, 2014 MQTT Test Scenario MQTT Latency for QoS = 1 Measure the roundtrip for sending data from ping to pong and back and divide by two to obtain the latency Mosquitto Broker Ping Pong MQTT Java Client MQTT Java Client
  53. 53. Copyright PrismTech, 2014 Testbed Linux Workstations running on i7 Intel Processor Gbps Ethernet Network Oracle JVM 1.8.0u20
  54. 54. Copyright PrismTech, 2014 Latency This graph shows: MQTT latency is for QoS = 0 DDS latency is for RELIABILITY=Reliable
  55. 55. Copyright PrismTech, 2014 Latency Analysis Peer-to-Peer DDS latency is always better than MQTT. The difference increases with payload size, to exceed 2x DDS latency through Vortex Cloud is quite close to that of Mosquitto for small data and better for larger payloads (starting from ~2Kbytes)
  56. 56. Copyright PrismTech, 2014 Small Data Latency For small data, DDS is obviously faster then MQTT when non-brokered via Vortex Cloud Vortex Cloud has a slightly higher latency than Mosquitto, but: - Vortex Cloud is at its 1.0 release, still space for performance improvements - Vortex Cloud has more complex logic, as it deals with instances, data-filtering, etc.
  57. 57. Copyright PrismTech, 2014 MQTT Latency for QoS=1 With QoS=1 (or 2) setting for published data, MQTT latency goes up to the sky This behaviour has been reproduced with both Mosquitto and Moquette and apparently depends on the disk access The performance of QoS=1,2 really pose the question of their applicability and scalability
  58. 58. Ease of Use
  59. 59. Copyright PrismTech, 2014 What’s Simpler? Beside simple hello world examples that use Strings, when writing actual data with MQTT, you need to take care of serialisation… And ensure you use the right deserialisation routine on the receiving side… DDS, completely hides away this issues to you BTW… Not to mention the ClientID management…. MQTT DDS val msg = new MqttMessage() builder.setSeqn(count) builder.setPayload(buf) builder.setTimestamp(System.nanoTime()) val sample = builder.build() sample.writeTo(os) val bytes = os.toByteArray msg.setPayload(bytes) msg.setQos(qos) msg.setRetained(false) broker.publish(pingTopic, msg) ! val sample = new PingData(count, buf, System.nanoTime()) dw.write(sample)
  60. 60. Online Discussions
  61. 61. Copyright PrismTech, 2014 MQTT. An Implementer’s Perspective
  62. 62. Copyright PrismTech, 2014 MQTT. An Implementer’s Perspective
  63. 63. Concluding Remarks
  64. 64. Copyright PrismTech, 2014 Summing Up Among the different protocols proposed for the IoT DDS and MQTT have gained quite some attention MQTT has mostly drawn the attention of Consumer IoT community while DDS the attention of the Industrial IoT community This presentation has shown that DDS can be as wire efficient as MQTT and that deliver overall better performance for both M-2-M communication as well as cloud mediated communication
  65. 65. Questions?

×