Attach:

Meow a mi blog: W-blog. cnEMQ official address :emqtt.com/EMQ Chinese document :emqtt.com/docs/v2/gui…

1. Configure ACL authentication rules

In normal services, acLs can be used to restrict client behaviors. For example, client A can only subscribe to /A/ GET queue messages and send messages to /A/ SET Publish content but in MYSQL you have to write two records to do this authentication. If you have a million devices and you have a database that has 2 million authentication data that can affect the performance of the database so is there any way to define ACL authentication in bulk?

In the mysql-ACL authentication configuration file, the SQL on how to use authentication is editable, which means you can implement batch ACL authentication rules in SQL

> vim/usr/local/emqttd/etc/plugins/emq_auth_mysql conf # at the bottom have such a configuration auth. Mysql. Acl_query = the select allow, ipaddr, username, clientid, access, topic from mqtt_acl where ipaddr = '%a' or username = '%u' or username = '$all' or clientid = '%c'Copy the code

By default, each device can subscribe to /A/ GET queue messages and publish to /A/ SET

My current rule is that clients can only write messages to Hello and nothing else is allowed, so 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');Copy the code

Mysql > alter TABLE topic_topic (‘ username ‘, ‘topic’);

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'Copy the code

This allows the client, which is user A, to write messages and listen for messages /A/ GET, even if there is no separate configuration for /A/set to write

2. Shared subscription

Common uses of queues also include scenarios where a message is expected to be received by multiple listeners. The possible scenarios are as follows:

  • One program processing, one program logging separately processing
  • Batch delivery
                            ---------
                            |       | --Msg1,Msg2,Msg3--> Subscriber1
Publisher--Msg1,Msg2,Msg3-->|  EMQ  | --Msg1,Msg2,Msg3--> Subscriber2
                            |       | --Msg1,Msg2,Msg3--> Subscriber3
                            ---------Copy the code

Multiple messages want to be processed by one of multiple applications in the following scenario:

  • Concurrent time-consuming operations are processed in parallel to improve system throughput
                            ---------
                            |       | --Msg1--> Subscriber1
Publisher--Msg1,Msg2,Msg3-->|  EMQ  | --Msg2--> Subscriber2
                            |       | --Msg3--> Subscriber3
                            ---------Copy the code

By default, multiple clients listening for an event receive the same message, but how do you share subscriptions? EMQ shared subscriptions can be used in two ways:

  • $queue/such as: $queue/topic
  • $share / / such as: $share/group/topic

Both can implement shared subscriptions (which I tested with Share), subscriptions, and listening

  • Multiple servers listen for $share/group/topic
  • The client sends messages to the topic

3. The difference of Qos 0/1/2 is measured

The most one-time transport message is transmitted over the TCP/IP network. There is no response and the semantics of retransmission are not defined in the protocol. The message may arrive at the server once, or it may not arrive at all.

At least one transmission message received by the transmission server is acknowledged by transmitting a PUBACK message. If there is a recognizable transmission failure, either the communication connection or the sending device, or if a period of time has elapsed to confirm that the message has not been received, the sender will place the DUP position 1 of the message header and send the message again. Messages arrive at the server at least once. SUBSCRIBE and UNSUBSCRIBE both use QoS of Level 1. If the client does not receive a PUBACK message (either an application-defined timeout or a failure is detected and the session is restarted), the client sends a PUBLISH message again and DUP position 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 realization that the consuming end blocks for 2 seconds to consume one content and the publishing end releases one content in 1 second. After the maximum congestion of EMQ is used up, there will be a lot of repeated messages after the EMQ cache

Only once transmission The protocol stream attached to QoS Level 1 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 a Message ID in the Message header.

4. Salt passwords

In user authentication can use plain | md5 | sha | sha256 | bcrypt hash approaches such as sha256 (default), but for security reasons EMQ also support to password salt, can solve one of the annotation using the way with salt

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,20Copy the code

The corresponding stored passwords will be salted

5.EMQ offline message

  • Retained messages When an MQTT client publishes a Message to the server, you can set the Retained Message flag. Retained messages reside on the Message server and can be received by subsequent subscribers as they subscribe to the topic. Mosquitto_pub -r -q 1 -t a/b/c -m ‘hello’ the MOSQUITto_pub -r -q 1 -t a/b/c -m ‘hello’ is a mosquitto_pub -r -q 1 -t a/b/c -m ‘hello’ is a mosquitto_pub -R -q 1 -t A /b/c -m $mosquitto_sub A /b/c -q 1 Hello Retained Message There are two methods of cleaning it: The client posts an empty Message to the subject of the Retained Message: Mosquitto_pub -r-q 1-t A/B/C-M “Message server sets up the mosquitto_pub to keep messages overdue.
  • When an MQTT client initiates a CONNECT request to the server, the Clean Session flag is used to set the Session. If Clean Session is set to 0, a persistent Session is created. When the client is disconnected, the Session is kept and the offline message is saved until the Session times out and is logged out. If Clean Session is set to 1, a new temporary Session is created. The Session is automatically destroyed when the client is disconnected.

3 summary

There are a lot of details to pay attention to in the use of EMQ and MQTT, and paying attention to the details can go a long way

Note: I have limited ability to say the wrong place hope we can point out, but also hope to communicate more!