MQTT and CoAP, IoT Protocols
The IoT needs standard protocols. Two of the most promising for
small devices are MQTT and CoAP.
Both MQTT and CoAP:
Are open standards
Are better suited to constrained environments than HTTP
Provide mechanisms for asynchronous communication
Have a range of implementations
MQTT gives flexibility in communication patterns and acts purely as
a pipe for binary data. CoAP is designed for interoperability
with the web.
MQTT is a publish/subscribe messaging protocol designed for
lightweight M2M communications. It was originally developed by IBM
and is now an open standard.
Architecture
MQTT has a client/server model, where every sensor is a client and
connects to a server, known as a broker, over TCP.
MQTT is message oriented. Every message is a discrete chunk of
data, opaque to the broker.
Every message is published to an address, known as a topic. Clients
may subscribe to multiple topics. Every client subscribed to a topic
receives every message published to the topic.
For example, imagine a simple network with three clients and a
central broker.
All three clients open TCP connections with the broker. Clients B
and C subscribe to the
topic temperature
At a later time, Client A publishes a value of
temperature
. The broker forwards the message to all subscribed clients.
The publisher subscriber model allows MQTT clients to communicate
one-to-one, one-to-many and many-to-one.
Topic matching
In MQTT, topics are hierarchical, like a filing system (eg.
kitchen/oven/temperature). Wildcards are allowed when registering a
subscription (but not when publishing) allowing whole hierarchies to
be observed by clients.
The wildcard + matches any single directory name, # matches any
number of directories of any name.
For example, the topic
kitchen/+/temperature matches kitchen/foo/temperature but not
kitchen/foo/bar/temperature
kitchen/# matches kitchen/fridge/compressor/valve1/temperature
Application Level QoS
MQTT supports three quality of service levels, “Fire and forget”,
“delivered at least once” and “delivered exactly once”.
Last Will And Testament
MQTT clients can register a custom “last will and testament”
message to be sent by the broker if they disconnect. These messages
can be used to signal to subscribers when a device disconnects.
Persistence
MQTT has support for persistent messages stored on the broker. When
publishing messages, clients may request that the broker persists
the message. Only the most recent persistent message is stored. When
a client subscribes to a topic, any persisted message will be sent
to the client.
Unlike a message queue, MQTT brokers do not allow persisted
messages to back up inside the server.
MQTT brokers may require username and password authentication from
clients to connect. To ensure privacy, the TCP connection may be
encrypted with SSL/TLS.
Even though MQTT is designed to be lightweight, it has two
drawbacks for very constrained devices.
Every MQTT client must support TCP and will typically hold a
connection open to the broker at all times. For some environments
where packet loss is high or computing resources are scarce, this is
a problem.
MQTT topic names are often long strings which make them impractical
for 802.15.4.
Both of these shortcomings are addressed by the MQTT-SN protocol,
which defines a UDP mapping of MQTT and adds broker support for
indexing topic names.
CoAP is the Constrained Application Protocol from the CoRE
(Constrained Resource Environments) IETF group.
Architecture
Like HTTP, CoAP is a document transfer protocol. Unlike HTTP, CoAP
is designed for the needs of constrained devices.
CoAP packets are much smaller than HTTP TCP flows. Bitfields and
mappings from strings to integers are used extensively to save
space. Packets are simple to generate and can be parsed in place
without consuming extra RAM in constrained devices.
CoAP runs over UDP, not TCP. Clients and servers communicate
through connectionless datagrams. Retries and reordering are
implemented in the application stack. Removing the need for TCP may
allow full IP networking in small microcontrollers. CoAP allows UDP
broadcast and multicast to be used for addressing.
CoAP follows a client/server model. Clients make requests to
servers, servers send back responses. Clients may GET, PUT, POST and
DELETE resources.
CoAP is designed to interoperate with HTTP and the RESTful web at
large through simple proxies.
Because CoAP is datagram based, it may be used on top of SMS and
other packet based communications protocols.
Application Level QoS
Requests and response messages may be marked as “confirmable” or
“nonconfirmable”. Confirmable messages must be acknowledged by the
receiver with an ack packet.
Nonconfirmable messages are “fire and forget”.
Content Negotiation
Like HTTP, CoAP supports content negotiation. Clients use
options to express a preferred representation of a resource and
servers reply with a
Content-Type
option to tell clients what they’re getting. As with HTTP, this
allows client and server to evolve independently, adding new
representations without affecting each other.
CoAP requests may use query strings in the form
. These can be used to provide search, paging and other features to
Because CoAP is built on top of UDP not TCP, SSL/TLS are not
available to provide security. DTLS, Datagram Transport Layer
Security provides the same assurances as TLS but for transfers of
data over UDP. Typically, DTLS capable CoAP devices will support RSA
and AES or ECC and AES.
CoAP extends the HTTP request model with the ability to observe a
resource. When the observe flag is set on a CoAP GET request, the
server may continue to reply after the initial document has been
transferred. This allows servers to stream state changes to clients
as they occur. Either end may cancel the observation.
Resource Discovery
CoAP defines a standard mechanism for resource discovery. Servers
provide a list of their resources (along with metadata about them)
at /.well-known/core. These links are in the application/link-format
media type and allow a client to discover what resources are
provided and what media types they are.
NAT Issues
In CoAP, a sensor node is typically a server, not a client (though
it may be both). The sensor (or actuator) provides resources which
can be accessed by clients to read or alter the state of the sensor.
As CoAP sensors are servers, they must be able to receive inbound
packets. To function properly behind NAT, a device may first send a
request out to the server, as is done in LWM2M, allowing the router
to associate the two. Although CoAP does not require IPv6, it is
easiest used in IP environments where devices are directly routable.
Comparison
MQTT and CoAP are both useful as IoT protocols, but have
fundamental differences.
MQTT is a many-to-many communication protocol for passing messages
between multiple clients through a central broker. It decouples
producer and consumer by letting clients publish and having the
broker decide where to route and copy messages. While MQTT has some
support for persistence, it does best as a communications bus for
live data.
CoAP is, primarily, a one-to-one protocol for transferring state
information between client and server. While it has support for
observing resources, CoAP is best suited to a state transfer model,
not purely event based.
MQTT clients make a long-lived outgoing TCP connection to a broker.
This usually presents no problem for devices behind NAT. CoAP
clients and servers both send and receive UDP packets. In NAT
environments, tunnelling or port forwarding can be used to allow
CoAP, or devices may first initiate a connection to the head-end as
MQTT provides no support for labelling messages with types or other
metadata to help clients understand it. MQTT messages can be used
for any purpose, but all clients must know the message formats
up-front to allow communication. CoAP, conversely, provides inbuilt
support for content negotiation and discovery allowing devices to
probe each other to find ways of exchanging data.
Both protocols have pros and cons, choosing the right one depends
on your application.
Do experiments, build prototypes and deploy test devices on
Toby Jaffey is Founder and CTO at
which provides knowledge and
systems to help manufacturers connect their products quickly and
effectively, at scale.
Further Reading
Open source implementations:
Open source implementations:
This work is licensed under a .MQTT协议 CoAP协议比较 - 为程序员服务
MQTT协议 CoAP协议比较
再写文章一篇对比一下MQTT与CoAP，极有可能成为物联网协议的两个协议。
MQTT协议优点
多对多的通信协议
IBM，Eurotech(欧泰)，思科和红帽等公司(组织)支持
开放源代码
MQTT协议缺点
没有消息标识(很难理解)。
必须熟悉消息格式才能通信。
CoAP协议优点
URI和 content-type的支持
设计用于Web服务互操作性/易转化为HTTP
可以用在各种不同的基于分组的通信协议
Contiki等公司(组织)支持
使用的设备要能支持UDP和UDP模拟，使其限制在一个范围广泛的设备
主要是一对一的协议（和一些寻找更先进的通信协议）
Phodal's
原文地址：, 感谢原作者分享。
您可能感兴趣的代码谈一谈玩Tinyos(2012年)和Contiki到现在()的感想 - dan158185的日志 -
电子工程世界-论坛
谈一谈玩Tinyos(2012年)和Contiki到现在()的感想
已有 311 次阅读 10:26
1，结缘Tinyos
& && & 被媳妇强迫来到北京工作；她是保定人，离她家近，工作是zigbee行业，我从来北京到现在一直在这个单位，也正是这个关系，上网搜索了解到了TinyOS,怀念当时的谷歌，现
在的搜索都要代理翻墙了，Contiki那会不清楚出没出来，年轻冲动，看着国外TeloSB天价
的开发板，想着为什么不能移植到CC2530，于是开始了自己的2530TinyOS之旅，那个时
候6lowpan的代码固件也就是包头压缩解压缩刚刚出来，还是采用udp广播模式，没有相应
的路由支持，等到大约年底看到了RPL，心里很高兴，马上移植测试；后来的COAP出来，
移植测试，天知道那会的边界路由还是ip-driver，tinyos开发者们自己写的一个串口转soc
ket（BLIP1.0），看了看觉得没什么用处，于是自己写了一个linux串口转socket,来实现2
530串口的直接firefox访问：链接接在这:
2530的驱动部分移植是我自己对照tinyos的tep文档自己测试修改的，当时最初选择了keil
编译器，现在还是回归了IAR，SDCC也可以，，懒得去弄了;
2,移植 到2530的痛苦
& && &移植过程是痛苦的，随着路由协议不断的推出新版本，2530各种捉襟见肘，TeloSB也招架不住了
2530（8K RAM）或者TeloSB（10K RAM），当然还有当时红极一时的（micaz,micaz2早就退出了，
内存更小，没记错好像是4K），于是整天的裁剪2530代码内存申请，8051的内核，IAR对lib6lowpan,
coap等库源码支持性不好，很多需要自己去调试修改，举个简单的例子，我到现在也搞不清楚是不是我
的IAR优化等级是最高的缘故，一个函数的形参是bool的话，函数体执行判断他是true或false都没用，
始终认为是false,如果改成uint8就行了，要说是代码写法问题，可是其他的函数形参bool都可以，唯独
这一个函数当然也是我玩2530的一个个例，现在大家下载到的我的2530的源码，是付出了很多的时间
& && &想想2530既然老是要裁剪并且使用IAR,为什么不能用一款cortex-m3来做呢；首先想到的是stm32w108;
但是对ST做zigbee的经验不太敢相信，好在2538出来了，好吧，开始淘宝买2538板子；买到了板子，自己
再买了XDS100V3，发现我买的板子和我买的编程器 JTAG口对不上，板子卖家不是标准的JTAG口接法，还需
要买转接板，而且代码神马的也没有给我，牛脾气一下子就上来了，让我媳妇自己画2538板子,这两块板子直接
扔了，我这人淘宝买东西从来不退货，后来媳妇的板子做回来，使用网上买了那个长的特别像JLINK的XDS100
V3，发现不了芯片，媳妇急了，检查硬件怎么也没问题，联系仿真器技术支持，好吧，销售转支持，电话第一次
还接，说不清楚，后面直接没接过；重新购买北京一家的XDS100V3，下载成功，板子没有问题;想想干脆淘宝挂
上吧，至少给大家提供学习的选择。但是2530也不能扔掉吧，于是给大家弄了个虚拟机加yeti2方便大家入门！
3，移植2538到TinyOS
& &&&国内外找不见2538移植的资源的，国外github有一家公司做了，但是源码不开放，大哥别闹啊；好吧，从零开始
自己移植，这年头还是得靠自己，视频中大家看到的TinyOS部分视频，的移植都是我自己一个人完成的
4，谈一谈TinyOS和Contiki的选择
& && & 两者都非常优秀；见仁见智，我是两者都玩
& && & TinyOS我接触最早，也是现在认为比较舒服的系统，先不谈新秀RIOT，Contiki相对就没有那么有绅士感觉；
& && & 如果是经验欠缺的可以玩TinyOS,官方的网站文档齐全，甚至齐全到每个例程都有网页介绍；例程源码中也都会
附上测试说明；如何安装测试需要的一些插件（从下载到安装到使用）；对于系统组件网络等部分会提供单元
测试以及（**.py脚本）来解决用户的问题，从单元测试着手一步一步的查找问题；
& && &&&C先呵呵一下哈，我真正测试估计是做视频的期间；2.7版本源码一看2538的驱动就有问题，详情看我的帖子
上github看了一下，都3.0版本了，下载来看看，测试（可以看我的视频）；打开源码一看，驱动目录倒还好，app
应用部分我就头疼了，怎么编译呢，亲，怎么测试呢，亲；新手完全摸不着头脑，上contiki官网找找吧，找了半天
也找不见有用的东西；哎，这玩意初学者难啃的；
& && &&&所以我视频中说TinyOS像商场，Contiki像集贸市场；指得就是对使用者的友好程度；
& && &&&到现在为止的例程视频，不管Contiki也好TinyOS也好，都是官方的源码
& && &&&contiki,测试最新版本3.0
& && &&&tinyos是现在github2015最新的代码，姑且叫2.2.13版本吧
以后我会补充APP的应用；
之所以用2538是因为：
1,&&没有版权问题;不会使用IAR等破解版软件了
2，需要一个资源超过这些系统的经典平台的新平台
& &&&看看TeloSB的垄断，心里就是不舒服，而且TeloSB节点并不能满足应用
& &&&需求；不信大家可以去看看他的测试例程，tinyos官网 网页，一般COAP等协议
& &&&有一句话：只在teloSB节点测试过；后面注意测试命令附近的小字，limit ram，资源所限
& &&&resource只有某些；
3，GCC的编译让我使用很舒服，源码如coap等c库不用再去像2530自己修改了
作者的其他最新日志
评论 ( 个评论)
Powered by6305人阅读
Contiki（16）
Contiki是为了Wireless Sensor Network设计的一个嵌入式系统，侧重于网络。虽然它也可以单独运行，但是这并不是它设计的初衷。
从它的core代码的多少就可以看出，在一共2.4M的代码中，net一个文件夹就占用了1.47M的内容。
在Contiki中包含的协议或机制：
Application： & & & & & & & &CoAp
Transport： & & & & & & & & & UDP
NetWork： & & & & & & & & & &IpV6/RPL
Adaptation: & & & & & & & & & 6LoWPAN
MAC: & & & & & & & & & & & & & &CSMA/link-layer bursts
Radio Duty Cycling: & & & &ContikiMAC
Physical: & & & & & & & & & & & &802.15.4
Communication Architecture:Chameleon(consists of Rime Stack and a set of packet transformation modules)
其中Contiki是一个事件驱动型操作系统，有一个事件驱动的核心。
主要的进程模式是protothread，这个进程模式，使得contiki这个操作系统只使用一个堆栈，节约了本不富裕的嵌入式设备上的内存。
但是这也造成了，在进行进程切换时，系统不会去保存当前进程的堆栈，及寄存器信息，所以contiki也警告说，在protothread模式中编程时，local variable要小心使用。所以一般都是定义 static 和global variable。防止切换时，变量信息丢失。
（使用vim+cscope+needtree+ctag+taglist+taghighlight或者Source Insight等工具查看代码，比较方便）
1、contiki加载protothread进程的方式，通过autostart_processes，这个全局变量，定义了涉及到的进程名及其进程体的函数指针，在运行时，将其加到进程的process_list中。
首先通过AUTOSTART_PROCESSES(&hello_world_process)，
定义autostart_processes这个全局变量，
之后再运行时调用autostart_start(autostart_processes)函数，
在autostart_start(autostart_processes)这个函数中调用 process_start(processes[i], NULL)函数，
将autostart_processes中的一个进程添加到process_list的首部，并改变其中的运行状态，将其设置为PROCESS_STATE_RUNNING,即运行状态在执行时。
在&&process_start(processes[i], NULL)函数中调用process_post_synch(p, PROCESS_EVENT_INIT, (process_data_t)arg)设置事件初始化标志PROCESS_EVENT_INIT
在process_post_synch(p, PROCESS_EVENT_INIT, (process_data_t)arg)中，
调用call_process(p, ev, data);实现设置。
在call_process(p, ev, data)函数中&ret = p-&thread(&p-&pt, ev, data);
通过函数指针调用进程的进程体函数，执行。
至此将所有的进程添加到进程链表中，在执行时遍历链表。
2、在main函数执行的过程中，
&while(1) {
&&&&& /* Reset watchdog. */
&&&&& watchdog_periodic();
&&&&& r = process_run();
&&& } while(r & 0);
&&& ENERGEST_OFF(ENERGEST_TYPE_CPU);
&&& /* watchdog_stop(); */
&&& ENERGEST_ON(ENERGEST_TYPE_LPM);
&&& /* Go to idle mode. */
&&& halSleepWithOptions(SLEEPMODE_IDLE,0);
&&& /* We are awake. */
&&& /* watchdog_start(); */
&&& ENERGEST_OFF(ENERGEST_TYPE_LPM);
&&& ENERGEST_ON(ENERGEST_TYPE_CPU);&
通过，do{}while()；语句实现进程切换，如果r，满足条件则继续执行，不满足，则切换。
3、浅探protothread进程控制模型
通过__LINE__,保存退出前的位置信息，在再次被调用时，通过switch语句跳转到这里执行。
故此，这里还有一点要特别注意的就是，在进程主体函数总不能使用switch语句，因为protothread使用switch进行进程切换，如果使用会出现问题。
Figure 1.由此图可知，如果uIP通过无线传输，则需要Rime协议栈；
同样如果Rime要走以太网，Rime就需要uIP的帮忙（这种情况估计不会用）。
Figure 2.Rime Map（Partial）
Figure 3.Rime 组织结构
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：404783次
积分：5559
积分：5559
排名：第2809名
原创：151篇
转载：37篇
评论：116条
(1)(2)(3)(2)(1)(2)(2)(1)(4)(2)(1)(3)(1)(1)(5)(6)(3)(3)(4)(4)(5)(5)(7)(14)(6)(7)(3)(2)(9)(6)(1)(4)(8)(9)(5)(1)(4)(5)(10)(19)(2)(3)(1)(4)