WO2020211344A1 - 一种基于mqtt的消息分发方法、服务器、装置及存储介质 - Google Patents

一种基于mqtt的消息分发方法、服务器、装置及存储介质 Download PDF

Info

Publication number
WO2020211344A1
WO2020211344A1 PCT/CN2019/117334 CN2019117334W WO2020211344A1 WO 2020211344 A1 WO2020211344 A1 WO 2020211344A1 CN 2019117334 W CN2019117334 W CN 2019117334W WO 2020211344 A1 WO2020211344 A1 WO 2020211344A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
sent
client
server
topic
Prior art date
Application number
PCT/CN2019/117334
Other languages
English (en)
French (fr)
Inventor
詹泽
Original Assignee
平安科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 平安科技（深圳）有限公司 filed Critical 平安科技（深圳）有限公司
Publication of WO2020211344A1 publication Critical patent/WO2020211344A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/26—Special purpose or proprietary protocols or architectures

Definitions

  • This application relates to the field of data transmission technology, and in particular to an mqtt-based message distribution method, server, virtual device and storage medium.
  • Message Queuing Telemetry Transport is an instant messaging protocol developed by IBM and may become an important part of the Internet of Things. This protocol supports all platforms and can connect almost all networked objects to the outside world, and is used as a communication protocol for sensors and actuators (such as connecting houses via Twitter).
  • the existing message distribution method will cause the server to store a large amount of Topic, and every time to find the Topic that needs to be sent, it needs to traverse the matching. If there are n Topic, it needs to match n times, and the server runs the message
  • the algorithm used by the distribution program is complex, and the space complexity of the algorithm (the size of the storage space temporarily occupied by the algorithm during operation) and the time complexity (the length of time the algorithm runs) are high, thereby reducing the efficiency of message distribution.
  • the main purpose of this application is to provide a message distribution method, server, virtual device, and storage medium based on mqtt, which aims to solve the technical problem of low message distribution efficiency in the existing message distribution method.
  • an mqtt-based message distribution method provided in this application is applied to a server, and the method includes:
  • Receiving step receiving a message sending request broadcast by the server cluster based on the mqtt protocol
  • Parsing step parsing the message to be sent carried in the message sending request, and determining the topic corresponding to the attribute information of the message to be sent according to the preset mapping relationship between the message attribute information and the topic;
  • the first judging step judging whether the subject has a first preset type field to determine whether the message to be sent is a P2P message;
  • Second judgment step when judging that the message to be sent is a P2P message, judging whether there is a second preset type field in the topic, to judge whether the client corresponding to the second preset type field subscribes to the topic ;
  • Sending step when it is determined that the topic has the second preset type field, the message to be sent corresponding to the topic is sent to the client corresponding to the second preset type field.
  • the present application further provides a server, the server includes a memory and a processor, the memory stores a message distribution program, and when the message distribution program is executed by the processor, the foregoing The steps of the message distribution method.
  • the present application further provides a computer-readable storage medium having a message distribution program stored on the computer-readable storage medium, and the message distribution program may be executed by one or more processors to achieve the above The steps of the message distribution method described.
  • the present application further provides a virtual device, the virtual device includes: a receiving module, a parsing module, a first judgment module, a second judgment module, and a sending module, each module can cooperate to realize the message distribution as described above Method steps.
  • the mqtt-based message distribution method, server, virtual device, and storage medium proposed in this application receive the message sending request broadcast by the server cluster based on the mqtt protocol, and analyze the message to be sent contained in the received message sending request, and then analyze the result according to the analysis result
  • the message sending request is distributed to the corresponding clients.
  • the information transfer between the servers in the server cluster in this application is implemented based on the mqtt protocol, and there is no need to store different message sending requests in the servers of the server cluster, thereby reducing the operation of the
  • the time complexity of the end-of-the-line algorithm further improves the efficiency of message distribution.
  • Figure 1 is an application environment diagram of a preferred embodiment of the application server
  • FIG. 2 is a schematic diagram of program modules of a preferred embodiment of the message distribution program in FIG. 1;
  • FIG. 3 is a schematic flowchart of a preferred embodiment of the message distribution method of this application.
  • the server of the present application may be any server in a server cluster, such as the first server 1 or the second server 2 in FIG. 1.
  • Each server is communicatively connected to multiple clients (only one is shown in the figure), for example, the first server 1 is connected to the first client 14 and the second server 2 is connected to the second client 15.
  • the information transfer between the servers in the server cluster is implemented based on the mqtt protocol. After a certain server receives a message sending request sent by a client, it broadcasts the message sending request to other servers based on the mqtt protocol.
  • the first server 1 receives the message sending request sent by the first client 14 based on mqtt
  • the protocol broadcasts the message sending request in the server cluster.
  • the second server 2 executes the message sending and distributing program 10 to analyze the message carried in the message sending request, and distribute the message sending request to the corresponding client according to the analysis result, such as the second Client 15.
  • this application does not need to store the message sending request separately in other servers in the server cluster, thereby reducing space complexity, improving message distribution efficiency, and identifying topics corresponding to P2P messages. Whether it contains a second preset type field, it will automatically match and send the message to the client corresponding to the topic subscribed to, reducing the complexity of searching for the client.
  • the server such as the first server 1 or the second server 2 in FIG. 1, may be one or more of a rack server, a blade server, a tower server, or a cabinet server.
  • the first server 1 includes, but is not limited to, a memory 11, a processor 12, and a network interface 13.
  • the memory 11 includes at least one type of readable storage medium, and the readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (for example, SD or DX memory, etc.), magnetic memory, magnetic disk, optical disk, etc.
  • the storage 11 may be an internal storage unit of the server, for example, a hard disk of the server.
  • the memory 11 may also be an external storage device of the server, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, and a flash memory equipped on the server. Card (Flash Card) etc.
  • the memory 11 may also include both an internal storage unit of the server and an external storage device.
  • the memory 11 can be used not only to store application software and various types of data installed on the server, such as the code of the message distribution program 10, etc., but also to temporarily store data that has been output or will be output.
  • the processor 12 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other data processing chip, and is used to run the program code or processing stored in the memory 11 Data, for example, execute the message distribution program 10 and so on.
  • CPU central processing unit
  • controller microcontroller
  • microprocessor microprocessor
  • the network interface 13 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface), and is usually used to establish a communication connection between the server and other electronic devices.
  • a standard wired interface and a wireless interface such as a WI-FI interface
  • the first client 14 may be a desktop computer, a notebook, a tablet computer, a mobile phone, or other terminal devices that have a function of sending mqtt messages and can communicate with a server through the network 16.
  • the second client 15 may be a desktop computer, a notebook, a tablet computer, a mobile phone, or a terminal device that has a function of receiving mqtt messages and can communicate with a server through the network 16.
  • the network 16 may be the Internet, a cloud network, a wireless fidelity (Wi-Fi) network, a personal network (PAN), a local area network (LAN), and/or a metropolitan area network (MAN).
  • Wi-Fi wireless fidelity
  • PAN personal network
  • LAN local area network
  • MAN metropolitan area network
  • Various devices in the network environment can be configured to connect to the communication network according to various wired and wireless communication protocols.
  • wired and wireless communication protocols can include but are not limited to at least one of the following: Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), ZigBee, EDGE, IEEE 802.11, Optical Fidelity (Li-Fi), 802.16, IEEE 802.11s, IEEE 802.11g, multi-hop communication, wireless access point (AP), device-to-device communication, cellular communication Protocol and/or Bluetooth (BlueTooth) communication protocol or a combination thereof.
  • TCP/IP Transmission Control Protocol and Internet Protocol
  • UDP User Datagram Protocol
  • HTTP Hypertext Transfer Protocol
  • FTP File Transfer Protocol
  • ZigBee ZigBee
  • EDGE EDGE
  • the server may further include a user interface.
  • the user interface may include a display (Display) and an input unit such as a keyboard (Keyboard).
  • the optional user interface may also include a standard wired interface and a wireless interface.
  • the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, an OLED (Organic Light-Emitting Diode, organic light emitting diode) touch device, etc.
  • the display may also be called a display screen or a display unit, which is used to display the information processed in the server and to display a visualized user interface.
  • FIG. 1 only shows the first server 1 and the second server 2 with components 11-16 and the message distribution program 10.
  • the structure shown in FIG. 1 does not constitute a reference to the first server 1.
  • the definition of the second server 2 may include fewer or more components than shown, or a combination of some components, or a different component arrangement.
  • Receiving step receiving a message sending request broadcast by the server cluster based on the mqtt protocol
  • Parsing step parsing the message to be sent carried in the message sending request, and determining the topic corresponding to the attribute information of the message to be sent according to the preset mapping relationship between the message attribute information and the topic;
  • the first judging step judging whether the subject has a first preset type field to determine whether the message to be sent is a P2P message;
  • Second judgment step when judging that the message to be sent is a P2P message, judging whether there is a second preset type field in the topic, to judge whether the client corresponding to the second preset type field subscribes to the topic ;
  • Sending step when it is determined that the subject has the second preset type field, the message to be sent corresponding to the subject is sent to the client corresponding to the second preset type field.
  • the message sending request is distributed by the load balancing device based on a preset load balancing rule.
  • the message sending request may also be directly sent by the client to the corresponding server.
  • the sending step may further include:
  • the message to be sent is saved to the offline message queue of the server.
  • the sending step may also include:
  • connection request of the client is detected, and when it is detected that the client is online, the message to be sent in the offline message queue is sent to the client.
  • FIG. 2 it is a schematic diagram of program modules of an embodiment of the message distribution program 10 in FIG. 1.
  • the message distribution program 10 is divided into multiple modules, and the multiple modules are stored in the memory 11 and executed by the processor 12 to complete the application.
  • the module referred to in this application refers to a series of computer program instruction segments that can complete specific functions.
  • the message distribution program 10 includes a receiving module 110, an analysis module 120, a first judgment module 130, a second judgment module 140, and a determination module 150.
  • the receiving module 110 is configured to receive a message sending request broadcast by the server cluster based on the mqtt protocol.
  • the server cluster includes multiple servers, such as the first server 1 or the second server 2 shown in FIG. 1. Each server is communicatively connected to multiple clients (only one is shown in the figure), for example, the first server 1 is connected to the first client 14 and the second server 2 is connected to the second client 15.
  • the information transfer between the servers in the server cluster is based on the mqtt protocol.
  • the first client 14 sends a message to the second client 15
  • the user needs to send a message sending request carrying the message to any server (such as the first server 1) in the server cluster through the first client 14.
  • the message sending request carries the message and the attribute information of the message (such as the topic corresponding to the message and the message sending request time, etc.).
  • the first server 1 receives a message sending request allocated by the load device based on a preset load balancing rule.
  • the preset load balancing rules include:
  • the allocation is performed in a polling manner.
  • the ranking of the servers in the server cluster is predetermined, and the message sending request is allocated to the servers in turn.
  • the first server 1 may also directly receive the message sending request sent by the first client 14.
  • rocketMQ messages middleware, used for data exchange between systems, with high throughput, high availability, and suitable for large-scale distributed system applications
  • redis database
  • the receiving module 110 is also used for:
  • the message to be sent of the first preset type (for example, mqtt) is read by the first server 1, and the message to be sent of the first preset type is converted to the second preset type (for example, rocketMQ) based on the preset conversion rule.
  • the purpose of this step is to communicate between the first type of message (for example, mqtt message) and the second type of message (for example, rocketMQ message), because you have the same type of message, such as mqtt message and rocketMQ message.
  • the protocols are different, so it is necessary to design a solution for mutual analysis of different types of messages;
  • the message of the second preset type is sent to rocketMQ, for the rocketMQ to broadcast the message of the second preset type to each server in the server cluster.
  • a topic that handles the mqtt protocol needs to be created in rocketMQ, and the message of the topic is an mqtt message.
  • All mqtt servers (all servers in the server cluster) internally start a rocketMQ producer and a rocketMQ consumer.
  • the first client 14 sends a message to the mqtt server (first server 1)
  • the mqtt server (first server 1)
  • a server 1) converts the message into a rocketMQ message using a preset conversion rule and sends it to the rocketMQ server, and then the rest of the mqtt server can receive the message through the rocketMQ consumer and deprocess it into an mqtt message, thereby performing corresponding processing.
  • the client sends an mqtt message to the server, and all the contents of the message include:
  • Payload the real message content
  • Topic The topic to which the message belongs, which will be used by matching consumers later
  • the message content of rocketMQ includes:
  • receiving module 110 is also used for:
  • search for the client corresponding to the second type field in the subject for example, the Id of the target client
  • ignore if the second type field does not exist For this message sending request, if there is a second type field, continue to perform the message broadcasting operation, and broadcast the message sending request to other servers in the server cluster based on the mqtt protocol.
  • the above-mentioned preset client list includes: the Id of the client that has connected to any server in the server cluster within a preset time (for example, the past 5 years/all historical time, which can be adjusted according to requirements).
  • the Id of the target client does not exist in the client list, it means that the target client has not connected to the server cluster within the preset time (that is, it will not subscribe to the topic), so in order to save the computing resources of the server, the information is directly filtered out Send the request, that is, it will not be processed in any way.
  • the parsing module 120 is configured to analyze the to-be-sent request carried in the received message sending request, and determine the topic corresponding to the attribute information of the to-be-sent message according to the preset mapping relationship between the message attribute information and the topic.
  • the first judgment module 130 is configured to judge whether the message to be sent is a P2P message. Determine whether the message to be sent is a P2P message by judging whether there is a first preset type field in the subject. Specifically, the method for determining whether the message to be sent is a P2P message is:
  • the message to be sent is not a P2P message.
  • the second judgment module 140 is used to judge whether the client has subscribed to the topic.
  • the first determining module 130 determines whether the subject contains a second preset type field (for example, the Id of the target client); if it contains a second type field , It is determined that the client is subscribed to the topic, and the message to be sent is sent to the client; if the second type field is not included, it is determined that the client is not subscribed to the topic, that is, the message is not sent, and a prompt is generated The information is fed back to the corresponding client that generates the message sending request.
  • a second preset type field for example, the Id of the target client
  • the sending module 150 is used to send the message to be sent to the client subscribed to the topic. Specifically, when the second judgment module 140 determines that the client has subscribed to the topic, it sends the message to be sent corresponding to the topic to the client corresponding to the second preset type field.
  • sending module 150 also executes:
  • the message to be sent is saved to the offline message queue of the server corresponding to the client (for example, during the saving process, the message is sent with the message sent according to the request time In the order of priority).
  • a first-in-first-out method is adopted, and messages are in from the end and out from the head, without manual sorting.
  • the server will notify other servers to delete the client's connection information locally and process offline message logic.
  • sending module 150 also executes:
  • connection request of the client is detected, and when the client is detected to be online, the message to be sent in the offline message queue is sent to the client.
  • this application also provides a message distribution method based on mqtt.
  • FIG. 3 it is a schematic diagram of a method flow of an embodiment of an mqtt-based message distribution method of this application.
  • the processor 12 of the server 1 executes the message distribution program 10 stored in the memory 11, the following steps of the mqtt-based message distribution method are implemented:
  • Step S110 using the receiving module 110 to receive a message sending request broadcast by the server cluster based on the mqtt protocol.
  • the server cluster includes multiple servers, such as the first server 1 or the second server 2 shown in FIG. 1. Each server is communicatively connected to multiple clients (only one is shown in the figure), for example, the first server 1 is connected to the first client 14 and the second server 2 is connected to the second client 15.
  • the information transfer between the servers in the server cluster is based on the mqtt protocol.
  • the first client 14 sends a message to the second client 15
  • the user needs to send a message sending request carrying the message to any server (such as the first server 1) in the server cluster through the first client 14.
  • the message sending request carries the message and the attribute information of the message (such as the topic corresponding to the message and the message sending request time, etc.).
  • the first server 1 receives a message sending request allocated by the load device based on a preset load balancing rule.
  • the preset load balancing rules include:
  • Distribute according to the real-time load of each server in the server cluster for example, allocate it to the server with the least real-time load for processing;
  • the allocation is performed in a polling manner.
  • the ranking of the servers in the server cluster is predetermined, and the message sending request is allocated to the servers in turn.
  • the first server 1 may also directly receive the message sending request sent by the first client 14.
  • rocketMQ messages middleware, used for data exchange between systems, with high throughput, high availability, and suitable for large-scale distributed system applications
  • redis database
  • step S110 further includes:
  • the message to be sent of the first preset type (for example, mqtt) is read by the first server 1, and the message to be sent of the first preset type is converted to the second preset type (for example, rocketMQ) based on the preset conversion rule.
  • the purpose of this step is to intercommunicate the first type of message (for example, mqtt message) and the second type of message (for example, rocketMQ message), because different types of messages, such as the protocol between mqtt messages and rocketMQ messages Different, so it is necessary to design a solution for mutual analysis of different types of messages;
  • the message of the second preset type is sent to rocketMQ, for the rocketMQ to broadcast the message of the second preset type to each server in the server cluster.
  • a topic that handles the mqtt protocol needs to be created in rocketMQ, and the message of the topic is an mqtt message.
  • All mqtt servers (all servers in the server cluster) internally start a rocketMQ producer and a rocketMQ consumer.
  • the first client 14 sends a message to the mqtt server (first server 1)
  • the mqtt server (first server 1)
  • a server 1) converts the message into a rocketMQ message using a preset conversion rule and sends it to the rocketMQ server, and then the rest of the mqtt server can receive the message through the rocketMQ consumer and deprocess it into an mqtt message, thereby performing corresponding processing.
  • the client sends an mqtt message to the server, and all the contents of the message include:
  • Payload the real message content
  • Topic The topic to which the message belongs, which will be used by matching consumers later
  • the message content of rocketMQ includes:
  • step S110 further includes:
  • search for the client corresponding to the second type field in the subject for example, the Id of the target client
  • ignore if the second type field does not exist For this message sending request, if there is a second type field, continue to perform the message broadcasting operation, and broadcast the message sending request to other servers in the server cluster based on the mqtt protocol.
  • the above-mentioned preset client list includes: the Id of the client that has connected to any server in the server cluster within a preset time (for example, the past 5 years/all historical time, which can be adjusted according to requirements).
  • the Id of the target client does not exist in the client list, it means that the target client has not connected to the server cluster within the preset time (that is, it will not subscribe to the topic), so in order to save the computing resources of the server, the information is directly filtered out Send the request, that is, it will not be processed in any way.
  • Step S120 is used to analyze the to-be-sent request carried in the received message sending request, and determine the topic corresponding to the attribute information of the to-be-sent message according to the preset mapping relationship between the message attribute information and the topic.
  • Step S130 is used to determine whether the message to be sent is a P2P message. Determine whether the message to be sent is a P2P message by judging whether there is a first preset type field in the subject. Specifically, the method for determining whether the message to be sent is a P2P message is:
  • the message to be sent is not a P2P message.
  • Step S140 is used to determine whether the client has subscribed to the topic.
  • the first determining module 130 determines whether the message to be sent is a P2P message, it determines whether the subject contains a second preset type field (for example, the Id of the target client); if it contains a second type field , It is determined that the client is subscribed to the topic, and the message to be sent is sent to the client; if the second type field is not included, it is determined that the client is not subscribed to the topic, that is, the message is not sent, and a prompt message is generated Feedback to the corresponding client that generated the message sending request.
  • a second preset type field for example, the Id of the target client
  • Step S150 is used to send the message to be sent to the client subscribed to the topic. Specifically, when the second judgment module 140 determines that the client has subscribed to the topic, it sends the message to be sent corresponding to the topic to the client corresponding to the second preset type field.
  • step S150 further includes:
  • the client corresponding to the second preset type field is not online, save the message to be sent to the offline message queue of the server (for example, during the saving process, messages with sent are sorted according to the order of the message sending request time) .
  • a first-in first-out method is adopted, and the message is entered from the end, and the message is entered from the head, without manual sorting.
  • the server will notify other servers to delete the client's connection information locally and process offline message logic.
  • step S150 further includes:
  • connection request of the client is detected, and when the client is detected to be online, the message to be sent in the offline message queue is sent to the client.
  • the embodiment of the present application also proposes a computer-readable storage medium.
  • the computer-readable storage medium may be a hard disk, a multimedia card, an SD card, a flash memory card, an SMC, a read-only memory (ROM), an erasable programmable read-only Any one or any combination of memory (EPROM), portable compact disk read-only memory (CD-ROM), USB memory, etc.
  • the computer-readable storage medium includes the message distribution program 10, and the specific implementation of the computer-readable storage medium of this application is substantially the same as the specific implementation of the above-mentioned message distribution method and server, and will not be repeated here.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请公开了一种基于mqtt的消息分发方法、服务器、虚拟装置及存储介质，该方法接收服务器集群基于mqtt协议广播的消息发送请求，解析消息发送请求中携带的待发送消息获取对应的主题，并判断是否存在第一类型字段。若存在则判断待发送消息为P2P消息，再判断主题是否存在第二类型字段，若存在则确定对应的客户端已订阅主题，将待发送消息发送至该对应的客户端。本申请中服务器集群中基于mqtt协议广播消息发送请求，不用分别将消息发送请求存储在各服务器中，能降低运行该消息分发程序的算法的空间复杂度，并能够识别第二类型字段匹配对应的客户端，可以降低运行查找对应客户端的算法的时间复杂度，提高消息分发效率。

Description

一种基于mqtt的消息分发方法、服务器、装置及存储介质
本申请基于巴黎公约申明享有2019年04月17日递交的申请号为CN 201910307498.9、名称为“一种基于mqtt的消息分发方法、服务器及存储介质”的中国专利申请的优先权，该中国专利申请的整体内容以参考的方式结合在本申请中。
技术领域
本申请涉及数据传输技术领域，尤其涉及一种基于mqtt的消息分发方法、服务器、虚拟装置及存储介质。
背景技术
消息队列遥测传输(Message Queuing Telemetry Transport，MQTT)是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和制动器(比如通过Twitter让房屋联网)的通信协议。
mqtt协议里，所有的消息都是广播消息，对于广播消息来说：所有消费者订阅一个Topic，比如TopicA，生产者将消息发送给TopicA，消费者就都能接收到这些消息，而对于P2P而言，普通的方式只能是每个消费者都订阅自己的Topic，比如消费者A订阅TopicA，消费者B订阅TopicB。
但是，通过现有的消息分发方式会导致服务端必须存储大量的Topic，而每次去寻找需要发送的Topic都需要去遍历匹配，如果有n个Topic，就需要匹配n次，服务器运行该消息分发程序采用的算法复杂，该算法的空间复杂度(算法在运行过程中临时占用存储空间的大小)以及时间复杂度(算法运行耗时长短)高，进而降低了消息分发的效率。
发明内容
本申请的主要目的在于提供一种基于mqtt的消息分发方法、服务器、虚拟装置及存储介质，旨在解决现有的消息分发方式存在消息分发效率低的技术问题。
为实现上述目的，本申请提供的一种基于mqtt的消息分发方法，应用于服务器，该方法包括：
接收步骤：接收所述服务器集群基于mqtt协议广播的消息发送请求；
解析步骤：解析所述消息发送请求中携带的待发送消息，根据预设的消息属性信息与主题之间的映射关系，确定与所述待发送消息的属性信息对应的主题；
第一判断步骤：判断所述主题是否存在第一预设类型字段，以确定所述待发送消息是否为P2P消息；
第二判断步骤：当判断所述待发送消息为P2P消息时，判断所述主题是否存在第二预设类型字段，以判断与所述第二预设类型字段对应的客户端是否订阅所述主题；及
发送步骤：当判断所述主题存在所述第二预设类型字段时，则将与所述主题对应的所述待发送消息发送至与所述第二预设类型字段对应的客户端。
为实现上述目的，本申请还进一步提供一种服务器，所述服务器包括存储器和处理器，所述存储器上存储有消息分发程序，所述消息分发程序被所述处理器执行时可实现如上所述的消息分发方法的步骤。
为实现上述目的，本申请进一步提供一种计算机可读存储介质，所述计算机可读存储介质上存储有消息分发程序，所述消息分发程序可被一个或者多个处理器执行，以实现如上所述的消息分发方法的步骤。
为实现上述目的，本申请进一步提供一种虚拟装置，所述虚拟装置包括：接收模块、解析模块、第一判断模块、第二判断模块及发送模块，各模块协同可实现如上所述的消息分发方法的步骤。
本申请提出的基于mqtt的消息分发方法、服务器、虚拟装置及存储介质，通过接收服务器集群基于mqtt协议广播的消息发送请求，将接受到消息发送请求中携带的待发送消息进行分析，根据分析结果将该消息发送请求分发至相对应的客户端。相比较现有的消息分发方式，本申请中服务器集群中的各服务器之间的信息传递基于mqtt协议实现，不需要将不同的消息发送请求分别存储在服务器集群的各服务器中，从而降低运行该消息分发程序的算法的空间复杂度，并通过识别与P2P消息对应的主题中是否含有第二预设类型字段，自动匹配并将消息发送给与订阅该主题的对应客户端，降低运行查找对 应客户端的算法的时间复杂度，进而提高消息分发效率。
附图说明
图1为本申请服务器较佳实施例的应用环境图；
图2为图1中消息分发程序较佳实施例的程序模块示意图；
图3为本申请消息分发方法较佳实施例的流程示意图。
本申请目的的实现、功能特点及优点将结合实施例，参附图做进一步说明。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
需要说明的是，在本申请中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。
本申请提供一种服务器。参照图1所示，本申请的服务器可为一个服务器集群中任意一台服务器，例如图1的第一服务器1或第二服务器2。每台服务器通信连接多个客户端(图中仅示出1个)，例如第一服务器1连接第一客户端14，第二服务器2连接第二客户端15。服务器集群中的各服务器(例如第一服务器1与第二服务器2)之间的信息传递基于mqtt协议实现。某太服务器接收到一个客户端发送的消息发送请求后，基于mqtt协议将该消息发送请求广播至其他服务器，例如第一服务器1在接收到第一客户端14发送的消息发送请求后，基于mqtt协议在服务器集群中广播该消息发送请求。第二服务器2接收到该消息发送请求发送后，执行消息发送发送分发程序10对该消 息发送请求携带的消息进行分析，根据分析结果将该消息发送请求分发至相对应的客户端，例如第二客户端15。相比较现有的消息分发方式，本申请不需要分别将消息发送请求存储在服务器集群中的其他各服务器，从而减少空间复杂度，提高消息分发效率，且能够通过识别与P2P消息对应的主题中是否含有第二预设类型字段，自动匹配并将消息发送给与订阅该主题对应的客户端，减少对客户端的查找时间复杂度。
所述服务器，例如图1中第一服务器1或第二服务器2，可以是机架式服务器、刀片式服务器、塔式服务器或机柜式服务器等的一种或几种。该第一服务器1包括，但不仅限于，存储器11、处理器12及网络接口13。
其中，存储器11至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、磁性存储器、磁盘、光盘等。存储器11在一些实施例中可以是服务器的内部存储单元，例如该服务器的硬盘。存储器11在另一些实施例中也可以是服务器的外部存储设备，例如该服务器上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。
进一步地，存储器11还可以既包括服务器的内部存储单元也包括外部存储设备。存储器11不仅可以用于存储安装于服务器的应用软件及各类数据，例如消息分发程序10的代码等，还可以用于暂时地存储已经输出或者将要输出的数据。
处理器12在一些实施例中可以是一中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器或其他数据处理芯片，用于运行存储器11中存储的程序代码或处理数据，例如执行消息分发程序10等。
网络接口13可选的可以包括标准的有线接口、无线接口(如WI-FI接口)，通常用于在该服务器与其他电子设备之间建立通信连接。
第一客户端14可以是桌上型计算机、笔记本、平板电脑、手机，或其他具有发送mqtt消息功能且可以通过网络16与服务器进行通信的终端装置。第二客户端15可以是桌上型计算机、笔记本、平板电脑、手机，或具有接收mqtt消息功能且可以通过网络16与服务器进行通信的终端装置。
网络16可以为互联网、云网络、无线保真(Wi-Fi)网络、个人网(PAN)、 局域网(LAN)和/或城域网(MAN)。网络环境中的各种设备可以被配置为根据各种有线和无线通信协议连接到通信网络。这样的有线和无线通信协议的例子可以包括但不限于以下中的至少一个：传输控制协议和互联网协议(TCP/IP)、用户数据报协议(UDP)、超文本传输协议(HTTP)、文件传输协议(FTP)、ZigBee、EDGE、IEEE 802.11、光保真(Li-Fi)、802.16、IEEE 802.11s、IEEE 802.11g、多跳通信、无线接入点(AP)、设备对设备通信、蜂窝通信协议和/或蓝牙(BlueTooth)通信协议或其组合。
可选地，该服务器还可以包括用户接口，用户接口可以包括显示器(Display)、输入单元比如键盘(Keyboard)，可选的用户接口还可以包括标准的有线接口、无线接口。可选地，在一些实施例中，显示器可以是LED显示器、液晶显示器、触控式液晶显示器以及OLED(Organic Light-Emitting Diode，有机发光二极管)触摸器等。其中，显示器也可以称为显示屏或显示单元，用于显示在服务器中处理的信息以及用于显示可视化的用户界面。
图1仅示出了具有组件11-16以及消息分发程序10的第一服务器1及第二服务器2，本领域技术人员可以理解的是，图1示出的结构并不构成对第一服务器1及第二服务器2的限定，可以包括比图示更少或者更多的部件，或者组合某些部件，或者不同的部件布置。
在一实施例中，图1的消息分发程序10被处理器12执行时，实现以下步骤：
接收步骤：接收所述服务器集群基于mqtt协议广播的消息发送请求；
解析步骤：解析所述消息发送请求中携带的待发送消息，根据预设的消息属性信息与主题之间的映射关系，确定与所述待发送消息的属性信息对应的主题；
第一判断步骤：判断所述主题是否存在第一预设类型字段，以确定所述待发送消息是否为P2P消息；
第二判断步骤：当判断所述待发送消息为P2P消息时，判断所述主题是否存在第二预设类型字段，以判断与所述第二预设类型字段对应的客户端是否订阅所述主题；及
发送步骤：当判断所述主题存在所述第二预设类型字段时，则将与所述 主题对应的所述待发送消息发送至与所述第二预设类型字段对应的客户端。
进一步地，在本实施例中，所述消息发送请求是由负载均衡设备基于预设的负载均衡规则分配的。在其他实施例中，所述消息发送请求还可以直接由客户端发送给对应的服务器。
在另一实施例中，所述发送步骤还可以包括：
判断与所述第二预设类型字段对应的客户端是否在线；
若与所述第二预设类型字段对应的客户端在线，则将所述待发送消息发送至所述客户端；及
若与所述第二预设类型字段对应的客户端不在线，则将所述待发送消息保存至所述服务器的离线消息队列。
进一步地，所述发送步骤还可以包括：
侦测所述客户端的连接请求，当侦测到所述客户端在线时，将所述离线消息队列中的所述待发送消息发送至所述客户端。
关于上述步骤的详细介绍，请参照下述图2关于消息分发程序10实施例的程序模块示意图及图3关于消息分发方法实施例的方法流程示意图的说明。
参照图2所示，为图1中消息分发程序10实施例的程序模块示意图。消息分发程序10被分割为多个模块，该多个模块存储于存储器11中，并由处理器12执行，以完成本申请。本申请所称的模块是指能够完成特定功能的一系列计算机程序指令段。
在本实施例中，所述消息分发程序10包括接收模块110、解析模块120、第一判断模块130、第二判断模块140及确定模块150。
接收模块110，用于接收服务器集群基于mqtt协议广播的消息发送请求。
服务器集群中包括多个服务器，例如图1中示出的第一服务器1或第二服务器2。每台服务器通信连接多个客户端(图中仅示出1个)，例如第一服务器1连接第一客户端14，第二服务器2连接第二客户端15。服务器集群中的各服务器(例如第一服务器1与第二服务器2)之间的信息传递基于mqtt协议。第一客户端14向第二客户端15发送消息的过程中，用户需要通过第一客户端14将携带消息的消息发送请求发送至服务器集群中任一台服务器 (如第一服务器1)上。以基于mqtt协议的点对点聊天为例，消息发送请求中携带有消息及消息的属性信息(如消息对应的主题topic及消息发送请求时间等)。
在本实施例中，所述第一服务器1接收负载设备基于预设的负载均衡规则分配的消息发送请求。所述预设的负载均衡规则包括：
根据服务器集群中各服务器的实时负载进行分配，例如，分配给实时负载最小的服务器进行处理；或
根据服务器集群中各服务器的排序，按照轮询的方式进行分配，例如，预先确定服务器集群中各服务器的排序，依次将消息发送请求分配给各服务器。
在其他实施例中，所述第一服务器1还可以直接接收第一客户端14发送的消息发送请求。
在本实施例中，采用rocketMQ(消息中间件，用于进行系统间的数据交换，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点)作为主要的内部消息分发，redis(数据库)作为备份分发，如果rocketMQ失效，则用redis进行分发。
所述接收模块110还用于：
通过所述第一服务器1读取第一预设类型(例如mqtt)的待发送消息，基于预设转换规则将所述第一预设类型的待发送消息转换为第二预设类型(例如rocketMQ)的待发送消息，本步骤的目的在于将第一类型的消息(例如mqtt消息)与第二类型的消息(例如rocketMQ消息)进行互通，因为你同类型的消息，例如mqtt消息与rocketMQ消息的协议不同，因此需要设计一种不同类型消息互相解析的方案；
将所述第二预设类型的消息发送至rocketMQ，供rocketMQ将所述第二预设类型的消息广播至服务器集群中的每一台服务器上。
该方式是需要在rocketMQ中创建一个处理mqtt协议的Topic，该Topic的消息为mqtt消息。所有mqtt服务端(服务器集群中的所有服务器)在内部启动一个rocketMQ生产者和一个rocketMQ消费者，在第一客户端14发送消息到mqtt服务端(第一服务器1)时，mqtt服务端(第一服务器1)将消息利用预设转换规则转化为rocketMQ消息发送到rocketMQ服务端，然后其余 mqtt服务端通过rocketMQ消费者可以接收到该消息并反处理为mqtt消息，从而进行相应的处理。
其中，mqtt消息与rocketMQ消息互通方式：
Figure PCTCN2019117334-appb-000001
比如客户端给服务端发送了一条mqtt消息，该消息的所有内容包括：
Payload：真正的消息内容
Qos:mqtt消息服务等级
Topic：消息所属主题，后面分发匹配消费者需要用到
Retain：mqtt消息属性
这里在发送给rocketMQ时，需要将mqtt消息的整个关键内容转换为 rocketMQ消息。
此时需要额外定义一个Map:
rocketMQ的消息内容包括：
Body：真正的消息内容
Map:{
  Qos:mqtt消息qos等级
  Topic:mqtt消息topic
  Retain：mqtt消息属性
}
Topic:rocketMQ消息主题
进一步地，所述接收模块110还用于：
当接收到所述消息发送请求时，从预设的客户端的列表中查找与所述主题中第二类型字段(例如目标客户端的Id)对应的客户端，若不存在第二类型字段，则忽略该条消息发送请求，若存在第二类型字段，则继续执行消息广播操作，将所述消息发送请求基于mqtt协议广播至所述服务器集群中的其他各服务器。
其中，上述预设的客户端列表中包括：在预设时间内(例如，过去5年/所有历史时间，具体可根据需求做调整)与服务器集群中任意一台服务器连接过的客户端的Id。
若客户端列表中不存在目标客户端的Id，说明目标客户端在预设时间内未连接过该服务器集群(即不会订阅该主题)，因此为了节省服务器的计算资源，直接过滤掉该条信息发送请求，即不对其进行任何处理。
解析模块120，用于解析接收到的消息发送请求中携带的待发送请求，根据预设的消息属性信息与主题之间的映射关系，确定与所述待发送消息的属性信息对应的主题。
第一判断模块130，用于判断所述待发送消息是否为P2P消息。通过判断该主题中是否存在第一预设类型字段，确定所述待发送消息是否为P2P消息。具体地，确定所述待发送消息是否为P2P消息的方式为：
判断所述主题中是否含有第一预设类型字段(例如Topic/P2P)；
若含有第一类型字段，则判断该待发送消息为P2P消息；及
若不含有第一类型字段，则判断该待发送消息不是P2P消息。
第二判断模块140，用于判断客户端是否订阅了该主题。
具体地，当所述第一判断模块130确定所述待发送消息为P2P消息时，判断所述主题中是否包含有第二预设类型字段(例如目标客户端的Id)；若含有第二类型字段，则判断该客户端订阅了该主题，将所述待发送消息发送至该该客户端；若不含有第二类型字段，则判断该客户端没有订阅该主题，即不发送消息，同时生成提示信息反馈给对应的生成消息发送请求的客户端。
发送模块150，用于将待发送消息发送至订阅了该主题的客户端。具体地，当所述第二判断模块140确定客户端订阅了该主题时，将与该主题对应的待发送消息发送至与第二预设类型字段对应的客户端。
进一步地，所述发送模块150还执行：
判断与所述第二预设类型字段对应的客户端是否在线；
若与所述第二预设类型字段对应的客户端在线，则将待发送消息发送至该客户端；及
若与所述第二预设类型字段对应的客户端不在线，则将待发送消息保存至与该客户端对应的服务器的离线消息队列(例如，保存过程中，带发送消息按照消息发出请求时间的先后顺序进行排序)。
具体地，通过将待发送消息保存至服务器的离线消息队列，采用先进先出，消息从尾进，从头部出的方式，不需要进行手动排序。当客户端重新连接到服务器上时，该服务器会通知其他服务器在本地删除该客户端的连接信息，同时处理离线消息逻辑。
进一步地，所述发送模块150还执行：
侦测所述客户端的连接请求，当侦测到客户端在线时，将离线消息队列中的待发送消息发送至该客户端。
此外，本申请还提供一种基于mqtt的消息分发方法。参照图3所示，为本申请基于mqtt的消息分发方法的实施例的方法流程示意图。服务器1的处理器12执行存储器11中存储的消息分发程序10时实现基于mqtt的消息分发方法的如下步骤：
步骤S110，利用所述接收模块110接收服务器集群基于mqtt协议广播的 消息发送请求。
服务器集群中包括多个服务器，例如图1示出的第一服务器1或第二服务器2。每台服务器通信连接多个客户端(图中仅示出1个)，例如第一服务器1连接第一客户端14，第二服务器2连接第二客户端15。服务器集群中的各服务器(例如第一服务器1与第二服务器2)之间的信息传递基于mqtt协议。第一客户端14向第二客户端15发送消息的过程中，用户需要通过第一客户端14将携带消息的消息发送请求发送至服务器集群中任一台服务器(如第一服务器1)上。以基于mqtt协议的点对点聊天为例，消息发送请求中携带有消息及消息的属性信息(如消息对应的主题topic及消息发送请求时间等)。
在本实施例中，所述第一服务器1接收负载设备基于预设的负载均衡规则分配的消息发送请求。所述预设的负载均衡规则包括：
根据服务器集群中各服务器的实时负载进行分配，例如，分配给实时负载最小的服务器进行处理；或
根据服务器集群中各服务器的排序，按照轮询的方式进行分配，例如，预先确定服务器集群中各服务器的排序，依次将消息发送请求分配给各服务器。
在其他实施例中，所述第一服务器1还可以直接接收第一客户端14发送的消息发送请求。
在本实施例中，采用rocketMQ(消息中间件，用于进行系统间的数据交换，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点)作为主要的内部消息分发，redis(数据库)作为备份分发，如果rocketMQ失效，则用redis进行分发。具体地，所述步骤S110还包括：
通过所述第一服务器1读取第一预设类型(例如mqtt)的待发送消息，基于预设转换规则将所述第一预设类型的待发送消息转换为第二预设类型(例如rocketMQ)的待发送消息，本步骤的目的在于将第一类型的消息(例如mqtt消息)与第二类型的消息(例如rocketMQ消息)进行互通，因为不同类型的消息，例如mqtt消息与rocketMQ消息的协议不同，因此需要设计一种不同类型消息互相解析的方案；
将所述第二预设类型的消息发送至rocketMQ，供rocketMQ将所述第二预设类型的消息广播至服务器集群中的每一台服务器上。
该方式是需要在rocketMQ中创建一个处理mqtt协议的Topic，该Topic的消息为mqtt消息。所有mqtt服务端(服务器集群中的所有服务器)在内部启动一个rocketMQ生产者和一个rocketMQ消费者，在第一客户端14发送消息到mqtt服务端(第一服务器1)时，mqtt服务端(第一服务器1)将消息利用预设转换规则转化为rocketMQ消息发送到rocketMQ服务端，然后其余mqtt服务端通过rocketMQ消费者可以接收到该消息并反处理为mqtt消息，从而进行相应的处理。
其中，mqtt消息与rocketMQ消息互通方式：
Figure PCTCN2019117334-appb-000002
比如客户端给服务端发送了一条mqtt消息，该消息的所有内容包括：
Payload：真正的消息内容
Qos:mqtt消息服务等级
Topic：消息所属主题，后面分发匹配消费者需要用到
Retain：mqtt消息属性
这里在发送给rocketMQ时，需要将mqtt消息的整个关键内容转换为rocketMQ消息。
此时需要额外定义一个Map:
rocketMQ的消息内容包括：
Body：真正的消息内容
Map:{
  Qos:mqtt消息qos等级
  Topic:mqtt消息topic
  Retain：mqtt消息属性
}
Topic:rocketMQ消息主题
进一步地，所述步骤S110还包括：
当接收到所述消息发送请求时，从预设的客户端的列表中查找与所述主题中第二类型字段(例如目标客户端的Id)对应的客户端，若不存在第二类型字段，则忽略该条消息发送请求，若存在第二类型字段，则继续执行消息广播操作，将所述消息发送请求基于mqtt协议广播至所述服务器集群中的其他各服务器。
其中，上述预设的客户端列表中包括：在预设时间内(例如，过去5年/所有历史时间，具体可根据需求做调整)与服务器集群中任意一台服务器连接过的客户端的Id。
若客户端列表中不存在目标客户端的Id，说明目标客户端在预设时间内未连接过该服务器集群(即不会订阅该主题)，因此为了节省服务器的计算资源，直接过滤掉该条信息发送请求，即不对其进行任何处理。
步骤S120，用于解析接收到的消息发送请求中携带的待发送请求，根据预设的消息属性信息与主题之间的映射关系，确定与所述待发送消息的属性信息对应的主题。
步骤S130，用于判断所述待发送消息是否为P2P消息。通过判断该主题中是否存在第一预设类型字段，以确定所述待发送消息是否为P2P消息。具体地，确定所述待发送消息是否为P2P消息的方式为：
判断所述主题中是否含有第一预设类型字段(例如Topic/P2P)；
若含有第一类型字段，则判断该待发送消息为P2P消息；及
若不含有第一类型字段，则判断该待发送消息不是P2P消息。
步骤S140，用于判断客户端是否订阅了该主题。
具体地，当所述第一判断模块130确定所述待发送消息为P2P消息时，判断所述主题中是否包含有第二预设类型字段(例如目标客户端的Id)；若含有第二类型字段，则判断该客户端订阅了该主题，将所述待发送消息发送至该客户端；若不含有第二类型字段，则判断该客户端没有订阅该主题，即不发送消息，同时生成提示信息反馈给对应的生成消息发送请求的客户端。
步骤S150，用于将待发送消息发送至订阅了该主题的客户端。具体地，当所述第二判断模块140确定客户端订阅了该主题时，将与该主题对应的待发送消息发送至与第二预设类型字段对应的客户端。
进一步地，所述步骤S150还包括：
判断与所述第二预设类型字段对应的客户端是否在线；
若与所述第二预设类型字段对应的客户端在线，则将待发送消息发送至该客户端；及
若与所述第二预设类型字段对应的客户端不在线，则将待发送消息保存至服务器的离线消息队列(例如，保存过程中，带发送消息按照消息发出请求时间的先后顺序进行排序)。
具体地，通过将待发送消息保存至与该客户端对应的服务器的离线消息队列，采用先进先出，消息从尾进，从头部出的方式，不需要进行手动排序。当客户端重新连接到服务器上时，该服务器会通知其他服务器在本地删除该客户端的连接信息，同时处理离线消息逻辑。
进一步地，所述步骤S150还包括：
侦测所述客户端的连接请求，当侦测到客户端在线时，将离线消息队列中的待发送消息发送至该客户端。
此外，本申请实施例还提出一种计算机可读存储介质，计算机可读存储介质可以是硬盘、多媒体卡、SD卡、闪存卡、SMC、只读存储器(ROM)、可擦除可编程只读存储器(EPROM)、便携式紧致盘只读存储器(CD-ROM)、USB存储器等中的任意一种或者几种的任意组合。计算机可读存储介质中包括消息分发程序10，本申请之计算机可读存储介质的具体实施方式与上述消息分发方法以及服务器的具体实施方式大致相同，在此不再赘述。
需要说明的是，上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。并且本文中的术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、装置、物品或者方法不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、装置、物品或者方法所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、装置、物品或者方法中还存在另外的相同要素。
上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。
以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (20)

  1. 一种基于mqtt协议的消息分发方法，应用于服务器集群的一服务器，其特征在于，该方法包括：
    接收步骤：接收所述服务器集群基于mqtt协议广播的消息发送请求；
    解析步骤：解析所述消息发送请求中携带的待发送消息，根据预设的消息属性信息与主题之间的映射关系，确定与所述待发送消息的属性信息对应的主题；
    第一判断步骤：判断所述主题是否存在第一预设类型字段，以确定所述待发送消息是否为P2P消息；
    第二判断步骤：当判断所述待发送消息为P2P消息时，判断所述主题是否存在第二预设类型字段，以判断与所述第二预设类型字段对应的客户端是否订阅所述主题；及
    发送步骤：当判断所述主题存在所述第二预设类型字段时，则将与所述主题对应的所述待发送消息发送至与所述第二预设类型字段对应的客户端。
  2. 如权利要求1所述的基于mqtt的消息分发方法，其特征在于，所述消息发送请求是由负载均衡设备基于预设的负载均衡规则分配的。
  3. 如权利要求2所述的基于mqtt的消息分发方法，其特征在于，所述负载均衡规则为：
    根据所述服务器集群中的各服务器的实时负载情况将所述消息发送请求优先分配给负载最小的服务器；或
    根据所述服务器集群中的各服务器的排序，按照轮询的方式分配所述消息发送请求。
  4. 如权利要求1所述的基于mqtt的消息分发方法，其特征在于，所述发送步骤还包括：
    判断与所述第二预设类型字段对应的客户端是否在线；
    若与所述第二预设类型字段对应的客户端在线，则将所述待发送消息发送至所述客户端；及
    若与所述第二预设类型字段对应的客户端不在线，则将所述待发送消息保存至与该客户端对应的服务器的离线消息队列。
  5. 如权利要求4所述的基于mqtt的消息分发方法，其特征在于，所述发送步骤还包括：
    侦测所述客户端的连接请求，当侦测到所述客户端在线时，将所述离线消息队列中的所述待发送消息发送至所述客户端。
  6. 一种服务器，其特征在于，所述服务器包括存储器和处理器，所述存储器上存储有消息分发程序，所述消息分发程序被所述处理器执行时实现如下步骤：
    接收步骤：接收所述服务器集群基于mqtt协议广播的消息发送请求；
    解析步骤：解析所述消息发送请求中携带的待发送消息，根据预设的消息属性信息与主题之间的映射关系，确定与所述待发送消息的属性信息对应的主题；
    第一判断步骤：判断所述主题是否存在第一预设类型字段，以确定所述待发送消息是否为P2P消息；
    第二判断步骤：当判断所述待发送消息为P2P消息时，判断所述主题是否存在第二预设类型字段，以判断与所述第二预设类型字段对应的客户端是否订阅所述主题；及
    发送步骤：当判断所述主题存在所述第二预设类型字段时，则将与所述主题对应的所述待发送消息发送至与所述第二预设类型字段对应的客户端。
  7. 如权利要求6所述的服务器，其特征在于，所述消息发送请求是由负载均衡设备基于预设的负载均衡规则分配的。
  8. 如权利要求7所述的服务器，其特征在于，所述负载均衡规则为：
    根据所述服务器集群中的各服务器的实时负载情况将所述消息发送请求优先分配给负载最小的服务器；或
    根据所述服务器集群中的各服务器的排序，按照轮询的方式分配所述消息发送请求。
  9. 如权利要求6-8中任一项所述的服务器，其特征在于，所述处理器运行所述消息分发程序，还执行：
    判断与所述第二预设类型字段对应的客户端是否在线；
    若与所述第二预设类型字段对应的客户端在线，则将所述待发送消息发送至所述客户端；及
    若与所述第二预设类型字段对应的客户端不在线，则将所述待发送消息保存至与该客户端对应的服务器的离线消息队列。
  10. 如权利要求9所述的服务器，其特征在于，所述处理器运行所述消息分发程序，还执行：
    侦测所述客户端的连接请求，当侦测到所述客户端在线时，将所述离线消息队列中的所述待发送消息发送至所述客户端。
  11. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有消息分发程序，所述消息分发程序可被一个或者多个处理器执行，以实现如下步骤：
    接收步骤：接收所述服务器集群基于mqtt协议广播的消息发送请求；
    解析步骤：解析所述消息发送请求中携带的待发送消息，根据预设的消息属性信息与主题之间的映射关系，确定与所述待发送消息的属性信息对应的主题；
    第一判断步骤：判断所述主题是否存在第一预设类型字段，以确定所述待发送消息是否为P2P消息；
    第二判断步骤：当判断所述待发送消息为P2P消息时，判断所述主题是否存在第二预设类型字段，以判断与所述第二预设类型字段对应的客户端是否订阅所述主题；及
    发送步骤：当判断所述主题存在所述第二预设类型字段时，则将与所述主题对应的所述待发送消息发送至与所述第二预设类型字段对应的客户端。
  12. 如权利要求11所述的计算机可读存储介质，其特征在于，所述消息发送请求是由负载均衡设备基于预设的负载均衡规则分配的。
  13. 如权利要求12所述的计算机可读存储介质，其特征在于，所述负载均衡规则为：
    根据所述服务器集群中的各服务器的实时负载情况将所述消息发送请求优先分配给负载最小的服务器；或
    根据所述服务器集群中的各服务器的排序，按照轮询的方式分配所述消息发送请求。
  14. 如权利要求11-13中任一项所述的计算机可读存储介质，其特征在于，所述处理器运行所述消息分发程序，还执行：
    判断与所述第二预设类型字段对应的客户端是否在线；
    若与所述第二预设类型字段对应的客户端在线，则将所述待发送消息发送至所述客户端；及
    若与所述第二预设类型字段对应的客户端不在线，则将所述待发送消息保存至与该客户端对应的服务器的离线消息队列。
  15. 如权利要求14所述的计算机可读存储介质，其特征在于，所述处理器运行所述消息分发程序，还执行：
    侦测所述客户端的连接请求，当侦测到所述客户端在线时，将所述离线消息队列中的所述待发送消息发送至所述客户端。
  16. 一种虚拟装置，其特征在于，所述虚拟装置包括：
    接收模块，用于接收服务器集群基于mqtt协议广播的消息发送请求；
    解析模块，用于解析接收到的消息发送请求中携带的待发送请求，根据预设的消息属性信息与主题之间的映射关系，确定与所述待发送消息的属性信息对应的主题；
    第一判断模块，用于判断所述待发送消息是否为P2P消息；
    第二判断模块，用于判断客户端是否订阅所述主题；及
    发送模块，用于将待发送消息发送至订阅了该主题的客户端。
  17. 如权利要求16所述的虚拟装置，其特征在于，所述消息发送请求是由负载均衡设备基于预设的负载均衡规则分配的。
  18. 如权利要求17所述的虚拟装置，其特征在于，所述负载均衡规则为：
    根据所述服务器集群中的各服务器的实时负载情况将所述消息发送请求优先分配给负载最小的服务器；或
    根据所述服务器集群中的各服务器的排序，按照轮询的方式分配所述消息发送请求。
  19. 如权利要求16-18中任一项所述的虚拟装置，其特征在于，所述发送模块还用于：
    判断与所述第二预设类型字段对应的客户端是否在线；
    若与所述第二预设类型字段对应的客户端在线，则将所述待发送消息发送至所述客户端；及
    若与所述第二预设类型字段对应的客户端不在线，则将所述待发送消息 保存至与该客户端对应的服务器的离线消息队列。
  20. 如权利要求19所述的虚拟装置，其特征在于，所述发送模块还用于：
    侦测所述客户端的连接请求，当侦测到所述客户端在线时，将所述离线消息队列中的所述待发送消息发送至所述客户端。
PCT/CN2019/117334 2019-04-17 2019-11-12 一种基于mqtt的消息分发方法、服务器、装置及存储介质 WO2020211344A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910307498.9 2019-04-17
CN201910307498.9A CN110086636B (zh) 2019-04-17 2019-04-17 一种基于mqtt的消息分发方法、服务器及存储介质

Publications (1)

Publication Number Publication Date
WO2020211344A1 true WO2020211344A1 (zh) 2020-10-22

Family

ID=67415385

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/117334 WO2020211344A1 (zh) 2019-04-17 2019-11-12 一种基于mqtt的消息分发方法、服务器、装置及存储介质

Country Status (2)

Country Link
CN (1) CN110086636B (zh)
WO (1) WO2020211344A1 (zh)

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112291325A (zh) * 2020-10-23 2021-01-29 上海豹云网络信息服务有限公司 一种消息的处理方法、装置及计算机系统
CN112463799A (zh) * 2020-12-11 2021-03-09 天冕信息技术(深圳)有限公司 数据提取方法、装置、设备及存储介质
CN112583933A (zh) * 2020-12-25 2021-03-30 高新现代智能系统股份有限公司 参数运行方法、装置、设备及存储介质
CN113190778A (zh) * 2021-04-30 2021-07-30 深圳壹账通创配科技有限公司 业务数据推送方法、系统、计算机设备及计算机存储介质
CN114025002A (zh) * 2021-11-05 2022-02-08 深圳市宏电技术股份有限公司 一种基于mqtt信息传输的方法、系统及通信设备
CN114172973A (zh) * 2021-11-30 2022-03-11 深圳市国电科技通信有限公司 一种基于mqtt协议和698协议的数据转换处理方法及电子设备
CN114422966A (zh) * 2020-10-28 2022-04-29 中国联合网络通信集团有限公司 信息发送方法及电子设备
CN114501186A (zh) * 2022-01-28 2022-05-13 瀚云科技有限公司 一种数据采集系统、方法、电子设备及存储介质
CN114513513A (zh) * 2022-02-15 2022-05-17 湖南快乐阳光互动娱乐传媒有限公司 基于消息中间件的数据处理方法及装置
CN114598894A (zh) * 2020-12-03 2022-06-07 北京字节跳动网络技术有限公司 交互消息处理方法、装置、设备和介质
CN114615277A (zh) * 2022-03-04 2022-06-10 杭州觅恒科技有限公司 一种基于emq x的多集群动态扩展方法及系统
CN114640707A (zh) * 2022-03-04 2022-06-17 微位（深圳）网络科技有限公司 一种消息异步处理方法、装置、电子设备及存储介质
CN114745364A (zh) * 2022-03-28 2022-07-12 重庆长安汽车股份有限公司 基于mqtt协议的车联网数据分发系统及方法
CN115314551A (zh) * 2022-10-12 2022-11-08 东方合智数据科技(广东)有限责任公司 设备数据推送方法及设备数据推送系统
CN115866286A (zh) * 2023-01-31 2023-03-28 北京微吼时代科技有限公司 直播业务中消息服务的方法与系统
CN116599922A (zh) * 2023-05-09 2023-08-15 广州市玄武无线科技股份有限公司 一种多类型消息的路由方法、系统、装置及介质
CN117354117A (zh) * 2023-10-10 2024-01-05 南京汇银迅信息技术有限公司 一种基于Java和MQ的分布式消息通讯方法及系统

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110086636B (zh) * 2019-04-17 2022-03-25 平安科技（深圳）有限公司 一种基于mqtt的消息分发方法、服务器及存储介质
CN110474917B (zh) * 2019-08-16 2024-07-12 深圳前海微众银行股份有限公司 消息中间件上、下线方法、装置、设备及可读存储介质
CN110716813A (zh) * 2019-09-17 2020-01-21 贝壳技术有限公司 数据流处理方法、装置、可读存储介质及处理器
CN112527475A (zh) * 2019-09-19 2021-03-19 北京国双科技有限公司 前端系统切换方法及装置
CN110661871B (zh) * 2019-09-27 2022-06-17 宁波和利时智能科技有限公司 一种数据传输方法及mqtt服务器
CN112751891B (zh) * 2019-10-30 2022-06-28 中移(苏州)软件技术有限公司 一种基于kafka的消息处理方法、电子设备及存储介质
CN113703954A (zh) * 2020-05-21 2021-11-26 中移(苏州)软件技术有限公司 一种消息备份方法、装置、电子设备及计算机存储介质
CN111737087B (zh) * 2020-06-30 2023-08-04 超越科技股份有限公司 身份信息显示方法及系统
CN111866160B (zh) * 2020-07-28 2023-09-15 网易（杭州）网络有限公司 多机控制方法、装置、设备及存储介质
CN112333115B (zh) * 2020-08-19 2024-02-09 深圳Tcl新技术有限公司 数据传输方法、终端设备、服务器及存储介质
CN112328596A (zh) * 2020-11-05 2021-02-05 平安消费金融有限公司 数据查询方法、装置、电子设备及存储介质
CN112860412B (zh) * 2021-03-12 2023-10-20 网易（杭州）网络有限公司 业务数据处理方法、装置、电子设备及存储介质
CN112948738A (zh) * 2021-03-18 2021-06-11 四川虹美智能科技有限公司 基于mqtt的数据处理方法和装置
CN113132926A (zh) * 2021-04-16 2021-07-16 中国工商银行股份有限公司 一种消息分发方法、系统、设备及介质
CN113206872B (zh) * 2021-04-22 2022-06-03 深圳感臻智能股份有限公司 一种消息发送方法、终端及计算机存储介质
CN113239307A (zh) * 2021-05-17 2021-08-10 北京百度网讯科技有限公司 用于存储消息主题的方法及装置
CN113347028B (zh) * 2021-05-25 2022-08-09 吉递(中国)能源科技有限公司 基于MQTT和RocketMQ开发的物联网平台管理系统
CN115914358B (zh) * 2021-08-06 2024-07-19 青岛海尔科技有限公司 消息推送方法、装置、电子设备及计算机存储介质
CN113645576B (zh) * 2021-08-20 2023-03-24 苏州良医汇网络科技有限公司 一种统一消息方法及系统
CN114125730B (zh) * 2022-01-29 2022-05-10 理工亘舒(广东)科技有限公司 冷箱开关锁的远程控制方法及系统
CN114760259B (zh) * 2022-04-27 2024-01-16 深圳小湃科技有限公司 离线消息发送方法、装置、电子设备及可读存储介质
CN116319650B (zh) * 2023-05-22 2024-01-30 三一海洋重工有限公司 港口设备数据的分发方法、装置、系统及集装箱起重机

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102308548A (zh) * 2009-02-12 2012-01-04 国际商业机器公司 在发布和定制引擎中引入加密、认证和授权
CN107181792A (zh) * 2017-04-21 2017-09-19 珠海派诺科技股份有限公司 基于MQTT和n2n VPN的远端设备管理方法及装置
CN108494815A (zh) * 2018-02-06 2018-09-04 北京极智感科技有限公司 一种传输消息的方法和系统
CN110086636A (zh) * 2019-04-17 2019-08-02 平安科技（深圳）有限公司 一种基于mqtt的消息分发方法、服务器及存储介质

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7406537B2 (en) * 2002-11-26 2008-07-29 Progress Software Corporation Dynamic subscription and message routing on a topic between publishing nodes and subscribing nodes
CN105684376A (zh) * 2013-09-28 2016-06-15 迈克菲公司 数据交换层上的位置服务
US9654571B2 (en) * 2014-01-21 2017-05-16 Time Warner Cable Enterprises Llc Publish-subscribe messaging in a content network
CN104639625B (zh) * 2015-01-27 2018-05-01 华南理工大学 一种基于mqtt的数据集中器采集控制方法、装置及系统
CN104796473A (zh) * 2015-04-21 2015-07-22 努比亚技术有限公司 一种跨平台的信息推送方法及系统
CN105430048B (zh) * 2015-10-29 2020-02-18 努比亚技术有限公司 一种基于多集群的消息投递系统和消息投递方法
CN106953901B (zh) * 2017-03-10 2020-04-07 重庆邮电大学 一种提高消息传递性能的集群通信系统及其方法
CN109639642B (zh) * 2018-11-12 2022-04-12 平安科技（深圳）有限公司 基于mqtt的安全认证方法、装置及存储介质
CN109450908A (zh) * 2018-11-23 2019-03-08 工业互联网创新中心（上海）有限公司 基于分布式消息的通信方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102308548A (zh) * 2009-02-12 2012-01-04 国际商业机器公司 在发布和定制引擎中引入加密、认证和授权
CN107181792A (zh) * 2017-04-21 2017-09-19 珠海派诺科技股份有限公司 基于MQTT和n2n VPN的远端设备管理方法及装置
CN108494815A (zh) * 2018-02-06 2018-09-04 北京极智感科技有限公司 一种传输消息的方法和系统
CN110086636A (zh) * 2019-04-17 2019-08-02 平安科技（深圳）有限公司 一种基于mqtt的消息分发方法、服务器及存储介质

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112291325A (zh) * 2020-10-23 2021-01-29 上海豹云网络信息服务有限公司 一种消息的处理方法、装置及计算机系统
CN114422966B (zh) * 2020-10-28 2023-05-30 中国联合网络通信集团有限公司 信息发送方法及电子设备
CN114422966A (zh) * 2020-10-28 2022-04-29 中国联合网络通信集团有限公司 信息发送方法及电子设备
CN114598894A (zh) * 2020-12-03 2022-06-07 北京字节跳动网络技术有限公司 交互消息处理方法、装置、设备和介质
CN112463799A (zh) * 2020-12-11 2021-03-09 天冕信息技术(深圳)有限公司 数据提取方法、装置、设备及存储介质
CN112583933A (zh) * 2020-12-25 2021-03-30 高新现代智能系统股份有限公司 参数运行方法、装置、设备及存储介质
CN112583933B (zh) * 2020-12-25 2023-02-24 高新现代智能系统股份有限公司 参数运行方法、装置、设备及存储介质
CN113190778A (zh) * 2021-04-30 2021-07-30 深圳壹账通创配科技有限公司 业务数据推送方法、系统、计算机设备及计算机存储介质
CN114025002A (zh) * 2021-11-05 2022-02-08 深圳市宏电技术股份有限公司 一种基于mqtt信息传输的方法、系统及通信设备
CN114172973A (zh) * 2021-11-30 2022-03-11 深圳市国电科技通信有限公司 一种基于mqtt协议和698协议的数据转换处理方法及电子设备
CN114172973B (zh) * 2021-11-30 2023-12-19 深圳市国电科技通信有限公司 一种基于mqtt协议和698协议的数据转换处理方法及电子设备
CN114501186A (zh) * 2022-01-28 2022-05-13 瀚云科技有限公司 一种数据采集系统、方法、电子设备及存储介质
CN114501186B (zh) * 2022-01-28 2023-10-03 瀚云科技有限公司 一种数据采集系统、方法、电子设备及存储介质
CN114513513A (zh) * 2022-02-15 2022-05-17 湖南快乐阳光互动娱乐传媒有限公司 基于消息中间件的数据处理方法及装置
CN114615277A (zh) * 2022-03-04 2022-06-10 杭州觅恒科技有限公司 一种基于emq x的多集群动态扩展方法及系统
CN114640707A (zh) * 2022-03-04 2022-06-17 微位（深圳）网络科技有限公司 一种消息异步处理方法、装置、电子设备及存储介质
CN114615277B (zh) * 2022-03-04 2024-01-16 杭州觅恒科技有限公司 一种基于emq x的多集群动态扩展方法及系统
CN114745364A (zh) * 2022-03-28 2022-07-12 重庆长安汽车股份有限公司 基于mqtt协议的车联网数据分发系统及方法
CN115314551A (zh) * 2022-10-12 2022-11-08 东方合智数据科技(广东)有限责任公司 设备数据推送方法及设备数据推送系统
CN115866286B (zh) * 2023-01-31 2023-05-16 北京微吼时代科技有限公司 直播业务中消息服务的方法与系统
CN115866286A (zh) * 2023-01-31 2023-03-28 北京微吼时代科技有限公司 直播业务中消息服务的方法与系统
CN116599922A (zh) * 2023-05-09 2023-08-15 广州市玄武无线科技股份有限公司 一种多类型消息的路由方法、系统、装置及介质
CN117354117A (zh) * 2023-10-10 2024-01-05 南京汇银迅信息技术有限公司 一种基于Java和MQ的分布式消息通讯方法及系统
CN117354117B (zh) * 2023-10-10 2024-05-31 南京汇银迅信息技术有限公司 一种基于Java和MQ的分布式消息通讯方法及系统

Also Published As

Publication number Publication date
CN110086636A (zh) 2019-08-02
CN110086636B (zh) 2022-03-25

Similar Documents

Publication Publication Date Title
WO2020211344A1 (zh) 一种基于mqtt的消息分发方法、服务器、装置及存储介质
WO2020133967A1 (zh) 共享计算资源的调度方法、共享计算系统、服务器及介质
US10241839B2 (en) Method and system for generating a virtual device resource accessible by an application
US8949258B2 (en) Techniques to manage file conversions
US10169060B1 (en) Optimization of packet processing by delaying a processor from entering an idle state
US8244822B1 (en) Push notification delivery system
US10673969B2 (en) Scalable data feed system
US10200460B2 (en) Server-processor hybrid system for processing data
US11616686B1 (en) Cluster management
WO2020140614A1 (zh) 离线消息分发方法、服务器及存储介质
CN110851248B (zh) 异步任务数据处理方法、装置及计算机可读存储介质
US10997538B1 (en) Resource management
US10284670B1 (en) Network-controlled device management session
WO2019096046A1 (zh) 数据处理系统、方法及令牌管理方法
US20210185740A1 (en) Enabling communications between a controlling device and a network-controlled device via a network-connected device service over a mobile communications network
WO2023103419A1 (zh) 基于消息队列的5g消息批量发送方法、装置及电子设备
CN114268667B (zh) 数据转发方法、装置、计算机设备及存储介质
US20090132582A1 (en) Processor-server hybrid system for processing data
JP2018522314A (ja) ユーザ・モバイルネットワークおよびデータプランに基づくコンテンツのフィルタリング
EP2622499B1 (en) Techniques to support large numbers of subscribers to a real-time event
CN111988403A (zh) 电子设备的请求处理方法、系统、存储介质和电子设备
CN113238808B (zh) 一种消息推送方法和装置
CN111193656A (zh) 一种消息推送方法和装置
CN115086425B (zh) 消息传输方法、装置、程序产品、介质及电子设备
CN116112880B (zh) 基于mq的高并发短信发送方法和装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19924823

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19924823

Country of ref document: EP

Kind code of ref document: A1