Data Streaming via GRPC vs MQTT vs Websockets
When there is a requirement to stream real time data like GPS and sensor data to cloud server, we have three main options to pick from MQTT, Websockets, GRPC the new guy from Google. But which one should we pick is real tough given the situations and requirements.
This article is primarily to brief about the different options and a comparison between each other.
Before we start
MQTT
MQTT[2] (MQ Telemetry Transport) is an open OASIS and ISO standard (ISO/IEC PRF 20922)[3] lightweight, publish-subscribe network protocol that transports messages between devices.
It works on TCP/IP protocol, and is light weight to work with IoT devices like smart bulbs, sensors etc. It works on Pub/Sub model and the connection is not persistent. MQTT client will connect and disconnect to read/write messages like ping. MQTT provides Quality of Service (QoS)level, which is an agreement between the sender of a message and the receiver of a message that defines the guarantee of delivery for a specific message. There are 3 QoS levels in MQTT:
- At most once (0) at most once
- At least once (1)at least once
- Exactly once (2) exactly once
WebSocket
WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011, and the WebSocket API in Web IDL is being standardized by the W3C.
It is based on HTTP1.1 protocol and came to support bi-directional communication which was not supported with plain HTTP1.1 protocol. Websockets maintain persistent connection. Message delivery order will be maintained and there are many libraries and frameworks to support websocket and pub/sub over websockets.
GRPC
gRPC (gRPC Remote Procedure Calls[1]) is an open source remote procedure call (RPC) system initially developed at Google. It uses HTTP/2 for transport, Protocol Buffers as the interface description language, and provides features such as authentication, bidirectional streaming and flow control, blocking or nonblocking bindings, and cancellation and timeouts.
This would look similar to websockets but underlying difference is it works on HTTP2 protocol and the data format for request response would be bound to Protobuf, cannot use JSON or XML. But protobuf is more compact and light weight than the latter. The connection would be persistent and client can invoke the methods in remote server through the connection as needed. It offers 4 types of method call, traditional request/response model, server-side streaming, client side streaming and bi-directional streaming.
I had a requirement to stream live data along with other details and broadcast to the subscribed parties, let us say live stock prices(but with additional details) with the above choices I have to choose one. I tried a small testing on message size and performance for all 3 options. I tried with 2kb and 4kb of message size. Below are the results, perhaps I need to also look cost efficiency of using IoT hub on public clouds and bi-directional communication for some needs.
Above results clearly shows that GRPC wins because of persistent connection and protobuf data format, which is lightweight.
Conclusion
Out of 3 options, it depends on individual requirements to choose one. If it is collecting data from sensors and IoT device the choice would always be MQTT. But if data streaming is between devices which doesnt have resource constraints GRPC and websockets can be an options. For my requirement GRPC is winner.
