官網(wǎng)地址 http://activemq.apache.org/apollo/documentation/mqtt-manual.html

MQTT協(xié)議

Apollo允許客戶端使用MQTT連接，該MQTT是一種開源協(xié)議規(guī)范，適用于使用發(fā)布-訂閱域的不可靠網(wǎng)絡上的有限資源設備。這些類型的設備通常需要一個小的內(nèi)存空間，不太適合 text-based 類型的協(xié)議，如HTTP或STOMP，甚至是傳統(tǒng)的二進制協(xié)議，如Openwire或AMQP。MQTT是一種緊湊的二進制協(xié)議，針對這些類型的有限設備和不可靠的網(wǎng)絡進行優(yōu)化。
在以前的版本中，MQTT作為獨立的插件在Apollo中得到支持。到目前為止，這個插件已經(jīng)成為主要開發(fā)的一部分，而MQTT支持可以在沒有任何其他配置或第三方插件打包的情況下使用。
由于MQTT是一個 wire-level 的協(xié)議，任何實現(xiàn)該協(xié)議的客戶端都應該能夠連接到Apollo，并與其他 MQTT-compatibe 消息代理進行互操作。
要了解更多關于MQTT的詳細信息，請參閱MQTT規(guī)范

MQTT 協(xié)議選項

要開始使用MQTT協(xié)議，使用一個有效的MQTT v3.1客戶端并連接到Apollo監(jiān)聽的端口。Apollo將執(zhí)行協(xié)議檢測，并將自動識別MQTT有效負載，并將連接視為MQTT連接。您不必為MQTT(或STOMP、Openwire、AMQP等)打開一個特殊的端口，它們都可以自動檢測到。為了強制某個連接器上的特定協(xié)議，有兩種方法可以做到這一點。您可以選擇不使用協(xié)議檢測，并將連接器設置為專門針對mqtt:

<connector id="tcp" bind="tcp://0.0.0.0:61613" protocol="mqtt"/>

或者，您可以限制使用<detected>配置元素“detected”的協(xié)議:

<connector id="tcp" bind="tcp://0.0.0.0:61613">
  <detect protocols="mqtt openwire" />
</connector>

mqtt元素支持以下 configuration 屬性:

• max_message_length:可以發(fā)送給代理的最大消息的大小(以字節(jié)為單位)。默認為100 mb
• protocol_filters:一個過濾器，它可以過濾被發(fā)送/接收到的客戶的框架。它可以修改框架，甚至放棄它。
• die_delay:在連接實際關閉之前，連接被認為是“死亡(dead)”之后多久;默認值:5000毫秒

也可以使用mqtt配置元素來控制如何解析和解釋目標報頭。支持的屬性有:

• queue_prefix:用來標識目標類型的標記;默認值:空
• path_separator:用于將目標名稱中的部分分隔開;默認值:/
• any_child_wildcard:表示匹配通配符的所有子級目的地;默認值:+
• any_UNK dant_wildcard:指明匹配通配符的目的地;默認值:#
• regex_wildcard_start:用于標識regex開頭的模式
• regex_wildcard_end:用于標識regex結尾的模式
• part_pattern:允許您指定約束命名主題的regex。默認值:[a-zA-Z0-9 \ _ \ \ % \ ~ :()]+

客戶端

Apollo 支持MQTT協(xié)議的v3.1。以下客戶將會工作:

Java : mqtt-client, MeQanTT
C : libmosquitto
Erlang : erlmqtt, my-mqtt4erl
.NET : MQTTDotNet, nMQTT
Perl : net-mqtt-perl, [anyevent-mqtt-perl]https://github.com/beanz/anyevent-mqtt-perl()
Python : nyamuk
Ruby : mqtt-ruby, ruby-em-mqtt
Javascript : Node.js MQTT Client
Delphi : TMQTTCLient
Device specific: Arduino, mbed, Nanode, Netduino
可惜了，沒有php

To see an up-to-date listing of client libraries, please the MQTT website for its softwarelistings
The Apollo distribution ships with an examples
directory where you can find some simple examples of how to use some of those clients to send and receive messages from a broker instance.

Connecting

The default broker configuration secures access to the broker so that only the admin
user can connect. The default password for the admin
user is password
.
MQTT clients cannot specify a Virtual Host (see the section on Virtual Hosts in the user guide) so the default virtual host will be used. This is usually the first Virtual Host defined in the Apollo.xml configuration file.

Destination Types

The MQTT protocol is a publish/subscribe protocol. It does not permit true point-to-point messaging achieved using Queues. Therefore Apollo allows only the use of Topics for MQTT messaging. The concept of a subscription and durable subscription to Topics is similar to what you'd find in other protocols and is controlled by the MQTT CONNECT frame's clean session
attribute.

Clean Sessions

When a client sends a connect frame with the clean session
flag set to cleared (false), any previously used session with the same client_id will be re-used. This means while the client was away, that subscription could have received messages. This is the equivalent of a durable subscription in Apollo.
If the clean session
flag is set (true), then a new session will be started and any sessions tha may have been lingering would be removed. This is equivalent to a normal topic subscription in Apollo.
Topic Retained Messages
If a message has been published with the retain flag set, then the message will be 'remembered' by the topic so that if a new subscription arrives, the last retained message is sent to the subscription. For example if you're publishing measurements and you want the last mesasurement published to always be available to a client that subscribes to the topic, you can set the retain flag on the PUBLISH frame.
Note: retained messages are not retained between broker restarts for Quality of Service setting of AT MOST ONCE (QoS=0).

Last Will and Testament Message

You can set a will
message and assocaited QoS for the message when a client first connects to Apollo. The will message is basically a message that will only get sent if there is an unexpected error with the connection and it must be dropped. This can be useful in situations where you have devices that could drop but when they do, you want to know. So if a medical sensor client drops from the broker, a will message could be sent to an “alarm” Topic and handled by the system as a high-priority alert.

Reliable Messaging

MQTT allows a client to publish a message with the following Quality of Service parameters (QoS):
At Most Once (QoS=0)
At Least Once (QoS=1)
Exactly Once (QoS=2)

At Most Once
This QoS will attempt to deliver the message to a client, but it will have the lowest reliability of the three options. If you publish with a QoS=0, At Most Once, then the broker will not send back an Ack saying it received the message, nor will it retry if the broker fails. This QoS is most similar to non-persistent messages in, for example, JMS.
At Least Once
This QoS setting will ensure that the message is delivered at least once to clients. When publishing with this setting, Apollo will send back a PUBACK frame which acknowledges that the broker has received the message and has taken “ownership” for delivering the message. If the client that published the message with QoS=1 does not recieve the PUBACK in a specified period of time, the client may wish to re-publish the message again with the DUP flag set on the PUBLISH frame. It's possible the broker received the first attempt to publish the message and subsequently published it to listening clients. So if the PUBACK got lost somehwere and the client sends the message again, there will be no duplicate detection, and the broker will send the message again to the topic's subscribers.
Exactly Once
This QoS is the strongest level of reliability afforded by the MQTT protocol. This assures the publisher that its message will not only get to its intended subscribers, but that the message will not be duplicated as it could with QoS=1. This QoS, however, comes with increased network overhead.
When a message is published, the broker will store the message ID and send the message to the Topic where it would be persisted if there are any durable subscriptions. It will then send the PUBREC frame back to the client implying the broker has received the message. At this point the broker will expect the client to send the PUBREL frame to clear the message ID from its session state and complete the send with the broker sending a PUBCOMP.
Wildcard Subscriptions
Wild cards can be used in destination names when subscribing as a consumer. This allows you to subscribe to multiple destinations or hierarchy of destinations.
/
is used to separate names in a path

is used to match any name in a path

is used to recursively match path names

For example using the above, these subscriptions are possible
PRICE/#
: Any price for any product on any exchange
PRICE/STOCK/#
: Any price for a stock on any exchange
PRICE/STOCK/NASDAQ/+
: Any stock price on NASDAQ
PRICE/STOCK/+/IBM
: Any IBM stock price on any exchange

Keep Alive
Apollo will only set a keep-alive/heart-beat monitor if the client has specified a keepAlive
value in the CONNECT frame. If one is specified, the actual value used by Apollo will be 1.5 * the keep alive value. This is in keeping with the MQTT spec.
Destination Name Restrictions
Destination names are restricted to using the characters a-z
, A-Z
, 0-9
, _
, -
%
, ~
, :
, ' ', '(', ')' or .
in addition to composite separator ,
and the wild card *
. Any other characters must be UTF-8 and then URL encoded if you wish to preserve their significance.