Building the Internet of Things



Download 258.06 Kb.
Page5/13
Date10.06.2017
Size258.06 Kb.
#20222
1   2   3   4   5   6   7   8   9   ...   13

f.Protocol choices


After you have chosen a connectivity type, you need to determine which protocols suit the purpose of your IoT solution. As you can see in the overview of logical protocols, the term protocol applies to different layers in the stack, and there are different protocols to choose from for each layer.

Transport-layer protocol choices


The transport layer provides communication services in the layered architecture of a network. In the Internet era, two such protocols have emerged as favorites: the connection-oriented Transmission Control Protocol (TCP) and the connectionless User Datagram Protocol (UDP). Depending on the environment that an IoT system must function in, the capabilities of its devices, and how much it must guarantee message delivery, you can choose to support either one of these protocols or both of them. The following figure and table provide an overview of the packet structure and a lightweight comparison of TCP and UDP, as well as factors to consider before choosing to use either protocol.



Figure . TCP and UDP basic packet structures

Table . Factors for using TCP vs. UDP

Capability

TCP

UDP

Connection type

Connection-oriented

Connectionless

Reliability

Full

None

Protocol overhead

+++

+

Resource usage

++

+

Broadcast transmission support

no

yes

Ordering of packets

active

none

Header size

20 bytes

8 bytes

Error checking

Yes, retransmit

Yes, no recovery possible

Acknowledgement

Yes

No

Special features

-

Broadcasts

Multicast

UDP is a good candidate to transmit data from constrained devices over constrained networks in close proximity, such as LANs or PANs where congestion and packet loss can be low. The following factors contribute to this:

UDP has very little overhead compared to TCP.

UDP is connectionless, so with no state to maintain, it uses less memory.

UDP transactions require only two datagrams, which reduces network pressure.

UDP has no retransmission delays.

On networks with a higher probability of packet loss, TCP, being more reliable and secure, is a viable candidate. The following factors contribute to this:

TCP supplies reliability, which is especially important in long-haul communications where there is a high chance of packet loss.

Because TCP is connection oriented, a device that uses TCP can better defend itself because it can ignore communications unrelated to current connections, whereas a device that uses UDP must accept every packet it receives on the listening port.

In scenarios that use streaming video or audio, where high throughput is more important than guaranteed packet delivery, and in telemetry solutions in which segments are missing, architects often choose UDP because packet loss is often a better tradeoff than experiencing delays caused by TCP retransmission.38

There are also scenarios where the occasional packet lost for the telemetry channel would be acceptable, but requirements would exist for guaranteed delivery of commands, making the case for a composite model to address these needs to uses both UDP and TCP.

Transport-layer protocol security


Another perspective on the choice between UDP and TCP is security. Because UDP is a connectionless protocol, it lacks the header values that TCP uses for connection management, such as keeping track of packet ordering (sequence numbers) and packet delivery (acknowledgment number), shown in Figure . UDP is thus a more lightweight protocol, but its lack of header values also lowers the barrier that an attacker has to overcome to send false information to the system. The ability of an attacker to “just” spoof the sender address on the IP layer instead of also accounting for altering connection management information demonstrates this vulnerability. In addition to spoofing, UDP is more susceptible to “flooding attacks,” where the attacker floods the system with requests, because of missing flow control39 and subsequent throttling behavior. TCP is also vulnerable to flooding attacks, but TCP systems can be fairly well secured by using SYN cookies.

In our work with customers, we have seen many who use devices with limited resources. For example, a 120 MHz microcontroller, with 256 KB SRAM, and 2 MB flash successfully use TCP as a transport protocol, although the stack in embedded systems often needs modification.40 These customers needed reliability for long-haul (direct) communication.


Application-layer protocol choices


From our experience, we have seen three dominant protocols on the rise in this space:

Advanced Message Queuing Protocol (AMQP). AMQP is an open protocol for message-oriented middleware that JP Morgan Chase developed. The same problems of connecting systems together would crop up regularly. Each time the same discussions about which products to use would happen, and each time the architecture of some system would be curtailed to allow for the fact that the chosen middleware was reassuringly expensive.41

The first implementation of AMQP was iMatix OpenAMQ,42 but others have emerged as well, notably Apache Qpid,43 Microsoft Azure Service Bus,44 and RabbitMQ.45

AMQP is a binary wire protocol that supports programming languages such as C#, C, Java, Perl, Python, Ruby, PHP, and Lisp.

Where many traditional queuing mechanisms have failed, AMQP seems to be thriving and is currently used in many systems, such as:46

Aadhaar,47 a large-scale identity system with 1.2 billion identities and about 100 million authentications per day.48

The National Science Foundation’s Oceans Observatory Initiative, processing 3 petabytes per year49



Figure . Multicast

For more information, see the AMQP site to read the specifications on the protocol or try a free implementation.

Constrained Application Protocol (CoAP).50 Targeted mostly at resource constrained sensors and actuators (devices) such as valves and switches, this protocol fits the bill for specific purpose networks, such as Wireless Sensor Networks (WSNs),51 with applications such as forest fire detection,52 and structural health monitoring.53 CoAP is by default bound to UDP and optionally Datagram Transport Layer Security (DTLS), providing communications privacy. With the default binding to UDP, CoAP supports multicast messaging, allowing for the addressing of a group of destinations at once. CoAP over TCP transport is currently in draft.

MQ Telemetry Transport (MQTT).54, 55 From the documentation, “MQTT is a Client Server publish/subscribe messaging transport protocol. The protocol runs over TCP/IP, or over other network protocols that provide ordered, lossless, bi-directional connections.” MQTT is a publish-subscribe protocol developed for machine-to-machine (M2M) communications, initially created by IBM, and currently undergoing standardization at OASIS.

In projects that we have done where there was a green field for implementation, AMQP has been the best fit because in addition to it being efficient, reliable, flexible, and broker independent, AMQP is native to Microsoft Azure Service Bus, the key technology component for all these customer projects.




Download 258.06 Kb.

Share with your friends:
1   2   3   4   5   6   7   8   9   ...   13



The database is protected by copyright ©ininet.org 2024
send message
    Main page
information contained
current view
issues discussed as
express written permission
authors would like