原创 Understanding UDP and the embedded wireless Internet of Things (Part 2)

[Continued from Understanding UDP and the embedded wireless Internet of Things (Part 2)]

CoAP is a web transfer protocol optimised for resource constrained networks typical of IoT and M2M applications. It is based on a REST architecture in which resources are server-controlled abstractions made available by an application process and identified by Universal Resource Identifiers (URIs).

The first significant difference between HTTP and CoAP is in the transport layer upon which they rely. HTTP relies on the Transmission Control Protocol (TCP), which uses a flow control mechanism ill-suited for LLNs. Moreover, its overhead is considered too high for short-lived transactions.

By comparison, CoAP is built on top of the UDP and therefore has significantly lower overhead and is capable of multi-cast support. To maintain all of the performance and resource advantages of UDP without giving up the reliability of the full TCP/IP, CoAP is organised into two layers.

The Transaction layer handles the single message exchange between end points. Four types of messages are handled by this layer: Confirmable (requires an acknowledgment), Non-confirmable (does not need to be acknowledged), Acknowledgment (acknowledges a Confirmable message) and Reset (indicates that a Confirmable message has been receive but context is missing to be processed).

The Request/Response layer is responsible for the transmission of requests and responses for the resource manipulation and transmission. This is the layer where the REST-based communication occurs. A REST request is piggybacked on a Confirmable or Non-confirmable message, while a REST response is piggybacked on the related Acknowledgment message.

Everything I read by the proponents of COAP argues that the use of this dual layer approach allows it to provide reliability mechanisms even without the use of TCP as the transport protocol. This is because a Confirmable message is retransmitted using a default timeout and exponential back-off between retransmissions, until the recipient sends the Acknowledgement message. An important aspect of COAP as far as response time is that when a server receives a request which it is not able to handle immediately, it first acknowledges the reception of the message and sends back the response in an off-line fashion.

To keep the message overhead as small as possible and avoid the significant overhead that the standard HTTP mechanism requires, COAP uses a number of techniques that will require embedded developers to carefully parse their impact on system response times and deterministic operation.

First, CoAP uses a short, fixed-length, compact binary header of 4B followed by compact binary options. A typical request has a total header of about 10-20B. Because a resource on a CoAP server will more often than not change over time, the protocol's been designed to allow a client to constantly observe the resources. The way this is done is that the client (the observer) registers itself to the resource (the subject) by means of a modified GET request sent to the server.

The server establishes an observation relationship between the client and the resource. Whenever the state of the resource changes, the server notifies each client having an observation relationship with the resource. The duration of the observation relationship is negotiated during the registration procedure. While not as neat and efficient as a purely UDP approach, it seems to resolve many of the performance issues.

Second, CoAP also supports other payload encoding standards, such as the widely used Extensible Markup Language (XML), but not your common ordinary garden-varity version. As it is presently implemented, the verbosity and parsing complexity of XML makes it inappropriate for constrained devices. One alternative is the more compact data representation in JSON.

JSON (JavaScript Object Notation) is a lightweight, text-based open standard designed for human-readable data interchange. It is derived from the JavaScript scripting language for representing simple data structures. But what JSON lacks is the flexibility of XML. As a result there are ongoing efforts to develop more compact binary XML-based representations such as the Extensible XML Interchange (EXI).

There is still a lot to learn about the impact of 6LoWPAN, COAP, and other protocols and how embedded developers can take advantage of them. I am still wading my way through the many articles and standards documents trying to learn as much as I can as fast as I can. In relation to COAP and its use of UDP, I still have a lot of questions.

First, even with all the thought that's been put into 6LoWPAN and into such protocols as COAP, will it be enough to penetrate more than the a small portion of embedded applications, especially those in hard real-time and deterministic applications in machine control and industrial control? The original uses of UDP were in wired networking applications that were by-and-large isolated from the outside network and so could make compromises on security and reliability. Not so in 6LoWPAN environments, which are naked to the world and require connectivity to the wider Internet.

Second, compared to the minimalistic UDP implementations that I have seen in the past, the UDP implementation within COAP is positively pudgy. Would this eliminate its use in most sensor networks using 8- and 16bit MCUs?

Third, why was the UDP subset the one that was chosen? Because of the sparse resources it requires, it was certainly most obvious choice. However, there are other variations, such as the TCP extensions for Transactions (T/TCP) that might have been a better starting point. While more complicated and less resource-efficient, T/TCP would be a case of taking one step back in order to take two steps forward: Even though it requires slightly more memory and is less efficient in terms of bandwidth than UDP, it has features that the COAP implementers had to add in to their UDP-derived scheme after the fact.

What is missing in almost everything I have read is an informed embedded systems developer's perspective. For that I look to you, in your comments here.