Chapter 4

Edge to Cloud Protocol

HTTP stands for HyperText Transfer Protocol. It is invented by Tim Berner. HyperText is the type
of text which is specially coded with the help of some standard coding language called HyperText
Markup Language (HTML). HTTP/2 is the successor version of HTTP, which was published on
May 2015. HTTP/3 is the latest version of HTTP, which is published in 2022.
The protocols that are used to transfer hypertext between two computers is known as HyperText
Transfer Protocol.
HTTP provides standard between a web browser and web server to establish communication. It is
set of rules for transferring data from one computer to another. Data such as text, images, and other
multimedia files are shared on the World Wide Web. Whenever a web user opens their web browser,
user indirectly uses HTTP. It is an application protocol which is used for distributed, collaborative,
hypermdia information systems.

How it works ?

First of all, whenever we want to open any website then first we open web browser after that we
will type URL of that website (e.g., www.facebook.com ). This URL is now sent to Domain Name
Server (DNS). Then DNS first check records for this URL in their database, then DNS will return IP
address to web browser corresponding to this URL. Now browser is able to sent request to actual
server.
After server sends data to client, connection will be closed. If we want something else from server
we should have to re-establish connection between client and server.

History ::
Tim Berners Lee and his team at CERN gets credit for inventing original HTTP and associated
technologies.
1. HTTP version 0.9 –This was first version of HTTP which was introduced in 1991.

2. HTTP version 1.0 –In 1996, RFC 1945 (Request For Comments) was introduced in HTTP
version 1.0.

3. HTTP version 1.1 –In January 1997, RFC 2068 was introduced in HTTP version 1.1.
Improvements and updates to HTTP version 1.1 standard were released under RFC 2616 in
June 1999.

4. HTTP version 2.0 –The HTTP version 2.0 specification was published as RFC 7540 on
May 14, 2015.

5. HTTP version 3.0 –HTTP version 3.0 is based on previous RFC draft. It is renamed as
HyperText Transfer Protocol QUIC which is a transport layer network protocol developed
by Google.

Characteristics of HTTP: HTTP is IP based communication protocol which is used to deliver data
from server to client or vice-versa.
1. Server processes a request, which is raised by client and also server and client knows each
other only during current request and response period.
2. Any type of content can be exchanged as long as server and client are compatible with it.
3. Once data is exchanged then servers and client are no more connected with each other.
4. It is a request and response protocol based on client and server requirements.
5. It is connection less protocol because after connection is closed, server does not remember
anything about client and client does not remember anything about server.
6. It is stateless protocol because both client and server does not expecting anything from each
other but they are still able to communicate.

Advantages :

 Memory usage and CPU usage are low because of less simultaneous connections.
 Since there are few TCP connections hence network congestion are less.
 Since handshaking is done at initial connection stage, then latency is reduced because there
is no further need of handshaking for subsequent requests.
 The error can be reports without closing connection.
  HTTP allows HTTP pipe-lining of request or response.
Disadvantages :

 HTTP requires high power to establish communication and transfer data.

 HTTP is less secure, because it does not uses any encryption method like https use TLS to
encrypt normal http requests and response.
 HTTP is not optimized for cellular phone and it is too gabby.
 HTTP does not offer genuine exchange of data because it is less secure.
 Client does not close connection until it receives complete data from server and hence server
needs to wait for data completion and cannot be available for other clients during this time
https://www.geeksforgeeks.org/http-full-form/

WebSocket: WebSocket is bidirectional, a full-duplex protocol that is used in the same scenario of
client-server communication, unlike HTTP it starts from ws:// or wss://. It is a stateful protocol,
which means the connection between client and server will keep alive until it is terminated by either
party (client or server). After closing the connection by either of the client and server, the
connection is terminated from both ends.
Let’s take an example of client-server communication, there is the client which is a web browser
and a server, whenever we initiate the connection between client and server, the client-server made
the handshaking and decide to create a new connection and this connection will keep alive until
terminated by any of them. When the connection is established and alive the communication takes
place using the same connection channel until it is terminated.
This is how after client-server handshaking, the client-server decide on a new connection to keep it
alive, this new connection will be known as WebSocket. Once the communication link
establishment and the connection are opened, message exchange will take place in bidirectional
mode until connection persists between client-server. If anyone of them (client-server) dies or
decide to close the connection is closed by both of the party. The way in which socket works is
slightly different from how HTTP works, the status code 101 denotes the switching protocol in
WebSocket.
When can a web socket be used:

 Real-time web application: Real-time web application uses a web socket to show the data
at the client end, which is continuously being sent by the backend server. In WebSocket, data
is continuously pushed/transmitted into the same connection which is already open, that is
why WebSocket is faster and improves the application performance.
For e.g. in a trading website or bitcoin trading, for displaying the price fluctuation and
movement data is continuously pushed by the backend server to the client end by using a
WebSocket channel.

 Gaming application: In a Gaming application, you might focus on that, data is

continuously received by the server, and without refreshing the UI, it will take effect on the
screen, UI gets automatically refreshed without even establishing the new connection, so it
is very helpful in a Gaming application.

 Chat application: Chat applications use WebSockets to establish the connection only once
for exchange, publishing, and broadcasting the message among the subscribers. It reuses the
same WebSocket connection, for sending and receiving the message and for one-to-one
message transfer.
When not to use WebSocket: WebSocket can be used if we want any real-time updated or
continuous streams of data that are being transmitted over the network. If we want to fetch old data,
or want to get the data only once to process it with an application we should go with HTTP
protocol, old data which is not required very frequently or fetched only once can be queried by the
simple HTTP request, so in this scenario, it’s better not use WebSocket.
Note: RESTful web services are sufficient to get the data from the server if we are loading the data
only once.
Differences between HTTP and WebSocket Connection:

WebSocket Connection HTTP Connection

WebSocket is a bidirectional communication The HTTP protocol is a unidirectional protocol that
protocol that can send the data from the client works on top of TCP protocol which is a
to the server or from the server to the client by connection-oriented transport layer protocol, we
reusing the established connection channel. can create the connection by using HTTP request
The connection is kept alive until terminated methods after getting the response HTTP
by either the client or the server. connection get closed.
Almost all the real-time applications like
(trading, monitoring, notification) services use Simple RESTful application uses HTTP protocol
WebSocket to receive the data on a single which is stateless.
communication channel.
When we do not want to retain a connection for a
All the frequently updated applications used
particular amount of time or reuse the connection
WebSocket because it is faster than HTTP
for transmitting data; An HTTP connection is
Connection.
slower than WebSockets.
https://www.geeksforgeeks.org/what-is-web-socket-and-how-it-is-different-from-the-http/

Message Queuing Telemetry Transport (MQTT) :

It was created by Andy Standford-Clark and Arlen Nipper. It is an IoT interaction protocol based on
the Publish/Subscribe model. This model is a simple model that provides support for QoS (Quality
of Service). Due to its abilities, it can be found in every second IoT based device. This protocol has
many features as it is over TCP and uses SSL/TLS for security. For messaging between server it
uses CONNECT, PUBLISH, SUBSCRIBE, DISCONNECT, etc.
Difference between MQTT and HTTP protocols :

Parameter MQTT HTTP

Message Queuing Telemetry
Abbreviation Hyper Text Transfer Protocol
Transport
It works on publish/subscribe
Architecture It works on request/response model.
model.
Complexity It has less complexity. It is more complex.
It runs over Transmission It runs over Transmission Control Protocol (TCP)
Runs over
Control Protocol. and can also adapted to User Datagram Protocol.
Protocol This protocol’s design is Data
This protocol’s design is Document centric.
Design centric.
The message size generated is The message size generated is more as it uses
Message Size
less as it uses binary format. ASCII format.
Header Size It is of 2 bytes. It is of 8 bytes.
Port Number It works on 1883 port. It works on 80 or 8080 port.
It provides data security with It does not provide security but Https is built for
Data Security
SSL/TLS. that.

https://www.geeksforgeeks.org/difference-between-mqtt-and-http-protocols/

IoT patterns – not found

Introduction of Message Queue Telemetry Transport Protocol (MQTT)

MQTT is simple, lightweight messaging protocol used to establish communication between
multiple devices. It is TCP-based protocol relying on the publish-subscribe model. This
communication protocol is suitable for transmitting data between resource-constrained devices
having low bandwidth and low power requirements. Hence this messaging protocol is widely used
for communication in IoT Framework.
Publish-Subscribe Model :
This model involves multiple clients interacting with each other, without having any direct
connection established between them. All clients communicate with other clients only via third
party known as Broker.
MQTT Client and Broker :
Clients publish messages on different topics to broker. The broker is the central server that receives
these messages and filters them based on their topics. It then sends these messages to respective
clients that have subscribed to those different topics.
Hence client that has subscribed to a specific topic receives all messages published on that topic.
Figure – Publish-Subscribe Model
Here the broker is central hub that receives messages, filters them, and distributes them to
appropriate clients, such that both message publishers, as well as subscribers, are clients.
dvantages :
1. Easy Scalability –

This model is not restricted to one-to-one communication between clients. Although the
publisher client sends a single message on specific topic, broker sends multiple messages to
all different clients subscribed to that topic. Similarly, messages sent by multiple such
publisher clients on multiple different topics will be sent to all multiple clients subscribed to
those topics.
Hence one-to-many, many-to-one, as well as many-to-many communication is possible
using this model. Also, clients can publish data and at the same time receive data due to this
two-way communication protocol. Hence MQTT is considered to be bi-directional protocol.
The default unencrypted MQTT port used for data transmission is 1883. The encrypted port
for secure transmission is 8883.
2. Eliminates insecure connections –

In a complex system where multiple devices are connected with each other, each device not
only has to manage its connections with other devices but also has to ensure that these
connections are secure. But in the publish-subscribe model, the broker becomes central
server managing all security aspects. It is responsible for the authentication and
authorization of all connected clients.
3. Lightweight Communication –

Data transmission is quick, efficient, and lightweight because MQTT messages have small
 code footprint. These control messages have a fixed header of size 2 bytes and payload
message up to size 256 megabytes.
https://www.geeksforgeeks.org/introduction-of-message-queue-telemetry-transport-protocol-mqtt/

MQTT and MQTT-SN are different from each other. MQTT is a protocol which is designed to be
light weight for M2M, but it needs TCP/IP stack to operate. But if the sensor nodes cannot hold the
TCP/IP stack then here comes MQTT-SN which does not depend on TCP/IP for it to operate.
Due to sudden increase of interest in Wireless Sensor Network (because of simplicity, low cost and
easy deployment), a light weight pub-sub protocol has been developed called MQTT-SN. The SN or
Sensor Network in the protocol name indicates that it is specifically designed for sensor networks.
As sensor nodes are specifically made with limited processing capabilities and limited amount of
storage, so these sensor nodes cannot have TCP/IP stack with themselves because TCP/IP protocol
stack is too heavy to be handled by such tiny sensor nodes due to big payload, retry mechanism,
time to live for the packets etc.
MQTT-SN was originally designed for running on top of the Zigbee APS layer. Any network which
provides a bi-directional data transfer service between any node and a particular one (gateway)
should be able to support MQTT-SN.
How MQTT-SN is different from MQTT?
First thing, MQTT-SN is designed to be as close as possible to MQTT, but is adapted to the
particular behavior of wireless communication network such as low bandwidth, high link failures,
short message length etc. Second, MQTT-SN is optimized for the implementation on low cost,
battery-operated devices with limited processing and storage resources. Third, MQTT-SN needs a
bridge to translate MQTT-SN messages into MQTT messages.
Compared to MQTT, MQTT-SN is characterized by following differences –
1) MQTT-SN supports topic ID instead of topic name. First client sends a registration request with
topic name and topic ID (2 octets) to the broker. After the registration is accepted, client uses topic
ID to refer the topic name. This saves media bandwidth and device memory – it is quite expensive
to keep and send topic names like home/livingroom/socket2/meter in memory for each publish
message.
2) The Topic name to topic ID can be preconfigured in MQTT-SN gateway, so that even registration
message can be skipped before publish.
3) A discovery procedure helps clients without a pre-configured server/gateway’s address to
discover the actual network address of an operating server/gateway. Multiple gateways may be
present at the same time within a single wireless network and can co-operate in a load-sharing or
stand-by mode.
4) The Clients connect to the broker through a gateway device, which resides within the sensor
network and connects to the broker.
MQTT-SN Architecture
The architecture of MQTT-SN can be represented by the following figure –
 Fig. 1: Image showing MQTT-SN Architecture

There are three kinds of MQTT-SN components – MQTT-SN clients, MQTT-SN gateways (GW)
and MQTT-SN forwarders. MQTT-SN clients connect themselves to a MQTT server via a MQTT-
SN GW using the MQTT-SN protocol. A MQTT-SN GW may or may not be integrated with a
MQTT server. In case of a stand-alone GW, the MQTT protocol is used between the MQTT server
and the MQTT-SN GW. Its main function is the translation between MQTT and MQTT-SN. MQTT-
SN clients can also access a GW via a forwarder in case the GW is not directly attached to their
network. The forwarder simply encapsulates the MQTT-SN frames it receives on the wireless side
and forwards them unchanged to the GW. In the opposite direction, it releases the frames it receives
from the gateway and sends them to the clients, unchanged too.
There are two types of Gateways depending on how a Gateway performs the protocol translation
between MQTT and MQTT-SN:
1) Transparent Gateway – For each MQTT-SN client, transparent gateway will form an individual
MQTT connection to the MQTT broker.
2) Aggregating Gateway – In this, for all MQTT-SN clients, the Aggregating gateway will form
only one MQTT connection to the MQTT broker. The advantage of using aggregating gateway is
shown where WSN network has large number of sensor nodes because it helps in reducing the
number of MQTT connections that broker has to create with individual client.

The MQTT-SN protocol has the following distinct features –

1) Gateway Advertisement and Discovery – A gateway continuously advertises itself by sending an
ADVERTISE & GWINFO message to all devices that are part of the network. The client discovers
the gateway by the Gateway unique ID. A client maintains the list of all active gateways with the
network address & UID.
2) Client’s Connection Setup – An MQTT-SN client needs to setup a connection to a GW before it
can exchange information with that GW.
 Fig. 7: Image showing MQTT-SN Client Connection Procedure
Check out the MQTT-SN specification for more details on Client connection procedure.
3) Procedure for updating the will data – The client can update the previously registered Will topic
and Will message at any time by sending the WILLTOPICUPD or WILLMSGUPD message.
4) Topic Name Registration Procedure – Because of the limited bandwidth and small payload, a
registration procedure is involved. The client first sends the REGISTER message with the topic
name to the gateway then if GW accepts the registration, it assigns the topic ID on that topic name
and acknowledge it with the REGACK message. In that way, if client sends any message to that
topic, it will not use the long topic name again, it will use only the assigned 2 bytes topic ID.
5) Client Disconnect – A client sends a DISCONNECT message to the GW to indicate that it is
about to close its connection. After this point, the client is then required to establish a new
connection with the GW before it can exchange information with that GW again.
6) Support of Sleeping Client – The broker or server remains aware of the sleeping clients and
buffer the message 0020 to deliver them when they wake up.

https://www.engineersgarage.com/mqtt-for-sensor-networks-mqtt-sn-iot-part-39/

Constrained Application Protocol (aka CoAP) is a specialized web transfer protocol for use with
constrained nodes (low power sensors and actuators) and constrained networks (low power, lossy
network). It enables those nodes to be able to talk with other constrained nodes over Internet. The
protocol is specifically designed for M2M applications such as smart energy, home automation and
many Industrial applications.
 Fig. 1: Overview of CoAP Protocol for Constraint Devices
CoAP protocol is necessary because traditional protocols such as TCP/IP are considered “too
heavy” for IoT applications that involves constrained devices. CoAP protocol runs on devices that
support UDP protocol. In UDP protocol, client and server communicate through connectionless
datagrams.

Fig. 2: Image showing CoAP Protocol Stack

As it is a web transfer protocol, it is based on RESTful architecture which provides a
request/response interaction model between application endpoints and supports built-in discovery of
services and resources. Like HTTP, Servers make resources under URL and clients access those
resources using methods such as GET, PUT, POST and DELETE.
The CoAP protocol has the following features –
1) It provides M2M communication in constrained environment.
2) It provides security of data by datagram transportation layer security (DTLS).
3) Asynchronous message exchange.
4) Low header overhead and parsing complexity
5) URI and content type support
6) UDP binding with optional reliability supporting unicast and multicast requests.
The CoAP is different from other protocols. When compared with HTTP, CoAP is implemented for
IoT and M2M environment to send messages over UDP protocol. To compensate for the
unreliability of UDP protocol, CoAP defines a retransmission mechanism and provides resource
discovery mechanism with resource description.
The MQTT and CoAP, both are designed to consider the long term vision that they need to be used
in lightweight environments. Both works well with low power and network constrained devices. So
the choice really depends on the application. If a M2M network has to be created where messages
must publish from one node to multiple interested nodes, the best choice will be to use MQTT
protocol. But if a M2M network has to be created where commands must be sent to among nodes,
CoAP will be the best choice for that. For example to control an AC from the smart phone, CoAP
would be the smarter choice.
CoAP should be on priority for the following three factors –
• Quality of service with confirmable message
• When multicast support is needed
• Very low overhead and simplicity.

https://www.engineersgarage.com/constrained-application-protocol-iot-part-32/

Basis of COAP MQTT

Message Queuing Telemetry
Abbreviation Constrained Application Protocol
Transport
Communication
It uses Request-Response model. It uses Publish-Subscribe model
Type
This uses both Asynchronous and
Messaging Mode This uses only Asynchronous
Synchronous.
Transport layer This mainly uses User Datagram This mainly uses Transmission
protocol protocol(UDP) Control protocol(TCP)
Header size It has 4 bytes sized header It has 2 bytes sized header
RESTful based Yes it uses REST principles No it does not uses REST principles
It supports and best used for live
Persistence support It does not has such support
data communication
It provides by adding labels to the
Message Labelling It has no such feature.
messages.
It is used in Utility area networks and It is used in IoT applications and is
Usability/Security
has secured mechanism. secure
Effectiveness Effectiveness in LNN is excellent. Effectiveness in LNN is low.
Communication Communication model is many-
Communication model is one-one.
Model many.

https://www.geeksforgeeks.org/difference-between-coap-and-mqtt-protocols/

STOMP provides an interoperable wire format so that STOMP clients can communicate with any
STOMP message broker to provide easy and widespread messaging interoperability among many
languages, platforms and brokers.
STOMP is a very simple and easy to implement protocol, coming from the HTTP school of design;
the server side may be hard to implement well, but it is very easy to write a client to get yourself
connected. For example you can use Telnet to login to any STOMP broker and interact with it!
The protocol is broadly similar to HTTP, and works over TCP using the following commands:
  CONNECT

 SEND

 SUBSCRIBE

 UNSUBSCRIBE

 BEGIN

 COMMIT

 ABORT

 ACK

 NACK

 DISCONNECT

Communication between client and server is through a “frame” consisting of a number of lines. The
first line contains the command, followed by headers in the form <key>: <value> (one per line),
followed by a blank line and then the body content, ending in a null character. Communication
between server and client is through a MESSAGE, RECEIPT or ERROR frame with a similar
format of headers and body content.

https://www.thetechplatform.com/post/stomp-simple-or-streaming-text-orientated-messaging-
protocol

What is Advanced Message Queuing Protocol?

The Advanced Message Queuing Protocol (AMQP) creates interoperability between clients and
brokers (i.e. messaging middleware). Its goal of creation was to enable a wide range of different
applications and systems to be able to work together, regardless of their internal designs,
standardizing enterprise messaging on industrial scale.
AMQP includes the definitions for both the way networking takes place and the way message
broker applications work. This means the specifications for:

 Operations of routing and storage of messages with the message brokers and set of rules to
define how components involved work

 And a wire protocol to implement how communications between the clients and the brokers
performing the above operations work

Reasons for AMQP’s Creation and Use

Before AMQP, there used to be different message brokering and transferring applications created
and set in use by different vendors. However, they had one big problem and it was their lack of
interoperability. There was simply not a way for one to work with another. The only method that
could be used to get different systems using different protocols to work was by introducing an
additional layer for converting messages called messaging bridge. These systems, using individual
adapters to be able to receive messages like regular clients, would be used to connect multiple and
different messaging systems (e.g. WebSphere MQ and another).
AMQP, by offering the clearly defined rules and instructions as we explained above, creates a
common ground which can be used for all message queuing and brokering applications to work and
interoperate.

What are AMQP Use Cases?

Whenever there is a need for high-quality and safe delivery of messages between applications and
processes, AMQP implementing message brokering solutions can be considered for use.

AMQP ensures

 Reliability of message deliveries

 Rapid and ensured delivery of messages

 Message acknowledgements

These capabilities make it ideal for

 Monitoring and globally sharing updates

 Connecting different systems to talks to each other

 Allowing servers to respond to immediate requests quickly and delegate time consuming
tasks for later processing

 Distributing a message to multiple recipients for consumption

 Enabling offline clients to fetch data at a later time

 Introducing fully asynchronous functionality for systems

 Increasing reliability and uptime of application deployments

AMQP Assembly and Terminology

Understanding and working with AMQP involves being familiar with quite a few different terms
and terminology. In this section, we will go over these key parts:

 Broker (Server): An application - implementing the AMQP model - that accepts

connections from clients for message routing, queuing etc.

 Message: Content of data transferred / routed including information such as payload and
message attributes.

 Consumer: An application which receives message(s) - put by a producer - from queues.

 Producer: An application which put messages to a queue via an exchange.

Note: The payload of messages are not defined by the AMQP; various and differing types of data,
therefore, can be transferred using the protocol.

Main AMQP Components

The AMQP Model defining how messages are received, routed, stored, queued and how application
parts handling these tasks work rely on the clear set definitions of the below components:

 Exchange: A part of the broker (i.e. server) which receives messages and routes them to
queues

 Queue (message queue): A named entity which messages are associated with and from
where consumers receive them

 Bindings: Rules for distributing messages from exchanges to queues

How Do AMQP Message Brokers Work?

In AMQP, “message brokers” translate to applications which receive the actual messages and route
(i.e. transfer) them to relevant parties.
APPLICATION EXCHANGE TASK LIST WORKER
[DATA] -------> [DATA] ---> [D]+[D][D][D] ---> [DATA]
Publisher EXCHANGE Queue Consumer

https://www.digitalocean.com/community/tutorials/an-advanced-message-queuing-protocol-amqp-
walkthrough