I would like to compare OPC UA vs MQTT on basis of the general characteristics of both the protocols such as Overhead (Packets), Security, Information modeling and Reliability. Where can I find some sample data for Overhead, and other characteristics, for each protocol so that I compare them. I need your suggestions. You can suggest any tool to compare these protocols.
MQTT is a broker based messaging protocol where the payload encoding and content is completely application specific. Therefore it would be useful if you want to send messages between two applications developed by you.
OPC UA is an architecture (OPC Unified Architecture) where a communication protocol is only a part of the topics addressed. An OPC UA application is able to expose a full meshed network of Objects, Variables, Methods and data structures in an object oriented way. The communication today is based on a client/server model where the server exposes a set of standard services to navigate through the available object, read and write data, call methods or subscribe for data changes or events.
The main goal is to provide interoperability between applications from different vendors by defining the meta meta model on how to make information available, by defining standard services for access to the information and by defining different transport protocols and data encodings for the service invocation. Protocols include an optimized OPC UA binary protocol providing end to end security but also web services or HTTPS based protocols.
The OPC UA working is currently working on a second Publish Subscribe based communication model that allows a messaging between OPC UA applications. Besides a UDP based peer-to-peer protocol, this PubSub extension will also use broker based messaging protocols like AMQP and MQTT.
Therefore it is difficult to compare OPC UA which is a complete set of features including protocols like MQTT and MQTT as stand-alone protocol.
Other responses already include references to MQTT material.
Here are some links to OPC UA material:
Brochure with some high level introduction to OPC UA:
https://opcfoundation.org/resources/brochures/
OPC UA Specifications:
https://opcfoundation.org/developer-tools/specifications-unified-architecture
Free evaluation and test tools:
Test / demo client:
https://www.unified-automation.com/downloads/opc-ua-clients.html
Test / demo servers:
https://www.unified-automation.com/downloads/opc-ua-servers.html
Development tools for different programming languages:
https://www.unified-automation.com/downloads/opc-ua-development.html
I have not seen a OPC UA vs MQTT comparison yet. Bear in mind, that OPC-UA shines most for SCADA systems, MQTT is very good for Publish/Subscribe messaging over unreliable networks like mobile networks.
If low overhead is key for you, MQTT may be a much better fit than OPC-UA. This of course heavily depends on your use case.
You may find this link useful if you're interested in the MQTT overhead: http://stephendnicholas.com/archives/1217
If you're interested in MQTT and security, this blog post series may be helpful to you: http://www.hivemq.com/introducing-the-mqtt-security-fundamentals/
If you're getting started with MQTT, this in-depth blog post series may be valuable for you: http://www.hivemq.com/mqtt-essentials-wrap-up/
OPC UA and MQTT are orthogonal because they try to solve different problems.
The OPC UA WG is currently developing a PubSub extension OPC UA that specifies how OPC UA payloads can be sent over MQTT, AMQP or XMPP.
One of the biggest problems with MQTT is the format of the payload is left to the application which means you have no real inter-operability between applications that have not been specifically coded to work with each other. The OPC UA PubSub extension addresses this limitation by defining a syntax for OPC UA payloads.
Related
I have been developing microservices with Spring Boot for a while, using feign client, rest template and AMPQ brokers to establish communication between each microservice.
Now, I am learning NestJs and its microservice approach. I've noticed that nestjs uses TCP as the default transport layer which is different from the way it is done with Spring Boot.
Why does nestjs prefer those transport layers (TCP, AMPQ) instead of HTTP? isn't HTTP the transport protocol for rest microservices?
From NestJs documentation:
"a microservice is fundamentally an application that uses a different transport layer than HTTP"
The main reason is it is slow. The problem with HTTP approach is that, with HTTP, JSON can generate an unwanted processing time to send and translate the information.
One problem with http-json is the serialization time of JSON sent. This is an expensive process and imagine serialization for a big data.
In addition to JSON, there are a number of HTTP headers that should be
interpreted further which may be discarded. The only concern should be to maintain a single layer for sending and receiving messages. Therefore, the HTTP protocol with JSON to communicate
between microservices is very slow. There are some optimization techniques and those are complex and does not add significant performance benefits
Also,HTTP spends more time waiting than it does transfer data.
If you look a the OSI model, HTTP is part of Layer 7 (Application). TCP is Layer 4 (Transport).
When looking at Layer 4 there is no determining characteristic that makes it HTTP, AMPQ, gRPC, or RTSP. Layer 4 is explicitly how data is transmitted and received with the remote device.
Now, this is where networking and the software development worlds collide. Networking people will use "transport" meaning Layer 4, while Programming people use "transport" meaning the way a packet of data is transmitted to another component.
The meaning of "transport" (or "transporter" as used in the docs) is used as an abstraction from how messages are shared in this architecture.
Looking at the documentation if you are looking for something like AMPQ for your microservice you can use NATS or REDIS (both implementations are built by them).
https://docs.nestjs.com/microservices/basics#getting-started
I am in the process of developing a chat application using Javascript. When sending messages from one client to another client, do I have to send it through a server or can I send it directly from a peer-to-peer approach, using something like websockets ?
Welcome to the stage of life where you see the importance of design patterns.
You can start solutionizing with mediator pattern and proxy pattern with web sockets.
Wheater you need a server or not is up to your design.
Technology-wise there are multiple APIs that HTML5 offers you can go through them and make something on your own.
There is a bunch of APIs available with HTML5 and JS.
Start digging on WebSockets, Server-Sent Events, Web Workers.
The server will give you the flexibility of record-keeping while acting as a mediator. Alternatively, you can come up with a pure p2p design with a scheme where every node or user notify other users with their details(IP) for establishing communication. Remember for web socket to work the client need to know what address to connect to. Maybe it can have fixed master nodes. Then you can use observables for polling and other features. Take a look at the BitTorrent protocol for design inspiration.
Get creative and start designing.
There are many ways to do it. I recommend the scheme:
Peer <---> custom websocket server <---> Peer;
I recommend NodeJS with SocketIO.
I am reading about TCP connections for past few days ,I came across NET as a native nodejs library and socket.io ..can anyone suggest which one will be better with pros and cons of both
socket.io is a specific message based protocol built on top of TCP.
If you want to send messages where you define a message name and send a payload for the message and the other side listens for a specific set of message names and you have a socket.io library already implemented for the other end of your connection, then socket.io will work great and will be a lot simpler to use and offer more ready-made capabilities (such as auto-reconnect).
If you intend to implement your own protocol, then you will use TCP in order to implement your own protocol. If the type of data you are sending is not really message-based (such as audio/video streaming or large file uploads as a couple examples), then you will want to either use TCP or use some other protocol that is also built on top of TCP (such as HTTP, FTP, etc...).
As with any feature in a library, define your requirements, understand the options available in your system and find the solution that best matches your requirements. Since you have said absolutely nothing about your requirements, we cannot make a specific recommendation.
Most examples I have seen are are just small demo's and not full stack applications and they use websocket for messaging, but for any chat application there is more data then just messages...suppose like user profile, his contacts etc.
So should I use websockets for all communication between server and client or just use them for sending messages and do other things through http? If I am to use websocket for all communication how do url design of the app...since websockets don't have have any different urls like http.
You might be interested in WAMP, an officially registered WebSocket subprotocol that provides applications with WebSocket based
asynchronous, bidirectional remote procedure calls
real-time publish & subscribe notifications
Disclaimer: I am original author of WAMP and work for Tavendo.
Pretty sure you'll get the usual "it depends" answer, because, well, it depends!
If you are going to build a large application, to be used by a number of different clients in different network arrangements etc then I personally wouldn't recommend using WebSockets for everything. Why?
It's a new standard, so not all clients support it
In some network configurations WebSocket traffic may be filtered out, meaning you end up with no communications - not great
If you end up exposing an external API then HTTP is much better fitted for the job and will likely be easier to code against. There are a lot more tools out there to help you with it and styles that everyone is familiar with, like REST, to follow.
Use WebSockets when you require data being pushed from the server without the client having to poll for it, or when HTTP header overhead becomes a problem. And if you still decide to use it make sure you have a fallback mechanism (e.g. longpolling) so you don't end up with no comms.
I'm afraid I can't help you regarding WebSocket API design... given it's a new standard I don't believe the community has settled on anything just yet so you'll have to come out with your own message-based scheme.
What is the SMPP protocol and how does it work?
I've not even seen it yet and have to start with introduction onward.
SMPP is a low-level binary Internet protocol.
The primary use of SMPP is to send and receive medium-to-high volumes of SMS texts.
SMPP uses a standard Internet connection to connect to an SMPP provider, to do away with or compliment the purchase of a GSM modem or a SIM card.
SMPP offers the following benefits over a GSM modem:
Send by a meaningful name e.g. a company name instead of phone number.
Send by a short codes; 3, 4, or 5 digit phone number instead of the normal length.
Faster processing
Software:
Kannel is an open-source client for experimenting on.
ActiveXperts Mobile Messaging Toolkit is a commercial solution with SMPP simulator.
For the record: I'm a programmer at ActiveXperts, actively involved in SMPP and SMS related developments.
Fundamentally it's the main protocol that SMS aggregator companies
(mostly!) use when communicating with different type of Gateways (GW).
Please check these links...they will definitely help you out understand SMPP more thoroughly.
http://www.simpleteam.com/downloads/SMPP_v3_4_Issue1_2.pdf
http://www.ehow.com/facts_7344160_smpp-protocol_.html
Wikipedia definition:
"SMPP is a telecommunications industry protocol for exchanging SMS messages between SMS peer entities such as short message service centers and/or External Short Messaging Entities. It is often used to allow third parties (e.g. value-added service providers like news organizations) to submit messages, often in bulk."