Extensible Messaging and Presence Protocol (XMPP)
This is a communication IoT protocol for message-oriented middleware based on the XML language. It enables the real-time exchange of structured yet extensible data between any two or more network entities. The protocol was developed by the Jabber open source community in 1999, basically for real-time messaging, presence information, and the maintenance of contact lists.
XMPP enables messaging applications to attain authentication, access control, hop-by-hop and end-to-end encryption. Being a secure protocol, it sits on top of core IoT protocols and connects the client to the server via a stream of XML stanzas. The XML stanza has three main components: message, presence and IQ.
Advanced Message Queuing Protocol (AMQP)
This was developed by John O’Hara at JPMorgan Chase in London. AMQP is an application layer protocol for message-oriented middleware environments. It supports reliable communication via message delivery assurance primitives like at-most once, atleast once and exactly once delivery.
The AMQP protocol consists of a set of components that route and store messages within a broker service, with a set of rules for wiring the components together. The AMQP protocol enables client applications to talk to the broker and interact with the AMQP model. This model has the following three components, which are connected into processing chains in the server to create the desired functionality.
- Exchange: Receives messages from publisher based applications and routes them to ‘message queues’.
- Message queue: Stores messages until they can be safely processed by the consuming client application.
- Binding: States the relationship between the message queue and the exchange.
Data Distribution Service (DDS)
This IoT protocol for real-time machine-to-machine communication was developed by the Object Management Group (OMG). It enables scalable, real-time, dependable, high-performance and interoperable data exchange via the publish-subscribe methodology. As compared to MQTT and CoAP IoT protocols, DDS makes use of brokerless architecture and of multicasting to bring high quality QoS to applications.
DDS can be deployed in platforms ranging from low-footprint devices to the cloud, and supports efficient bandwidth usage as well as the agile orchestration of system components.
The DDS protocol has two main layers: Data Centric Publish-Subscribe (DCPS) and Data-Local Reconstruction Layer (DLRL). DCPS performs the task of delivering the information to subscribers, and the DLRL layer provides an interface to DCPS functionalities, enabling the sharing of distributed data among IoT enabled objects.
Simple Text Oriented Messaging Protocol (STOMP)
This text based protocol was developed to work with message-oriented middleware. It provides an interoperable wire format that enables STOMP clients to communicate with any STOMP message broker to enable easy and widespread messaging interoperability among many languages, platforms and brokers. Like AMQP, STOMP provides the message header with properties and a frame body.
STOMP does not, however, deal in queues and topics—it uses a SEND semantic with a ‘destination’ string. The broker must map it onto something that it understands internally, such as a topic, queue, or exchange. Consumers then SUBSCRIBE to those destinations. Since those destinations are not mandated in the specifications, different brokers may support different flavours of the destination. So, it’s not always straightforward to port code between brokers.
However, STOMP is simple and lightweight (although somewhat verbose on the wire), with a wide range of language bindings. It also provides some transactional semantics. One of the most interesting examples is with RabbitMQ Web Stomp, which allows you to expose messaging in a browser through Web-sockets.
Very Simple Control Protocol (VSCP)
This is more a framework than a protocol. VSCP is highly scalable, has a low footprint and is a free-cum-open source solution for device discovery and identification, device configuration, autonomous device functionality and secure firmware updates. VSCP makes things interact at the application layer. It makes use of CAN, RS-232, Ethernet, TCP/IP, MQTT and 6LowPan.
VSCP uses an event format and supports global unique identiﬁers for nodes, thus making a node identifiable no matter where it is installed in the world. Besides, it includes a register model in order to provide a flexible common interface for node configuration and a model for controlling the functionality of each node. VSCP does not make any assumptions regarding the lower level system used to realise the physical interconnection with the node; therefore, it works with different transport mechanisms such as Ethernet, TCP/IP, wireless, Zigbee, Bluetooth, CAN, GPRS, RS-232 and USB.
VSCP is event-based. Every time an event occurs, it is broadcast to all other nodes on the network. From there on, each node decides on its own if the event received needs to be processed or not. The ﬁnal decision depends on the node’s decision matrix, which is made up of a number of ‘if condition> then action> lines’, where the condition> is evaluated based on the ﬁelds present in the VSCP datagram broadcast to the network.
This article first appeared in open source for you.