•

IP
• Properties
– IP address are lengthened from 32bit
• It has integrated no security and no mobility features.
• Cons
– Limited address space
– NAT functionality needs gateways, etc leads to more cost
IPV6 It has integrated security and mobility features.
– Possibility of adding innovative techniques as location aware addressing.
• Cons
– Larger address width (Having efficient address compression schemes may
alleviate this con)
– Complying to IPv6 node requirements (IPSec is mandated)
TCP
advantages
• Guaranteed Delivery of messages
• Supports a wide range of Application Protocols
• Due to the Flow control feature two devices with different Speeds can Communicate
Without data loss
• The TCP Packets will be routed by the routers in an efficient way to utilize
Bandwidth and balance the load on all the routes
Dis advantage
• Has more Overhead than UDP
• Does not Guarantee the In Order Delivery of Data
• Not suitable for streaming protocols and applications
UDP Adv
• Faster Delivery of messages
 • Supports a wide range of Streaming Application Protocols
• Has Less Overhead than TCP
• The UDP Packets will be routed by the routers in an effective way such that the
packets will arrive at the destination with lowest possible latency
Dis Adv
• The packets may be lost and hence less reliable
• The packets arriving late will be dropped in any streaming application
• Does not has any flow control by default and hence the flow control has to be
implemented at the Application layer
• The application must detect lost packets and retransmit if required

HTTP

CoAP: Constrained Application Protocol

• For Machine –to-Machine (M2M) Application
– Such as constraint environments with constrained devices and constrained
networks
• Is a web transfer protocol like HTTP
• Uses a request-response model
• Runs on top of UDP instead of TCP
• Uses client server architecture where client communicate with servers using
connectionless datagrams
• Supports methods such as
– GET, PUT, POST and DELETE
WebSocket
• It allows full-duplex communications over the single socket connection for sending
message between client and server
• Is based on TCP
• Allows stream of messages to be sent back and forth between client and server
• The client can be a
– Browser
– Mobile Applications
– IoT device
MQTT: Message Queue Telemetry Transport

The goals were to have a protocol, which is bandwidth-efficient and uses little battery power,
because the devices were connected via satellite link and this was extremely expensive at that
time. The protocol uses a publish/subscribe architecture in contrast to HTTP with its
request/response paradigm.Publish/Subscribe is event-driven and enables messages to be
pushed to clients. The central communication point is the MQTT broker, it is in charge of
dispatching all messages between the senders and the rightful receivers. Each client that
publishes a message to the broker, includes a topic into the message. The topic is the routing
information for the broker. Each client that wants to receive messages subscribes to a certain
topic and the broker delivers all messages with the matching topic to the client. Therefore the
clients don’t have to know each other, they only communicate over the topic. This
architecture enables highly scalable solutions without dependencies between the data
producers and the data consumers.
• Lightweight message queuing and transport protocol
• Asynchronous communication model with messages(events)
• Low overhead (2 Bytes header for low network bandwidth applications
• Publish/subscribe(pub sub Model)
• Simple protocol aimed at low complexity, low power and low footprint
Adv-
• Less Overhead
• Multiple QoS types for Reliable exchange of data
• Provides secured communication with SSL Mutual authentication
• Requires Less bandwidth
Disadv
• Connection oriented
• The MQTT brokers requires more resources than the HTTP servers

•
 MQTT Components:
That takes us to the MQTT components, which are 5 as follows:
 Broker, which is the server that handles the data transmission between the clients.
 A topic, which is the place a device want to put or retrieve a message to/from.
 The message, which is the data that a device receives “when subscribing” from a topic or send “when
publishing” to a topic.
 Publish, is the process a device does to send its message to the broker.
 Subscribe, where a device does to retrieve a message from the broker.
Why not HTTP
HTTP is slower, more overhead and power consuming protocol than MQTT. So, let’s get into
each one separately:
 Slower: because it uses bigger data packets to communicate with the server.
 Overhead: HTTP request opens and closes the connection at each request, while MQTT stays online
to make the channel always open between the broker “server” and clients.
 Power consuming: since it takes a longer time and more data packets, therefore it uses much power.

XMPP
It gives the presence of the other users. Watsapp, Google chat etc use XMPP Protocol.
• Extensible Messaging and Presence protocol
• For real-time communication and streaming
• Applications includes
– Messaging, presence, data syndication, gaming, multi-party chat, voice/video
calls
• Uses client-server architecture
• Supports
– Client-to-server communication
– Server-to-server communication
DDS
 • Data Distribution Service
• Uses Publish and subscriber model
• Publisher is an object responsible for data distribution ( Generation)
– Creates topic
• Subscriber responsible for receiving published data
– Subscribes to topic
• DDS provides Quality of Service (QoS) control and configurable reliability
AMQP
• Advanced Message Queuing protocol
• For business messaging
• Supports
– Point-to-point
– Publisher and subscriber models
– Routing and Queuing
• AMQP brokers receive the messages from publisher and route them to the subscribers
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