attach:
Meow's blog: w-blog.cn
EMQ official address: http://emqtt.com/
EMQ Chinese documentation: http://emqtt.com/docs/v2/guide.html
1. ACL authentication rules
In normal business use, ACL can be used to limit the behavior of the client. For example, client A can only subscribe to /A/get queue messages and publish content to /A/set, but to process such authentication in MYSQL, it is necessary to write two If the number of devices is one million, the database will have to undertake two million pieces of authentication data, which will greatly affect the performance of the database. Is there any batch method to define ACL authentication?
In the configuration file of mysql-ACL authentication, the SQL on how to use authentication can be edited, which means that you can implement batch ACL authentication rules through SQL.
> vim /usr/local/emqttd/etc/plugins/emq_auth_mysql.conf
# 最下面有这样一条配置
auth.mysql.acl_query = select allow, ipaddr, username, clientid, access, topic from mqtt_acl where ipaddr = '%a' or username = '%u' or username = '$all' or clientid = '%c'
The author here realizes that each device can subscribe to /A/get queue messages and publish to /A/set by default.
The author's current rule is that the client can only write messages to hello. Other operations are not allowed. Let's add two records first.
insert `mqtt_acl`(`allow`,`username`,`access`,`topic`) values(1,'$all',1,'/$user/get');
insert `mqtt_acl`(`allow`,`username`,`access`,`topic`) values(1,'$all',2,'/$user/set');
Then modify the default ACL authentication SQL statement as follows (username is used here as the topic dynamic name and other fields can also be used):
select allow, ipaddr, username, clientid, access, REPLACE(topic,'$user','%u') from mqtt_acl where ipaddr = '%a' or username = '%u' or username = '$all' or clientid = '%c'
In this way, even if there is no independent configuration /A/set that can be written, the client as user A can also write messages, and can also monitor messages /A/get
2. Shared Subscriptions
There are also such scenarios in the common use of queues. A message is expected to be received by multiple listeners. The possible scenarios are as follows:
- One program processing, one program recording log processing separately
- Bulk push
---------
| | --Msg1,Msg2,Msg3--> Subscriber1
Publisher--Msg1,Msg2,Msg3-->| EMQ | --Msg1,Msg2,Msg3--> Subscriber2
| | --Msg1,Msg2,Msg3--> Subscriber3
---------
Multiple messages are expected to be processed by one of multiple programs. The scenarios are as follows:
- Parallel processing of time-consuming operations under concurrent conditions improves system throughput
---------
| | --Msg1--> Subscriber1
Publisher--Msg1,Msg2,Msg3-->| EMQ | --Msg2--> Subscriber2
| | --Msg3--> Subscriber3
---------
By default, when multiple clients listen to an event, they will receive the same message, but how to share the subscription? EMQ shared subscription supports two ways of use:
- $queue/ eg: $queue/topic
- $share/<group>/ 如:$share/group/topic
Both of the above can realize shared subscription (the author tested the value through share to complete the subscription), subscription and monitoring
- Multiple servers listen to $share/group/topic
- The client sends a message to the topic
3. The difference between QoS 0/1/2 is measured
The most-once transmission message is based on TCP/IP network transmission. There is no response, and the semantics of retransmission are not defined in the protocol. The message may arrive at the server 1 time, or it may not arrive at all.
At least once the transmission server receives the message will be acknowledged by transmitting a PUBACK message. If there is an identifiable transmission failure, whether it is the communication connection or the sending device, or the confirmation message has not been received after a period of time, the sender will set the DUP bit in the message header to 1, and then send the message again. The message arrives at the server at least once. Both SUBSCRIBE and UNSUBSCRIBE use level 1 QoS. If the client does not receive a PUBACK message (either by an application-defined timeout, or if a failure is detected and the communication session restarts), the client sends the PUBLISH message again and sets the DUP bit to 1. When it receives duplicate data from the client, the server resends the message to the subscriber and sends another PUBACK message.
The author made a method to realize that the consumer side blocks for 2 seconds to consume a content, and the publisher publishes a content for 1 second. After the maximum congestion of EMQ is used up, there will be many duplicate messages after the message is cached by EMQ.
The additional protocol flow at QoS level 1 for only one transmission ensures that duplicate messages are not delivered to the receiving application. This is the highest level of transport and is used when duplicate messages are not allowed. This increases network traffic, but it is usually acceptable because the message content is important. QoS level 2 has the Message ID in the message header.
4. Password salt
In user authentication, you can use hash methods such as plain | md5 | sha | sha256 | bcrypt (sha256 is used by default), but EMQ also supports salting passwords for security reasons. You can unpack the comments and use the salting method. A sort of
vim /usr/local/emqttd/etc/plugins/emq_auth_mysql.conf
## sha256 with salt prefix
## auth.mysql.password_hash = salt,sha256
## bcrypt with salt only prefix
## auth.mysql.password_hash = salt,bcrypt
## sha256 with salt suffix
## auth.mysql.password_hash = sha256,salt
## pbkdf2 with macfun iterations dklen
## macfun: md4, md5, ripemd160, sha, sha224, sha256, sha384, sha512
## auth.mysql.password_hash = pbkdf2,sha256,1000,20
The corresponding stored password will be salted
5. EMQ offline message
-
Retained message When the MQTT client publishes (PUBLISH) a message to the server, it can set the retained message (Retained Message) flag. Retained messages will reside on the message server, and subsequent subscribers can still receive the message when they subscribe to the topic. For example, the mosquitto command line publishes a retained message to the topic 'a/b/c': mosquitto_pub -r -q 1 -ta/b/c -m 'hello' The connected MQTT client subscribes to the topic 'a/b/c' ', you can still receive the message: $ mosquitto_sub -ta/b/c -q 1 hello There are two ways to clear the retained message: The client publishes an empty message to the topic with retained messages: mosquitto_pub -r -q 1 -ta/b/c -m '' The message server sets the timeout period for retaining messages.
-
cleanSession Clean Session When the MQTT client initiates a CONNECT request to the server, the session can be set through the 'Clean Session' flag. 'Clean Session' is set to 0, which means to create a persistent session, when the client disconnects, the session remains and saves offline messages until the session times out and logs out. 'Clean Session' is set to 1, which means to create a new temporary session, when the client disconnects, the session is automatically destroyed.
3 Summary
There are still many details to pay attention to in the use of EMQ and MQTT, and you can go further by paying attention to details
Note: The author has limited ability and I hope that everyone can point out the wrong places, and I hope to communicate more!