CN117135196A - Data transmission method and related equipment - Google Patents

Abstract

The embodiment of the application discloses a data transmission method and related equipment, which are used for realizing automatic connection between a client and a server. The method of the embodiment of the application comprises the following steps: the method comprises the steps that a first server sends a target message, wherein the target message comprises server information of the first server, and the server information is used for indicating an address of the first server; the method comprises the steps that a first service end receives an access request message from a client end, wherein a destination address of the access request message is an address of the first service end, and the access request message is used for requesting to establish connection between the client end and the first service end; and the first service end sends an access response message to the client end according to the access request message.

Description

Data transmission method and related equipment

Technical Field

The embodiment of the application relates to the field of communication, in particular to a data transmission method and related equipment.

Background

The publish/subscribe mode is a low-overhead, low-bandwidth-occupation instant messaging mode. After the client connects to the server, the client can implement information interaction by publishing a message and subscribing to a topic (topic) to the server.

After the client establishes connection with the server, the client can exchange information with the server through a publish/subscribe mode. One common method of establishing a connection is to manually configure the IP address of the server on the client, thereby implementing the connection between the client and the server.

However, the manual configuration is inefficient and costly, and thus an automatic connection is needed instead of manual configuration.

Disclosure of Invention

The embodiment of the application provides a data transmission method and related equipment, which are used for realizing automatic connection between a client and a server.

In a first aspect, an embodiment of the present application provides a data transmission method, including: the method comprises the steps that a first server sends a target message, wherein the target message comprises server information of the first server; the server information is used for indicating the address of the first server. Then, the first service end receives an access request message from the client end, the destination address of the access request message is the address of the first service end, and the access request message is used for requesting to establish connection between the client end and the first service end. Then, the first service end can send an access response message to the client end according to the access request message, so that the connection between the first service end and the client end is realized.

In the embodiment of the application, the server information of the server is sent to the client through the target message of the server, so that the address of the server is indicated to the client. The client can determine the address of the server according to the target message, so that an access request message is sent to the server, and automatic connection with the server is realized. The method does not need to manually configure the address of the server on the client, and simplifies the process of establishing connection between the server and the client, thereby improving the efficiency of establishing connection between the client and the server.

In an alternative implementation, the target message may be sent through the target port. The target port is used for transmitting a target message of a target message type; the target message of the target message type is used for indicating the address of the first server to the client.

Alternatively, the target message type may be a Discovery (DISCOVER) message type of a message queue telemetry transport protocol (message queuing telemetry transport, MQTT) newly defined by an embodiment of the present application. The discovery message is used for indicating the address of the server to the client.

In the embodiment of the application, the target port is a contracted port for transmitting the target message, the server and the client realize the receiving and transmitting of the target message through the contracted port, the message received by the client from the target port can be regarded as the target message, and the mode of determining the message type by the client is simple, convenient and quick.

In an alternative implementation, the target message further includes a target message type identifier. The target message type identifier is used for indicating that the message type of the target message is the target message type.

In the embodiment of the application, the client can determine whether the message type transmitted by the target port is matched with the message type transmitted by the target port through the target message identifier. Therefore, the message of the non-appointed type (non-target message type) transmitted on the target port is prevented from being processed by the client so as to generate errors, and the processing efficiency of the client is improved.

In an alternative implementation, the target message further includes a target message type verification identifier, where the target message type verification identifier is used for verifying the validity of the target message type identifier by the client.

In the embodiment of the application, the validity of the target message type identification is verified through the target message type verification identification, so that whether the target message is wrong or not is determined, if yes, the target message is discarded, the client is prevented from processing wrong messages, and the processing efficiency of the client is improved.

In an alternative implementation manner, the target message may be a control message of the message queue telemetry transport protocol MQTT, and the target message type identifier may be a message type field on a fixed header of the target message, where the value of the message type field is 0.

In the embodiment of the application, a '0' type message reserved in the current MQTT protocol is defined, and a message with a message type field value of 0 is called a Discovery (DISCOVER) message, wherein the discovery message is used for indicating the address of a server to a client. The method realizes the expansion of the current MQTT protocol, and realizes the automatic configuration from the address of the server to the client by finding the message based on the current MQTT protocol, thereby realizing the automatic connection between the client and the server.

In an alternative implementation manner, the target message further includes an operation type identifier, where the operation type identifier is used to instruct the client to send the access request message to the first service end.

In the embodiment of the application, different operation types of the client are indicated through the operation type identifier, so that the client is divided into two main types for management, wherein one type is never connected with the server, and the other type is connected with the server. Therefore, the server side can flexibly manage part of the clients and can flexibly change the address information.

In an alternative implementation manner, the operation type identifier may include an access identifier, where the access identifier is used to instruct a client that is not connected to the service end to send an access request packet to the first service end.

In the embodiment of the application, the access identifier is used for indicating the client which is not accessed to the server to access to the first server, so that the client is connected to the server and managed by the server.

In an alternative implementation manner, the operation type identifier may include an update identifier, where the update identifier is used to instruct a client connected to the second service end to establish a connection with the first service end; or, the method is used for indicating the client terminal which is not connected with the service terminal to establish the connection with the first service terminal.

In the embodiment of the application, the update identifier may indicate that a client that is not connected to the server accesses the publish/subscribe network, or may also indicate that the client updates the connected server.

In an alternative implementation, the target message is a control message of the message queue telemetry transport protocol MQTT, and the operation type is identified on a variable header of the target message.

In an alternative implementation, the first service may broadcast the target message.

In the embodiment of the application, the first service end sends the target message in the network segment where the first service end is located in a broadcast mode, so that the consumption of communication resources can be reduced.

In an alternative implementation, the server information includes an IP address of the first server, and the target packet further includes an IP address type identifier, where the IP address type identifier is used to instruct the client to read an IP address of the first server with a target length from the target packet.

In the embodiment of the application, the target length of the IP address is indicated by the IP address type identifier, and the client needs to determine the length of the read IP address according to the IP address type identifier, so that the accuracy of the read IP address is ensured.

In an alternative implementation manner, the type of the IP address of the first service end is IPv4, and the target length is 4 bytes; or the type of the IP address of the first service end is IPv6, and the target length is 16 bytes.

In a second aspect, an embodiment of the present application provides a data transmission method, including: the client receives the target message from the first service end. The target message comprises server information of the first server, and the server information is used for indicating an address of the first server. The client may then send an access request message to the first server. The destination address of the access request message is the address of the first service end, and the access request message is used for requesting to establish the connection between the client and the first service end. The client may then receive an access response message from the first server.

The advantageous effects of the second aspect are referred to in the first aspect and are not described here in detail.

In an alternative implementation, the client receives the target message from the first service end through the target port. The target port is used for transmitting a target message of a target message type, and the target message of the target message type is used for indicating the address of the first server to the client.

In an alternative implementation, the target message further includes a target message type identifier. The client can determine that the message type of the target message is the target message type according to the target message type identifier in the target message. The client can read the information of the server from the target message according to the message type of the target message as the target message type. The client may then determine the address of the first server based on the server information.

In an alternative implementation, the target message further includes a target message type verification identifier. And the client verifies the validity of the target message type identifier according to the target message type verification identifier in the target message.

In an alternative implementation, the target message is a control message of the message queue telemetry transport protocol MQTT. The target message type identifier is a message type field on a fixed head of the target message, and the value of the message type field is 0.

In an alternative implementation, the target message also includes an operation type identifier. The client may send an access request packet to the first service according to the operation type identifier.

In an alternative implementation, the operation type identification includes an access identification. And the client end which is not connected with the service end can send an access request message to the first service end according to the access identifier.

In an alternative implementation, the operation type identifier includes an update identifier. And the client connected with the second service end can establish connection with the first service end according to the update identification. Or, the client terminal not connected with the service terminal can establish connection with the first service terminal according to the update identification.

In an alternative implementation, the target message is a control message of the message queue telemetry transport protocol MQTT, and the operation type is identified on a variable header of the target message.

In an alternative implementation, the server information includes an IP address of the first server, and the target packet further includes an IP address type identifier. The client may read the IP address of the first service end of the target length from the target packet according to the IP address type identifier.

In an alternative implementation, the type of the IP address of the first service end is IPv4, and the target length is 4 bytes. Or the type of the IP address of the first service end is IPv6, and the target length is 16 bytes.

In a third aspect, an embodiment of the present application further provides a server, where the server is a server according to the first aspect, and the first server is configured to execute the data transmission method according to the first aspect.

In a fourth aspect, an embodiment of the present application provides a server device. The server device includes a processor and a memory, the processor and the memory being coupled. The memory is used for storing programs; the processor is configured to execute a program in the memory, so that the server device executes the data transmission method described in the first aspect.

Alternatively, the server device may be a server, a computing device, a chip, or the like.

In a fifth aspect, an embodiment of the present application provides a client, where the client is configured to perform the data transmission method described in the first aspect.

In a sixth aspect, embodiments of the present application provide a client device comprising a processor and a memory, the processor and the memory coupled. The memory is used for storing a program, and the processor is used for executing the program in the memory, so that the client performs the data transmission method according to the second aspect.

In a seventh aspect, an embodiment of the present application provides a chip. The chip includes at least one processor and an interface. The interface is for providing program instructions or data to the at least one processor. At least one processor is configured to execute program instructions to implement the method of the first or second aspect.

In an eighth aspect, embodiments of the present application provide a computer-readable storage medium. The computer readable storage medium stores a computer program which, when executed, implements the method according to the first or second aspect.

In a ninth aspect, embodiments of the present application provide a computer program product. The computer program product comprises computer program code. The computer program code implementing the method of the first or second aspect when executed.

Drawings

FIG. 1 is a schematic diagram of a network according to an embodiment of the present application;

fig. 2 is a schematic diagram of an optical transmission network according to an embodiment of the present application;

fig. 3 is a schematic flow chart of a data transmission method according to an embodiment of the present application;

fig. 4 is a schematic flow chart of an embodiment of the present application when the operation type is access;

FIG. 5a is a schematic diagram of a message structure according to an embodiment of the present application;

fig. 5b is a schematic structural diagram of a fixed header of a message according to an embodiment of the present application;

fig. 5c is a schematic diagram of a variable header structure of a message according to an embodiment of the present application;

fig. 6a is a schematic diagram of an application scenario of a data transmission method according to an embodiment of the present application;

fig. 6b is a schematic diagram of an operation type in the scenario of fig. 6a according to an embodiment of the present application;

FIG. 7 is a flowchart illustrating an update of an operation type according to an embodiment of the present application;

FIG. 8 is a schematic diagram of an operation type update in the scenario of FIG. 6a according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of a server device according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of a client device according to an embodiment of the present application.

Detailed Description

Embodiments of the present application are described below with reference to the accompanying drawings. As one of ordinary skill in the art can know, with the development of technology and the appearance of new scenes, the technical scheme provided by the embodiment of the application is also applicable to similar technical problems.

The terms first, second and the like in the description and in the claims and in the above-described figures, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the terms so used are interchangeable under appropriate circumstances and are merely illustrative of the manner in which embodiments of the application have been described in connection with the description of the objects having the same attributes. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. In addition, "at least one" means one or more, and "a plurality" means two or more. "and/or", describes an association relationship of an association object, and indicates that there may be three relationships, for example, a and/or B, and may indicate: a alone, a and B together, and B alone, wherein a, B may be singular or plural. The character "/" generally indicates that the context-dependent object is an "or" relationship. "at least one of" or the like means any combination of these items, including any combination of single item(s) or plural items(s). For example, at least one (one) of a, b, or c may represent: a, b, c, a-b, a-c, b-c, or a-b-c, wherein a, b, c may be single or plural.

Referring to fig. 1, in a communication network in a publish/subscribe mode, the communication network includes a client and a server. After the clients establish connection with the server, they subscribe to the same topic (topic) from the server. After a client (e.g., client 1 in fig. 1) subscribed to the topic sends a message to the server, other clients (e.g., client 2 and client n in fig. 1) subscribed to the topic can obtain the message from the server.

In an optical transport network, an example of a communication network in a publish/subscribe mode is shown in fig. 2. A server on the remote management platform runs a server, and a gateway device connected with the remote management platform runs a client. The gateway equipment is connected with user equipment such as a computer, a set top box and the like, and provides application services for the user equipment. Optionally, the gateway device may access the remote management platform through an optical line terminal (optical line terminal, OLT).

In the embodiment of the application, the remote management platform is used for managing and controlling the client device. The remote management platform can remotely manage the behavior of the client, acquire the relevant data collected by the client, remotely upgrade the client software and the like through a subscription/release protocol. Alternatively, the remote management platform may be a network management center; the remote management platform may also be a client subscribed to a related topic (topic), exchange messages with other clients, and the application is not limited in this respect.

Alternatively, in the optical transport network shown in fig. 2, the server may also operate on other devices, such as a computing board, a private cloud, a common physical server, and the like, besides the server on the remote management platform, which is not limited by the present application.

Alternatively, the gateway device in fig. 2 may be a switch, a router, a device supporting two-layer or three-layer network protocols, and the application is not limited thereto. The user device shown in fig. 2 may also be a mobile phone, a wearable device, etc., which is not limited in this aspect of the present application.

Alternatively, in the optical transmission network shown in fig. 2, the client may also operate on other network hardware devices, such as a monitor, a temperature sensing device, a smart water meter, etc., besides the gateway device, which is not limited by the present application.

Alternatively, the communication network of the publish/subscribe mode may be implemented on other networks than the optical transmission network shown in fig. 2. For example, in a monitoring network, a server may run on a server, a computing center, a private cloud, a public cloud, etc., and a client may run on a monitor device.

Alternatively, in the network shown in fig. 1 or fig. 2, the message transmission in the publish/subscribe mode may be implemented by transmitting the message of the queue telemetry transport protocol MQTT. That is, in the network shown in fig. 1 or fig. 2, the server may be an MQTT server, and the client may be an MQTT client.

Alternatively, in addition to MQTT, the message transmission of the publish/subscribe mode may be implemented in other manners, such as a data distribution service (data distribution service for real-time systems, DDS) protocol, an advanced message queue protocol (advanced message queuing protocol, AMQP), etc., which is not limited by the present application.

In the network shown in fig. 1 or fig. 2, after the client establishes a connection with the server, the transmission of the message can be achieved through the publish/subscribe mode. In order to establish a connection between a client and a server, the client needs to acquire an address (e.g., an IP address) of the server. One common method of establishing a connection is to manually configure the address of the server on the client, thereby implementing the connection between the client and the server. But this approach is inefficient and costly.

The embodiment of the application provides a data transmission method and related equipment, wherein a server informs a client of the address of the server, so that automatic connection between the client and the server is realized. As shown in fig. 3, the data transmission method provided by the embodiment of the present application includes:

301. the first server sends a target message, wherein the target message comprises server information of the first server, and the server information is used for indicating an address of the first server.

The first service end can indicate the address of the first service end to the client through the service end information in the target message.

Alternatively, the server information may include an internet (internet protocol, IP) address of the first server, a media storage control bit (media access control, MAC) address, vendor information, etc., which is not limited in the present application.

302. The first service end receives an access request message from the client end.

The client can determine the address of the first service end according to the service end information in the target message. The client may directly or indirectly determine the address of the first service according to the service information. For example, the client may directly read the IP address or MAC address of the first service included in the target packet. Or, the client may determine the port number of the first service according to the IP address and vendor information of the first service included in the target packet, thereby determining the IP address and port number of the first service.

Optionally, the target message may also carry authentication information, and only the client that passes the authentication can process the target message, so that the server can manage the designated device (client device) that passes the authentication. For example, vendor information or authentication information may include an organization unique identifier (organizationally unique identifier, OUI) of the vendor, and the client may only process target messages that include the own vendor OUI, so that the MQTT server may only manage the own vendor's devices.

The address of the first service end is determined, and the client can send an access request message to the first service end. The destination address of the access request message is the address of the first service end, and the access request message is used for requesting to establish connection with the first service end. Accordingly, the first service end may receive the access request message from the client end.

303. And the first service end sends an access response message to the client according to the access request message.

And the first service end sends an access response message to the client end according to the access request message, so that the connection between the first service end and the client end is completed.

In the embodiment of the application, the first service end sends the target message, and the address of the first service end is indicated to the client end through the service end information in the target message, so that the address of the service end is configured on the client end, and the connection between the service end and the client end is completed. The method can automatically establish connection through the client and the server, does not need to manually configure the address of the server on the client, and improves the efficiency of configuring the address of the server and establishing connection.

The data transmission method provided by the embodiment of the application can be applied to an MQTT protocol, and the application of the data transmission method provided by the embodiment of the application in the MQTT protocol is explained below. It should be noted that, in addition to the MQTT protocol, the data transmission method provided in the embodiment of the present application may also be applied to other protocols, which is not limited in this aspect of the present application. As shown in fig. 4, the data transmission method provided by the embodiment of the present application includes:

401. And after the client is started, opening the target port.

In the embodiment of the application, a new message type of the MQTT protocol is defined: discovery (DISCOVER) messages. The discovery message is used for indicating the address of the server to the client. In the embodiment of the present application, the type of the Discovery (DISCOVER) message is also referred to as the target message type.

In the embodiment of the application, the destination port can be appointed for transmitting the discovery message. Therefore, after the client is started, the client may open (learning) the destination port to receive the discovery message through the destination port, and acquire the address of the server according to the discovery message received on the destination port. In the embodiment of the application, the appointed port is also called a target port.

In embodiments of the present application, the type of destination port is not limited, and the destination port may be a secure transport layer protocol (transport layer security, TLS) port, such as 8884 port; non-secure transport layer protocol (non-transport layer security, non-TLS) ports, such as 1884 ports, may also be used, as embodiments of the application are not limited in this regard. Optionally, the discovery message is transmitted through the TLS port, so that the discovery message can be prevented from being tampered, and the network security is improved.

402. The first server side sends a target message through the target port.

As described above, the destination port is used to transmit discovery messages. After the first service end is started, the first service end can send the target message through the target port. The target message is a discovery message, and the server information in the target message is used for indicating the address of the first server. The first client may indicate the address of the first server to the client via the target message.

As shown in fig. 5a, the target packet may include information such as a control packet type identifier, a control packet type verification identifier, an IP address type, an operation type identifier, and an IP address of the first service end.

The control packet type identifier (control packet type) is used for indicating the message type of the target message. In the MQTT protocol, the control packet type is identified as a message type field on the fixed header (fix header) of the MQTT control packet. As shown in fig. 5b, the message type field is the 4 th to 7 th bits on the fixed header. In the MQTT protocol, the type of a message is represented by the value of the message type field. In the embodiment of the application, the value of the message type field of the Discovery (DISCOVER) message is 0. In the embodiment of the application, the message type field with the value of 0 is also called a target message type identifier.

The control packet type verification identifier (flags of control packet type) is used for verifying the validity of the message type identifier.

The IP address type is used to indicate the type of the IP address of the server carried in the Discovery (DISCOVER) message. The IP address may be an address of an IPv4 or IPv6 protocol, for example, which is not limited by the present application.

The operation type identifier is used to indicate that a Discovery (DISCOVER) message indicates the operation type performed by the client, such as access, update, etc., which is not limited by the present application.

Optionally, besides the first service end is started, the first service end can be triggered to send the target message by other mechanisms. For example, the first service end may send the target message at a fixed time, and the time interval of the fixed time sending may be 1 minute, 5 minutes, or the like, which is not limited in the present application. Or after the client is started, the online message can be broadcasted, the server receives the online message, sends a target message to the client, and the like, which is not limited by the application.

Optionally, the first service end may broadcast the target message to the clients in the same network segment, so as to reduce consumption of communication resources. Alternatively, the first service end may also send the target message to the clients in the same network segment one by one, which is not limited in the present application.

403. The client determines whether the message type identification in the target message is legal or not according to the message type verification identification in the target message; if not, execute step 404; if it is legal, step 405 is performed.

In order to avoid errors and the like of the MQTT control packet, a control packet type verification identifier is set in the MQTT protocol so as to verify the validity of the control packet type identifier. The control packet type verification identifier in the discovery message is used for verifying the validity of the discovery message type identifier. The control packet type verification identifier in the discovery packet is also referred to as the target packet type verification identifier, and the specific position is shown in fig. 5a and 5b on the fixed header (fix header) in the discovery packet.

Alternatively, as shown in fig. 5b, the value of the target message type verification identifier may be set to 0. The client reads the control packet type verification identifier in the target message, and when the value is determined to be 0, the control packet type (namely the message type field) of the discovery message is determined to be legal, otherwise, the control packet type (namely the message type field) of the discovery message is determined to be illegal. It should be noted that, the value of 0 is only an example, and the value of the control packet type verification identifier of the discovery packet may be other values, which is not limited herein.

404. The client ignores the target message.

If the client determines that the control packet type verification identifier in the target message is illegal, the MQTT control packet is tampered, faked and the like, so that the client ignores the target message.

405. And the client determines the target message as a discovery message according to the message type identifier in the target message.

The client reads the message type field of the target message, and if the value of the field is 0, the client can determine that the target message is a discovery message, and execute the steps 406 and the following steps. If the value of the field is not 0, it indicates that the target message is wrong, and step 404 is performed.

It should be noted that, the value of 0 is only an example, and the value of the control packet type identifier of the discovery packet may be other values, which is not limited herein.

406. The client determines the operation type identifier in the target message as access.

As shown in fig. 5a, an operation type identifier may be included on a variable header (variable header) in the target message, to indicate that the discovery message indicates a type of operation performed by the client, such as access, update, etc. The specific location of the operation type identification in the discovery message is seen in fig. 5a or fig. 5c.

Optionally, as shown in fig. 5c, an operation type field is included on the variable header of the discovery message, where the value of the field is used to indicate the operation type of the discovery message. For example, the value corresponding to the access type may be set to 0. The service side reads the operation type field of the target message, and when determining that the value of the operation type field is 0, the service side can determine that the operation type identifier of the target message is accessed.

407. The client determines whether the server is not connected; if connected, go to step 404, if not, go to step 408.

408. And the client determines the target length of the IP address of the first service end according to the IP address type identification in the target message.

As shown in fig. 5a, the variable header of the discovery packet further includes an IP address type identifier, which is used to indicate the IP address type of the first service end. Alternatively, the IP address type may be an IP address type of an IPv4 protocol or an IPv6 protocol, or an IP address type of a protocol that may occur in the future. Each IP address has a corresponding length, for example, an IP address of the IPv4 type has a length of 4 bytes and an IP address of the IPv6 type has a length of 16 bytes. In the embodiment of the present application, this length is referred to as a target length.

409. The client reads the IP address of the target length.

When the target length is determined, the client may read the IP address of the target length from the corresponding location of the target message (i.e. the location of the IP address of the first server shown in fig. 5a and 5 b), where the IP address is the IP address of the first server.

410. And the client sends an access request message to the first service terminal.

411. And the first server sends an access response message to the client.

Step 410 and step 411 refer to steps 202 and 203 of the embodiment shown in fig. 2, and are not described here again.

Alternatively, an MQTT server may communicate in multiple network segments through multiple network cards, and then the MQTT server may send target packets in multiple network segments, so as to implement connection with clients on different network segments. For example, as shown in fig. 6a, the MQTT service end (i.e., the aforementioned first service end) communicates with devices in the 192.168.1 network segment through the network card 1, and communicates with devices in the 192.168.2 network segment through the network card 2. It is assumed that neither client 1 nor client 2 in the 192.168.1 network segment is connected to the server, and that client 3 in the 192.168.2 network segment is connected to MQTT server 2 (second server). The MQTT server 1 (first server) may send a target packet over the network card 1 in the 192.168.1 network segment, where the server information in the packet is used to indicate the address of the MQTT server 1 in the 192.168.1 network segment. The MQTT server 1 (first server) may send a target packet over the network card 2 in a 192.168.2 network segment, where the server information in the packet is used to indicate the address of the MQTT server 1 in the 192.168.2 network segment.

As shown in fig. 6b, in the target packets sent to different network segments, the operation type identifier is accessed (i.e., the value of the operation type field is 0). Since neither the client 1 nor the client 2 is connected to the server, after receiving the target packet, in step 202 shown in fig. 2 and step 410 shown in fig. 4, the client 1 and the client 2 may send an access request packet to the network card 1. The destination address of the access request message is the address of the MQTT server 1 in the 192.168.1 network segment, and is used for requesting to access the MQTT server 1.

Since the client 3 has already connected to the MQTT server 2 (second server), after receiving the target message, in step 407 shown in fig. 4, it is determined that the server has already been connected, and step 404 is performed (the target message is ignored).

Optionally, the operation type of the discovery message may further include updating, and the operation flow in the case of updating is described below with reference to fig. 7, which specifically includes:

701. and after the client is started, opening the target port.

702. The first server side sends a target message through the target port.

703. The client determines whether the message type identifier in the target message is legal or not according to the target message type verification identifier in the target message; if not, execute step 704; if it is legal, step 705 is performed.

704. The client ignores the target message.

705. And the client determines the target message as a discovery message according to the message type identifier in the target message.

The client reads the message type field of the target message, and if the value of the field is 0, the client can determine that the target message is a discovery message, and execute the steps 706 and later. If the value of the field is not 0, it indicates that the target message is wrong, and step 704 is performed.

It should be noted that, the value of 0 is only an example, and the value of the control packet type identifier of the discovery packet may be other values, which is not limited herein.

706. The client determines that the operation type identifier in the target message is updated.

Alternatively, the value corresponding to the update type may be set to 1. The server reads the operation type field of the target message, and when the operation type field is determined to be 1, the operation type identifier of the target message can be determined to be updated.

707. And the client determines the target length of the IP address of the first service end according to the IP address type identification in the target message.

708. The client reads the IP address of the target length.

Steps 707 to 708 refer to steps 408 to 409 of the embodiment shown in fig. 4, and are not described here again.

709. The client judges whether the IP address in the target message is the same as the IP address of the connected server; if so, step 704 is performed, and if not, step 710 is performed.

In step 708, the client reads the IP address in the target message (i.e., the IP address of the first server), and if the client is already connected to the server, the client can determine whether the IP address in the target message (i.e., the IP address of the first server) is the same as the IP address of the connected server. If the IP addresses are the same, the client does not need to update (reestablish the connection with the first server), and step 704 is performed to ignore the target message. If the IP addresses are different, it is indicated that the target message indicates that the client updated service end is different from the service end connected to the client, and the client may update the connected service end according to the target message, that is, establish a connection with the first service end, so as to execute steps 710 to 711.

In the case that the client is not connected to the server, the client may determine that the client is not connected to the server in step 709, thereby determining that steps 710 and 711 are performed.

Optionally, after determining that the operation type is updated in step 706 (or before/at the same time as step 706), the client may also determine whether the client is connected to the server, and if the client is not connected to the server, the steps 707 and thereafter are directly performed. Since the client is not connected to the server, steps 709, 712, and 713 do not need to be performed.

710. And the client sends an access request message to the first service terminal.

711. And the first server sends an access response message to the client.

Steps 710 to 711 refer to steps 410 to 411 of the embodiment shown in fig. 4, and are not described here again.

712. The client determines whether the second server is connected, and if so, performs step 713.

Alternatively, if the client is connected to the second server (the second server is not the same as the first server), the client may disconnect from the second server according to the target message (the operation type is identified as updated), and step 713 may be performed.

713. And the client sends a disconnection request message to the second client.

The client requests to disconnect the connection between the second service ends by sending a disconnection request message to the second service ends.

For example, if the second server is to switch addresses, in order to reduce the duration of service interruption (i.e. the duration of disconnection between the server and the client), the first server may be started, and the first server sends a target message (the operation type is update) to the client, so that the client originally connected to the second server is connected to the first server. Before the second service end is switched, the clients connected with the second service end are connected with the first service end, and the clients are managed through the first service end. The service is not interrupted while the service side switching is completed.

Under the condition that the operation type is 1 (updating), the clients in different wave bands can determine the address of the first service end on the corresponding wave band according to the target message, so that the service end connected with the client is updated. For example, based on the connection relationship in fig. 6a, in the case where the operation type in the target message is update, the specific case is as shown in fig. 8. In the target message sent by the MQTT server 1 to different network segments, the operation type identifier is updated.

As shown in fig. 8, in the target packets sent to different network segments, the operation type identifier is updated (i.e., the value of the operation type field is 1). Since neither the client 1 nor the client 2 is connected to the server, after receiving the target packet, in step 707 shown in fig. 7, the client 1 and the client 2 may determine that the first server is not connected, so as to send an access request packet to the network card 1 in step 710. The destination address of the access request message is the address of the MQTT server 1 in the 192.168.1 network segment, and is used for requesting to access the MQTT server 1 in the 192.168.1 network segment.

Since the client 3 has already connected to the MQTT server 2 (second server), after receiving the target packet, in step 407 shown in fig. 4, the client 3 may determine that the first server is not connected, so as to send an access request packet to the network card 3 in step 710. The destination address of the access request message is the address of the MQTT server 1 in the 192.168.2 network segment, and is used for requesting to access the MQTT server 1 in the 192.168.3 network segment. Optionally, after step 707, the client 3 may perform steps 712 and 713 according to the operation type identifier as update, thereby disconnecting from the second server (MQTT server 2).

Referring to fig. 9, the embodiment of the application further provides a server device 900, which includes a processor 910 and a memory 920, where the processor 910 is coupled to the memory 920. The memory 920 is used for storing programs. The processor 910 is configured to execute the program in the memory 920, so that the server device 900 performs the actions performed by the server in any of the foregoing embodiments of fig. 3 to 8, thereby implementing a corresponding data transmission method.

Referring to fig. 10, an embodiment of the present application further provides a client device 1000, including a processor 1010 and a memory 1020, where the processor 1010 is coupled to the memory 1020. The memory 1020 is used for storing programs. The processor 1010 is configured to execute the program in the memory 1020, so that the client device 1000 performs the actions performed by the client in any of the foregoing embodiments of fig. 3 to 8, thereby implementing the corresponding data transmission method.

It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, which are not repeated herein.

In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in part or all of the technical solution or in part in the form of a software product stored in a storage medium, including instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a read-only memory (ROM), a random access memory (random access memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

Claims (30)

1. A data transmission method, comprising:

the method comprises the steps that a first server sends a target message, wherein the target message comprises server information of the first server, and the server information is used for indicating an address of the first server;

the first service end receives an access request message from a client end, wherein the destination address of the access request message is the address of the first service end, and the access request message is used for requesting to establish connection between the client end and the first service end;

and the first server sends an access response message to the client according to the access request message.

2. The method of claim 1, wherein the first server sends the target message, including:

the first server side sends the target message through a target port, wherein the target port is used for transmitting the target message of a target message type; the target message of the target message type is used for indicating the address of the first service end to the client.

3. The method according to claim 1 or 2, wherein the target message further comprises a target message type identifier, the target message type identifier being used to indicate that the type of the target message is a target message type; the target message of the target message type is used for indicating the address of the first service end to the client.

4. The method of claim 3, wherein the target message further comprises a target message type verification identifier, the target message type verification identifier being used by the client to verify the validity of the target message type identifier.

5. The method according to claim 3 or 4, wherein the target message is a control message of a message queue telemetry transport protocol MQTT, the target message type identifier is a message type field on a fixed header of the target message, and the value of the message type field is 0.

6. The method according to any one of claims 1 to 4, wherein the target message further comprises an operation type identifier, the operation type identifier being used to instruct the client to send the access request message to the first server.

7. The method of claim 6, wherein the operation type identifier comprises an access identifier, the access identifier being used to instruct the client that is not connected to a server to send the access request message to the first server.

8. The method of claim 6, wherein the operation type identifier comprises an update identifier that is used to:

Indicating the client connected with a second service end to establish connection with the first service end; or,

and indicating the client terminal which is not connected with the service terminal to establish connection with the first service terminal.

9. The method according to any of claims 6 to 8, wherein the target message is a control message of a message queue telemetry transport protocol MQTT, the operation type being identified on a variable header of the target message.

10. The method according to any one of claims 1 to 9, wherein the first server sends a target message, including:

and the first server broadcasts the target message.

11. The method according to any one of claims 1 to 10, wherein the server side information includes an IP address of the first server side, and the target message further includes an IP address type identifier, where the IP address type identifier is used to instruct the client to read an IP address of the first server side with a target length from the target message.

12. The method of claim 11, wherein the step of determining the position of the probe is performed,

the type of the IP address of the first service end is IPv4, and the target length is 4 bytes; or,

The type of the IP address of the first service end is IPv6, and the target length is 16 bytes.

13. A data transmission method, comprising:

the method comprises the steps that a client receives a target message from a first service end, wherein the target message comprises service end information of the first service end, and the service end information is used for indicating an address of the first service end;

the client sends an access request message to the first service end, wherein the destination address of the access request message is the address of the first service end, and the access request message is used for requesting to establish the connection between the client and the first service end;

the client receives an access response message from the first service end.

14. The method of claim 13, wherein the client receives the target message from the first service, comprising:

the client receives a target message from a first service end through a target port, wherein the target port is used for transmitting the target message of a target message type; the target message of the target message type is used for indicating the address of the first service end to the client.

15. The method according to claim 13 or 14, wherein the target message further comprises a target message type identification; before the client sends the access request message to the first service end, the method further comprises:

The client determines that the message type of the target message is a target message type according to the target message type identifier in the target message;

the client reads the server information from the target message according to the message type of the target message as the target message type;

and the client determines the address of the first server according to the server information.

16. The method of claim 15, wherein the target message further comprises a target message type verification identifier, and wherein before the client sends the access request message to the first service, the method further comprises:

and the client verifies the validity of the target message type identifier according to the target message type verification identifier in the target message.

17. The method according to claim 15 or 16, wherein the target message is a control message of a message queue telemetry transport protocol MQTT, the target message type identifier is a message type field on a fixed header of the target message, and the value of the message type field is 0.

18. The method according to any one of claims 13 to 17, wherein the target message further comprises an operation type identification; the client sends an access request message to the first service end, including:

And the client sends the access request message to the first server according to the operation type identifier.

19. The method of claim 18, wherein the operation type identification comprises an access identification; the client sends an access request message to the first service end, including:

and the client terminal which is not connected with the server terminal sends the access request message to the first server terminal according to the access identifier.

20. The method of claim 18, wherein the operation type identification comprises an update identification; the client sends an access request message to the first service end, including:

the client connected with the second service end establishes connection with the first service end according to the update identification; or,

and the client which is not connected with the server establishes connection with the first server according to the update identification.

21. The method according to any of claims 18 to 20, wherein the target message is a control message of a message queue telemetry transport protocol, MQTT, the operation type being identified on a variable header of the target message.

22. The method according to any one of claims 13 to 21, wherein the server side information includes an IP address of the first server side, the target message further includes an IP address type identifier, and before the client side sends an access request message to the first server side, the method further includes:

and the client reads the IP address of the first server with the target length from the target message according to the IP address type identifier.

23. The method of claim 22, wherein the step of determining the position of the probe is performed,

the type of the IP address of the first service end is IPv4, and the target length is 4 bytes; or,

the type of the IP address of the first service end is IPv6, and the target length is 16 bytes.

24. A server, wherein the server is a first server, and the first server is configured to perform the method of any one of claims 1 to 12.

25. A server device comprising a processor and a memory, the processor being coupled to the memory,

the memory is used for storing programs;

the processor configured to execute the program in the memory, so that the server device performs the method according to any one of claims 1 to 12.

26. A client for performing the method of any of claims 13 to 23.

27. A client device comprising a processor and a memory, the processor being coupled to the memory,

the memory is used for storing programs;

the processor configured to execute the program in the memory, to cause the client device to perform the method of any one of claims 13 to 23.

28. A chip comprising at least one processor and an interface;

the interface is used for providing program instructions or data for the at least one processor;

the at least one processor is configured to execute the program instructions to implement the method of any one of claims 1 to 12 or claims 13 to 23.

29. A computer readable storage medium, characterized in that the computer readable storage medium stores a computer program which, when run, implements the method of any one of claims 1 to 12 or 13 to 23.

30. A computer program product, the computer program product comprising: computer program code which, when executed, implements the method of any one of claims 1 to 12 or claims 13 to 23.