CN114125940A

CN114125940A - Data message sending method, data message processing method, data message sending device, data message processing device, data message sending equipment and data message

Info

Publication number: CN114125940A
Application number: CN202010901599.1A
Authority: CN
Inventors: 曾春亮; 翟召轩; 成云峰; 陈钊; 黄翔文; 范作; 杨启昌; 余志刚; 吴泰月; 冯涛
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority date: 2020-08-31
Filing date: 2020-08-31
Publication date: 2022-03-01
Also published as: WO2022042235A1

Abstract

The embodiment of the application provides a data message sending method, a data message processing device, data message equipment and a data message, and relates to the technical field of communication. The method comprises the following steps: determining m fields included in the data message from predefined n fields, wherein n is a positive integer, and m is a positive integer less than or equal to n; generating a data message comprising m fields; the data message also comprises n flag bits, wherein the ith flag bit in the n flag bits is used for indicating whether the data message contains a field corresponding to the ith flag bit in n fields; and sending the data message. The embodiment of the application enhances the universality of the data message.

Description

Data message sending method, data message processing method, data message sending device, data message processing device, data message sending equipment and data message

Technical Field

The embodiment of the application relates to the technical field of communication, in particular to a data message sending method, a data message processing method, a data message sending device, a data message processing device, data message equipment and a data message.

Background

A communication protocol refers to the rules and conventions that must be followed by two entities to complete a communication or service.

In the related art, different services use different communication protocols. For example, HTTP (HyperText Transfer Protocol) is a transmission Protocol for transmitting HyperText from a WWW server to a local browser, and is generally used for transmitting data on some data channels supporting IP (Internet Protocol), and is not applicable on some Low-bandwidth data channels such as BLE (Bluetooth Low Energy).

Disclosure of Invention

The embodiment of the application provides a data message sending method, a data message processing device, data message equipment and a data message. The technical scheme is as follows:

in one aspect, an embodiment of the present application provides a data message sending method, where the method includes:

determining m fields included in a data message from predefined n fields, wherein n is a positive integer, and m is a positive integer less than or equal to n;

generating the data message comprising the m fields; the data message further includes n flag bits, and an ith flag bit of the n flag bits is used to indicate whether the data message includes a field corresponding to the ith flag bit of the n fields;

and sending the data message.

In another aspect, an embodiment of the present application provides a data packet processing method, where the method includes:

receiving a data message;

reading n flag bits included in the data message; the ith flag bit in the n flag bits is used for indicating whether the data message contains a field corresponding to the ith flag bit in predefined n fields, wherein n is a positive integer;

and analyzing m fields included in the data message based on the n flag bits, wherein m is a positive integer less than or equal to n.

In another aspect, an embodiment of the present application provides a data packet sending apparatus, where the apparatus includes:

a field determining module, configured to determine m fields included in a data packet from predefined n fields, where n is a positive integer and m is a positive integer less than or equal to n;

a message generating module, configured to generate the data message including the m fields; the data message further includes n flag bits, and an ith flag bit of the n flag bits is used to indicate whether the data message includes a field corresponding to the ith flag bit of the n fields;

and the message sending module is used for sending the data message.

In another aspect, an embodiment of the present application provides a data packet processing apparatus, where the apparatus includes:

the message receiving module is used for receiving a data message;

a flag bit reading module, configured to read n flag bits included in the data packet; the ith flag bit in the n flag bits is used for indicating whether the data message contains a field corresponding to the ith flag bit in predefined n fields, wherein n is a positive integer;

and the field analyzing module is used for analyzing m fields included in the data message based on the n flag bits, wherein m is a positive integer less than or equal to n.

In yet another aspect, an embodiment of the present application provides a data message sending device, where the device includes a processor, a memory, and a transceiver;

the processor is configured to determine m fields included in a data packet from predefined n fields, where n is a positive integer and m is a positive integer less than or equal to n;

the processor is further configured to generate the data packet including the m fields; the data message further includes n flag bits, and an ith flag bit of the n flag bits is used to indicate whether the data message includes a field corresponding to the ith flag bit of the n fields;

the transceiver is further configured to send the data packet.

In yet another aspect, an embodiment of the present application provides a data message processing apparatus, which includes a processor, a memory, and a transceiver;

the transceiver is used for receiving data messages;

the processor is used for reading n flag bits included in the data message; the ith flag bit in the n flag bits is used for indicating whether the data message contains a field corresponding to the ith flag bit in predefined n fields, wherein n is a positive integer;

the processor is further configured to analyze m fields included in the data packet based on the n flag bits, where m is a positive integer less than or equal to n.

In another aspect, an embodiment of the present application provides a data packet for inter-device transmission, where the data packet is used for loading information during data transmission between devices, and the data packet includes m fields of predefined n fields, where n is a positive integer, and m is a positive integer less than or equal to n;

the data packet further includes n flag bits, and an ith flag bit of the n flag bits is used to indicate whether the data packet includes a field corresponding to the ith flag bit of the n fields.

In yet another aspect, an embodiment of the present application provides a computer-readable storage medium, where a computer program is stored, and the computer program is loaded and executed by a processor to implement the data packet sending method according to the above aspect or implement the data packet processing method according to the above aspect.

In yet another aspect, embodiments of the present application provide a computer program product including computer instructions stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and executes the computer instructions, so that the computer device executes the data message sending method according to the above aspect, or implements the data message processing method according to the above aspect.

The technical scheme provided by the embodiment of the application can bring the following beneficial effects:

by setting a flag bit in the data message, where the flag bit is used to indicate whether the data message includes a field corresponding to the flag bit, and the flag bit corresponds to a predefined field, in the embodiments of the present application, the data message may be flexibly and dynamically assembled through the flag bit, so as to change the transmission amount of the data message, enable the data message to be transmitted on different data channels, and enhance the universality of the data message.

Drawings

FIG. 1 is a schematic illustration of an implementation environment provided by one embodiment of the present application;

fig. 2 is a flowchart of a data packet sending method according to an embodiment of the present application;

fig. 3 to fig. 5 are schematic diagrams of formats of data packets provided in the embodiment of the present application;

fig. 6 is a flowchart of a data packet processing method according to an embodiment of the present application;

fig. 7 to fig. 10 are schematic diagrams of formats of data packets provided in the embodiment of the present application;

fig. 11 is a block diagram of a data message transmitting apparatus according to an embodiment of the present application;

fig. 12 is a block diagram of a data packet processing apparatus according to an embodiment of the present application;

fig. 13 is a schematic structural diagram of a data packet sending device according to an embodiment of the present application;

fig. 14 is a schematic structural diagram of a data packet processing device according to an embodiment of the present application.

Detailed Description

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

Referring to fig. 1, a schematic diagram of an implementation environment provided by an embodiment of the present application is shown, where the implementation environment may include: a first device 10, a second device 20 and a third device 30.

In this embodiment, the first device 10 refers to a data packet sending device, and the data packet sending device refers to a device that sends a data packet. Exemplarily, the first device 10 may be a terminal or a server, for example, the terminal may be a smartphone, a tablet, a PC (Personal Computer), a smart multimedia device, a smart wearable device, or the like; the server may be one server, a server cluster composed of a plurality of servers, a cloud server, or an IoT (Internet of Things) server. Of course, in a possible implementation, the data packet may be sent by an APP (Application).

In this embodiment of the application, the second device 20 is a relay device, that is, the second device 20 is a device for forwarding the data packet sent by the first device 10 to the third device 30. Illustratively, the second device 20 may be a bridge, a router, a gateway, or the like.

Illustratively, the third device 30 may be a terminal, for example, the terminal may be a smartphone, a tablet, a PC (Personal Computer), an intelligent multimedia device, an intelligent wearable device, an intelligent home device, an intelligent transportation device, and the like. The number of the third devices may be one or more, and the embodiment of the present application is not limited thereto.

It should be noted that both the second device 20 and the third device 30 may be referred to as data packet processing devices, and the data packet processing device refers to a device that processes a data packet.

In a possible implementation, the first device 10 and the third device 30 may not be able to communicate directly, requiring the second device 20 to relay. At this time, the first device 10 sends the data packet to the second device 20, so that the second device 20 forwards the data packet to the third device 30; alternatively, the first device 10 and the third device 30 may communicate directly without relaying through the second device 20, that is, peer-to-peer communication may be implemented between the first device 10 and the third device 30. At this time, the first device 10 transmits the data packet to the third device 30.

In a possible implementation manner, the data packet in the embodiment of the present application may also be referred to as a message or a domain network layer message. The first device 10 may simultaneously send multiple messages to the second device 20 or the third device 30, which form a total datagram.

The technical solution of the present application will be described below with reference to several exemplary embodiments.

Referring to fig. 2, a flowchart of a data packet sending method according to an embodiment of the present application is shown, where the method may be executed by a first device. The method may include several steps as follows.

Step 201, m fields included in the data message are determined from predefined n fields, where n is a positive integer and m is a positive integer less than or equal to n.

It is understood that n fields that can be included in a data message are predefined by a skilled person, and the n fields do not necessarily need to be all given in the data message, but can be given in the data message by selecting necessary fields according to a transmission scenario. For example, in a possible implementation, it is assumed that the predefined n fields include: the field related to the transmission scenario 1 is field 2 and field 3, and the data packet includes 2 fields: field 2 and field 3. For another example, if the fields related to transmission scenario 2 are field 1, field 2, field 3, and field 4, the data packet includes 4 fields: field 1, field 2, field 3, and field 4. For another example, the data packet may not include any one of the predefined n fields, that is, m is 0.

Step 202, a data packet including m fields is generated.

The data message also comprises n flag bits, the ith flag bit in the n flag bits is used for indicating whether the data message contains a field corresponding to the ith flag bit in n fields, and i is a positive integer less than or equal to n.

The n flag bits correspond to the n fields one by one, and different fields correspond to different flag bits. Still taking the above example as an example, the field 1 corresponds to the flag bit 1, the field 2 corresponds to the flag bit 2, the field 3 corresponds to the flag bit 3, and the field 4 corresponds to the flag bit 4, and assuming that the data packet includes the field 2 and the field 3, the first device may generate the data packet including the field 2 and the field 3, where the data packet includes the flag bit 1, the flag bit 2, the flag bit 3, and the flag bit 4, the flag bit 1 is used to indicate that the data packet does not include the field 1, the flag bit 2 is used to indicate that the data packet includes the field 2, the flag bit 3 is used to indicate that the data packet includes the field 3, and the flag bit 4 is used to indicate that the data packet does not include the field 4. The field contents of field 2 and the field contents of field 3 may be in binary format.

In a possible implementation manner, whether a field corresponding to the flag bit is contained in the data message is determined by the value of the flag bit. The flag bit may be represented by 1 bit, for example, the value of the flag bit may be 0 or 1, and when the value of the flag bit is 0, it indicates that the data packet does not include a field corresponding to the flag bit; when the value of the flag bit is 1, it indicates that the data packet includes a field corresponding to the flag bit. Of course, in other possible implementations, the value of the flag bit may also be other values, which is not limited in this embodiment of the application.

In one example, the first device may determine the value of the flag bit, and then determine the field included in the data packet according to the value of the flag bit.

In another example, the first device may determine a field included in the data packet and then determine a value of the flag bit based thereon.

In the embodiment of the present application, the flag bit corresponding to m fields is used to indicate that the data message contains the m fields.

Step 203, sending the data message.

After the first device generates the data packet, the first device may send the data packet to the second device or the third device.

In summary, in the technical solution provided in this application embodiment, a flag bit is set in a data packet, the flag bit is used to indicate whether the data packet includes a field corresponding to the flag bit, and the flag bit corresponds to a predefined field.

In an exemplary embodiment, as shown in FIG. 3, the n flag bits include at least one of: length flag bit 31, destination address flag bit 32, source address flag bit 33, transaction flag bit 34.

Illustratively, the length flag bit 31 may be denoted as L, the destination address flag bit 32 may be denoted as D, the source address flag bit 33 may be denoted as S, and the transaction flag bit 34 may be denoted as T.

In a possible implementation manner, the value of the flag bit includes a first value and a second value, the first value is used to indicate that the data message does not include the field corresponding to the flag bit, and the second value is used to indicate that the data message includes the field corresponding to the flag bit. L, S, D, T may have a large endian form, the first and second values may each comprise 1 bit, for example, the first value may be 0 and the second value may be 1.

The length flag bit 31 is used to indicate whether the data packet includes a length field 311, and the length field 311 is used to indicate the length of the data packet.

The length of the data packet may refer to the overall length of all fields including the header and Payload.

Illustratively, when the value of L is 0, it indicates that there is no Length field (which may be expressed as Length) in the data packet, and at this time, the Length of the data packet continues to the end of the total data packet. For example, when the lower layer Protocol is a Protocol with data boundaries, such as UDP (User Datagram Protocol), L is 0, which means that the remaining part of the total Datagram is the content of the current Datagram.

When the value of L is 1, the length field exists in the data message, and the length of the current data message is the length indicated by the field content of the length field. Illustratively, when the lower layer Protocol is a streaming Protocol without a data boundary, such as TCP (Transmission Control Protocol), the value of L is only allowed to be set to 1, and if the value of L is not 1, the lower layer connection should be terminated.

In a possible implementation, the length field encoding employs little endian. The length field includes 2 bytes. For example, if the length of the data packet is 1228, the length field is encoded as 0xcc0x 04.

The destination address flag bit 32 is used to indicate whether the data packet contains a destination address field 321, and the destination address field 321 is used to indicate a destination device address of the data packet.

Illustratively, when the value of D is 0, it indicates that no Destination Address field (which may be denoted as Destination Address) exists in the data message. If the lower layer protocol is a streaming transmission protocol which cannot distinguish message boundaries, the receiving equipment of the data message is equipment indicated by the destination equipment address of the data message; if the lower layer protocol is a datagram transport protocol that can distinguish message boundaries, the following two cases are distinguished: 1. if the current data message is the first message in the total datagram, the receiving equipment of the data message is equipment indicated by the destination equipment address of the data message; 2. and if the current data message is not the first message in the total datagram, the field content of the current destination address field is the same as the field content of the destination address field of the first message in the total datagram.

When the value of D is 1, it indicates that a destination address field exists in the data packet, and at this time, the destination device address of the data packet is given by the field content of the destination address field.

Illustratively, when multiple messages occur in the same total datagram, the value of D must be 0 from the 2 nd message, otherwise the remaining data including the message with D ═ 1 is ignored.

In a possible implementation, the destination address field is encoded in 32-bit little-endian, and the destination address field includes 4 bytes.

A source address flag bit 33, configured to indicate whether the data packet includes a source address field 331, where the source address field 331 is used to indicate a sending device address of the data packet.

Illustratively, when the value of S is 0, it indicates that no Source Address field (which may be denoted as Source Address) exists in the data message. If the lower layer protocol is a streaming protocol which can not distinguish the message boundary, the field content of the source address field is given by the lower layer protocol; if the lower layer protocol is a datagram transport protocol that can distinguish message boundaries, the following two cases can be distinguished: 1. if the current data message is the first message in the total Datagram, the field content of the source address field is given by a lower layer protocol (for example, given by a certificate of DTLS (Datagram Transport Level Security); 2. and if the current data message is not the first message in the total datagram, the field content of the current source address field is the same as the field content of the source address field of the first message in the total datagram.

When the value of S is 1, the data message is indicated to have a source address field, and at this time, the sending device address of the data message is given by the field content of the source address field.

Illustratively, when multiple messages occur within the same total datagram, starting with message 2, S must take the value 0. Otherwise, the remaining data containing the S-1 message is ignored.

In a possible implementation, the source address field is encoded in 32-bit little-endian, and the source address field includes 4 bytes.

It should be noted that, in the same network, the situation that different devices use the same address generally does not occur. In a possible implementation, the source address and the destination address are allocated by a cloud server or a gateway instead of a cloud server (BLE, BLE Mesh).

A transaction flag bit 34 for indicating whether a transaction field 341 is included in the data message, and the transaction field 341 is used for indicating the transaction and for tracking the processing procedure of the transaction.

Illustratively, when the value of T is 0, indicating that the transaction function is not currently used, no transaction field exists in the data packet. At this point, the message is neither an active transaction nor a passive transaction, and is only used for notification. Messages must not be handled as normal transaction messages.

When the value of T is 1, the transaction function is used currently, and a transaction field exists in the data message.

In a possible implementation, the Transaction field, which may be denoted as Transaction, comprises 4 bytes.

In the embodiment of the application, the transaction message is received and sent through the transaction flag bit, when the data message comprises a transaction field, the message is indicated to be the transaction message, and the message processing at the moment is processed according to the flow of the transaction; otherwise, processing according to the non-transaction message.

In a possible implementation, the transaction field includes 32 bits, the lower 31 of the 32 bits being used to represent the identity of the transaction, and the most significant of the 32 bits being used to represent the operator type of the transaction.

Illustratively, the lower 31 bits include the lower 7 bits of the 1 st, 2 nd, 3 rd bytes and the 4 th byte, and the Identification of the Transaction may also be referred to as a Transaction unique identifier (Identification). The most significant bit is the most significant bit of the 4 th byte. The most significant bit is used for representing an active mark or a passive mark, when an active starting party of a transaction sends a message, the most significant bit can be set to be 1, and the most significant bit is used for representing the active mark; the most significant bit may be set to 0 when the passive initiator of the transaction sends a message, and the most significant bit is used to indicate the passive flag.

Except for the connection established with the cloud server, when the bottom layer establishes the connection for the first time, all the low-order 31 bits are 0. 256 transaction fields are required to be reserved for processing an implicit function in connection with the cloud server, so that when the connection is established for the first time, the low-order 31-bit is 256, and the cloud server must avoid using 256 transaction fields of 0-255. When the connection is not established for the first time, the low 31 bits are self-incremented by 1 each time a new transaction is actively initiated. It should be noted that 2147483647(2^31-1) is an invalid identifier, and when the identifier of the transaction grows to the value or a message with the identifier of the value is received, the transaction should be cleared actively and the connection should be terminated.

When the active initiator initiates a transaction, if the usage identifier is 0x00000001, the transaction field is 0x010x000x000x 80. When the passive initiator sends a transaction-related message to the active initiator, the most significant bit is flipped and the transaction field is 0x010x000x000x 00.

In a possible implementation manner, the transmission timing of the length field, the source address field, the destination address field and the transaction field is consistent with the arrangement sequence of the length flag bit, the source address flag bit, the destination address flag bit and the transaction flag bit, and the sequence of the flag bits can be adjusted.

It will be appreciated that a message is primarily composed of a source address (which may also be referred to as a source device address, a sending device address), a destination address (which may also be referred to as a destination device address), transaction related messages, message type, message content, etc. The domain network layer is used for processing and distributing the data received from the security transmission layer, and forwarding the data message to other equipment or delivering the data message to the model control layer of the equipment for processing. The device address is a 32-bit number and is the identity of the device, and the device address 0(0x00000000) indicates no identity or no identity. The sending source refers to the first device that sends a message, and the sending destination (which may also be referred to as a destination device) refers to the device that ultimately receives and processes the message. A transaction refers to this process of completely handling one thing, such as "entire read process of reading a certain state of a device", "entire process of changing a certain state of a device to another state", "entire listen process of listening for a change in a certain state value of a device", "entire send process of sending a file to a device", and so on.

The domain network layer message is allowed to be spliced in the transmission process, and according to the type of a lower layer protocol, the following two splicing conditions are adopted: the lower Layer is a streaming data transmission protocol (such as TLS (Transport Layer Security) which can not distinguish message boundaries), and domain network Layer messages are directly spliced by the lower Layer; the lower layer is the datagram transport protocol (e.g. DTLS, BLE, UDP) that can distinguish message boundaries, and the domain network layer messages allow splicing but not crossing datagram boundaries, when there may be multiple domain network layer messages within one total datagram. In a possible implementation, the sender and receiver of multiple messages within the same overall datagram may be identical.

According to the embodiment of the application, the data message can be flexibly and dynamically assembled through the zone bit, network data can be efficiently and flexibly received and transmitted, and the data message can be dynamically expanded to various service scenes for use. The data message defines the sending device address and the destination device address of the message, and can realize point-to-point data transceiving and also support data transceiving through intermediate routing.

The method and the device have the advantages that the transaction message is clearly defined, the message can be expanded through flexible definition of the message type, and the flexibility of message expression is greatly improved.

In the exemplary embodiment, as shown in fig. 4, the data packet further includes a first extension option field 41 and a payload 42 corresponding to the first extension option field 41.

In a possible implementation, the first extension option field 41 comprises 1 byte and the payload 42 comprises 4 bytes.

In a possible implementation, the data format of the payload 42 is a serialized structure data format.

Illustratively, the data format of the payload is protocol buffer (google protocol buffer). Payload can be expressed as Payload, Payload uses protobuf to carry out data expression, makes the content expression efficiency of data message higher, combines the flag bit to carry out dynamic equipment to the message in a flexible way to and use binary format to define data message, and this application embodiment can be unified transmission on data channel of various bandwidths such as wifi, BLE (Bluetooth Low Energy, Low power consumption), the use of data message is more flexible.

In a possible implementation manner, the payload 42 includes an extension field 411 corresponding to the first extension option field 41, a second extension option field 43, and an extension field 431 corresponding to the second extension option field 43.

In a possible implementation manner, the second extension option field includes 1 byte, the extension field corresponding to the second extension option field includes 2 bytes, and the extension field corresponding to the first extension option field includes 1 byte.

In a possible implementation manner, the first extension option field is represented as Type, Payload is extension content, the Type indicates a Payload Type, and the message is extended by the Type. The second extension option field is denoted as next type. The embodiment of the application carries out message extension through the field content of Type. After the content is extended, the payload of another extended or higher layer message is followed, thereby enabling flexible message extension.

In a possible implementation manner, a write attribute value message of Transaction Timeout (operation Transaction Timeout) may be added to the data message, where the field content of the first extension Option field is 0x80, the field content of the extension field corresponding to the first extension Option field is 10, the field content of the second extension Option field is 7, the field content of the extension field corresponding to the second extension Option field is propelesewritereq, and the propelesewritereq is a protocol attribute.

In a possible implementation, the first byte of the payload is the second extension option field, the second byte is the extension field corresponding to the first extension option field, and the third and fourth bytes are the extension fields corresponding to the second extension option field.

Through message extension, service extension can be flexibly performed, and the embodiment of the application is particularly suitable for communication of an IoT scene.

In an exemplary embodiment, as shown in fig. 5, the data packet further includes a version number field 51, where the version number field 51 is used to indicate the current version of the data packet.

Illustratively, the Version number field may be expressed as Ver (Version), and the Version number fields corresponding to different versions are different, that is, the field contents of the Version number fields corresponding to different versions are different.

In a possible implementation manner, Ver adopts a large-end bit sequence, and the version number field includes 2 bits, for example, 00 is used to indicate that the current version of the data packet is the first version, 01 is used to indicate that the current version of the data packet is the second version, 10 is used to indicate that the current version of the data packet is the third version, and 11 is used to indicate that the current version of the data packet is the fourth version. When the current version is upgraded, the fields in the data message can be redefined and expanded into a new data message.

Of course, in a possible implementation manner, the version number field may further include 3 bits or even more bits, which is not limited in this application.

In the illustrative embodiment, as shown in fig. 5, the data packet further includes a protocol extension field 52, and the protocol extension field 52 is used to indicate an extension function associated with the data packet.

The protocol extension field may include 2 bits. For example, when the protocol extension field is 01, it indicates that the data in Payload is encrypted by AES (Advanced Encryption Standard).

The message header may include a version number field, a protocol extension field, a flag bit, a first extension option field. Of course, in a possible implementation, the message header may also include a length field, a source address field, a destination address field, and a transaction field.

Referring to fig. 6, a flowchart of a data packet processing method provided by an embodiment of the present application is shown, where the method may be performed by a second device or a third device, and the method may include the following sub-steps:

step 601, receiving a data message.

Step 602, reading n flag bits included in the data packet.

The ith flag bit of the n flag bits is used for indicating whether the data message contains a field corresponding to the ith flag bit of predefined n fields, and n is a positive integer.

The n flag bits correspond to the n fields one by one, and different fields correspond to different flag bits. In a possible implementation manner, whether a field corresponding to the flag bit is contained in the data message is determined by the value of the flag bit. The flag bit may be represented by 1 bit, for example, the value of the flag bit may be 0 or 1, and when the value of the flag bit is 0, it indicates that the data packet does not include a field corresponding to the flag bit; when the value of the flag bit is 1, it indicates that the data packet includes a field corresponding to the flag bit. Of course, in other possible implementations, the value of the flag bit may also be other values, which is not limited in this embodiment of the application.

Step 603, analyzing m fields included in the data message based on the n flag bits, wherein m is a positive integer less than or equal to n.

And the flag bit corresponding to the m fields is used for indicating that the data message contains the m fields. Illustratively, the second device or the third device resolves a field corresponding to a flag bit having a value of 1.

Of course, in a possible implementation manner, the second device may only parse part of the fields included in the data packet as needed, and not necessarily parse all the fields included in the data packet.

In an exemplary embodiment, the n flag bits include at least one of:

and the length flag bit is used for indicating whether the data message contains a length field or not, and the length field is used for indicating the length of the data message.

And the destination address flag bit is used for indicating whether a data message contains a destination address field, and the destination address field is used for indicating the destination equipment address of the data message.

And the source address flag bit is used for indicating whether the data message contains a source address field or not, and the source address field is used for indicating the address of the sending equipment of the data message.

And the transaction flag bit is used for indicating whether a transaction field is contained in the data message or not, and the transaction field is used for indicating the transaction and tracking the processing process of the transaction.

In an exemplary embodiment, a receiving device (which may also be referred to as a data packet processing device) needs to determine whether a data packet is a data packet to be forwarded, that is, the receiving device needs to determine whether the receiving device is a second device or a third device, and when the receiving device determines that the data packet is the data packet to be forwarded, the receiving device is the second device; and when the receiving equipment determines that the data message is not the data message to be forwarded, the receiving equipment is third equipment.

If the data message is a data message to be forwarded, the flag bit comprises a source address flag bit, and the source address flag bit is used for indicating that the data message does not contain a source address field, the sending equipment address of the data message is determined as the field content of the source address field and is added into the data message.

The point-to-point data receiving and sending can be realized through the source address field and the destination address field, the message routing forwarding can also be realized, and the message forwarding can be carried out through the network bridge. The forwarding process of the second device is as follows: 1. determining the field content of a destination address field from the data message; 2. checking whether the destination device addresses corresponding to the field contents of the destination address field can be directly connected; 3. if the destination device address can be directly communicated, forwarding the data message to a third device; 4. if the destination equipment address can not be directly connected, refusing to forward; 5. if the source address flag bit included in the data message is used to indicate that the data message does not include a source address field, the second device needs to rewrite a message header (i.e., a header of the data message), and determines the sending device address of the data message as the field content of the source address field to be added to the data message; 6. and sending the adjusted data message to the third device.

In a possible implementation, the message forwarding is performed at most once. Message forwarding has the following provisions: the second device must be able to communicate directly with the third device and not be able to forward the message to another second device. The second device cannot forward the message back onto the original connection of the message.

In a possible implementation manner, the receiving device determines whether the data packet is a data packet to be forwarded by:

1. determining whether the data message contains the address of the destination device; if the data message contains the address of the destination device, executing the following step 2; if the data packet does not contain the destination device address, the following step 3 is performed.

2. Comparing the destination device address with the receiving device address; if the destination device address is the same as the receiving device address, executing the following step 3; if the destination device address is different from the receiving device address, the following step 4 is performed.

The receiving device address refers to an address of the current receiving device, that is, an address of the device that currently receives the data packet. The destination device address is the address of the device that ultimately receives the data message.

3. And determining that the data message is not a data message to be forwarded.

4. And determining that the data message is a data message to be forwarded.

After receiving the data message, the receiving device reads the destination address flag bit, and if the value of the destination address flag bit is 0, the receiving device indicates that the data message is not the data message to be forwarded; if the value of the destination address flag bit is 1, the receiving device compares the destination device address with the receiving device address. If the destination equipment address is consistent with the receiving equipment address, the data message is not a data message to be forwarded, and the receiving equipment is third equipment; and if the address of the destination equipment is not consistent with the address of the receiving equipment, the data message is a data message to be forwarded, and the receiving equipment is second equipment.

In an exemplary embodiment, the data message further includes a first extension option field and a payload corresponding to the first extension option field.

It is understood that the first extension option field may be denoted as Type. Illustratively, the transaction message is processed as follows: 1. determining whether the Type is a reserved value (the reserved value refers to a value in a model control layer); if the Type is a reserved value, ignoring the message and ending the processing process; if the Type is not a reserved value, the following flow is continued. 2. And searching an ongoing transaction list on the current connection according to the transaction field. If the existing transaction (including the active mark or the passive mark) can be matched, the transaction is distributed to the existing transaction for processing, and the processing process is finished; if the corresponding transaction cannot be found, the following process is continued. 3. Judging an active transaction or a passive transaction according to the transaction field, and for the passive transaction, responding to an error (code is not existed in the thread), and ending the processing process; for active transactions, the flow continues. 4. Judging whether the transaction field is marked as ended or not, if the transaction field is marked as ended, responding (code is EFINISHED (Error Finished), and finishing the processing process); if the transaction is not marked as finished, the following flow continues. 5. The message is handed to the model control layer for processing.

Non-transactional message processing may be used for bluetooth Beacon and the like broadcast messages.

In an exemplary embodiment, the data format of the payload is a serialized structure data format.

In an exemplary embodiment, the payload includes an extension field corresponding to the first extension option field, a second extension option field, and an extension field corresponding to the second extension option field.

In an exemplary embodiment, the data packet further includes a version number field for indicating the current version of the data packet.

In an exemplary embodiment, the data packet further includes a protocol extension field for indicating an extension function associated with the data packet.

For the description of the data message, reference may be made to the above embodiments, which are not described herein again.

It should be noted that the sending device in the embodiment of the present application may also be referred to as a sender or a sender; the receiving device in the embodiments of the present application may also be referred to as a receiving party or a recipient. Therefore, the sending device address may also be referred to as a sender address or a sender address, and the receiving device address may also be referred to as a receiver address or a receiver address, which is not limited in this embodiment of the present application.

The embodiments of the present application will be described below with reference to several application scenarios.

Scene 1: the control device (first device) writes attributes (for example, lights) to the child device (third device) under the TCP channel, and since the control device needs to transfer the control of the child device through the gateway (second device), the data packet needs to include a source address field and a destination address field, and the format of the data packet is as shown in fig. 7. The field content of the first extension option field is 0x07, and the field content of the payload is Set Properties Request msg (Set Properties Request message).

Scene 2: the control device (first device) writes an Attribute (e.g., lights) to the child device (third device) in bluetooth GATT (Generic Attribute Profile) or UDP channel, and the data packet does not need to include a length field, and the format of the data packet is as shown in fig. 8. The field content of the first extension option field is 0x07, and the field content of the payload is Set Properties Request msg (Set Properties Request message).

Scene 3: the control device (first device) points to the point-to-point operation on the sub-device (third device) write attribute (e.g., lights up) under the bluetooth GATT or UDP channel, and the data packet does not need to include the length field, the source address field, and the destination address field, and the format of the data packet is as shown in fig. 9. The field content of the first extension option field is 0x07, and the field content of the payload is Set Properties Request msg (Set Properties Request message).

Scene 4: the cloud (first device) issues a notification, such as a notification of replacing a home, to the child device (third device) through the UDP channel, at this time, the data packet does not need to include a length field, a source address field, a destination address field, and a transaction field, and the format of the data packet is as shown in fig. 10. The field content of the first extension option field is 0x38, and the field content of the payload is Home Change Notify msg (Change Home notification).

In an exemplary embodiment, an embodiment of the present application further provides a data packet for inter-device transmission, where the data packet is used to load information during data transmission between devices, where the data packet includes m fields of predefined n fields, n is a positive integer, and m is a positive integer less than or equal to n.

The data message also comprises n flag bits, wherein the ith flag bit in the n flag bits is used for indicating whether the data message contains a field corresponding to the ith flag bit in the n fields.

With combined reference to fig. 3 to 5, in a possible implementation, the n flag bits include at least one of: the length flag bit is used for indicating whether the data message contains a length field or not, and the length field is used for indicating the length of the data message; the destination address flag bit is used for indicating whether a data message contains a destination address field, and the destination address field is used for indicating the destination equipment address of the data message; a source address flag bit for indicating whether the data message contains a source address field, wherein the source address field is used for indicating the address of the sending equipment of the data message; and the transaction flag bit is used for indicating whether a transaction field is contained in the data message or not, and the transaction field is used for indicating the transaction and tracking the processing process of the transaction.

In a possible implementation manner, the data packet further includes a first extension option field and a payload corresponding to the first extension option field.

In a possible implementation, the data packet further includes a protocol extension field, and the protocol extension field is used for indicating an extension function related to the data packet. In a possible implementation, the data format of the payload is a serialized structured data format.

In a possible implementation manner, the payload includes an extension field corresponding to the first extension option field, a second extension option field, and an extension field corresponding to the second extension option field.

In a possible implementation manner, the data packet further includes a version number field, and the version number field is used for indicating the current version of the data packet.

It should be noted that, in a possible implementation manner, the data packet may simultaneously include n flag bits, a first extension option field, a payload corresponding to the first extension option field, and a protocol extension field. Of course, the data message may include some or all of the above fields according to the needs of the actual application.

For the description of the related data message, reference may be made to the above embodiments, which are not described herein again.

The following are embodiments of the apparatus of the present application that may be used to perform embodiments of the method of the present application. For details which are not disclosed in the embodiments of the apparatus of the present application, reference is made to the embodiments of the method of the present application.

Referring to fig. 11, a block diagram of a data packet sending apparatus according to an embodiment of the present application is shown, where the apparatus has a function of implementing the above method example, and the function may be implemented by hardware, or by hardware executing corresponding software. The apparatus 1100 may include: a field determination module 1110, a message generation module 1120, and a message sending module 1130.

A field determining module 1110, configured to determine m fields included in a data packet from predefined n fields, where n is a positive integer, and m is a positive integer less than or equal to n;

a packet generating module 1120, configured to generate the data packet including the m fields; the data message further includes n flag bits, and an ith flag bit of the n flag bits is used to indicate whether the data message includes a field corresponding to the ith flag bit of the n fields;

a message sending module 1130, configured to send the data message.

In an exemplary embodiment, the n flag bits include at least one of:

a length flag bit, configured to indicate whether the data packet includes a length field, where the length field is used to indicate a length of the data packet;

a destination address flag bit, configured to indicate whether the data packet includes a destination address field, where the destination address field is used to indicate a destination device address of the data packet;

a source address flag bit, configured to indicate whether the data packet includes a source address field, where the source address field is used to indicate a sending device address of the data packet;

and the transaction flag bit is used for indicating whether a transaction field is contained in the data message or not, and the transaction field is used for indicating a transaction and tracking the processing process of the transaction.

In an exemplary embodiment, the transaction field includes 32 bits, a lower 31 of the 32 bits being used to represent an identification of the transaction, and a highest order bit of the 32 bits being used to represent an operator type of the transaction.

In an exemplary embodiment, the data packet further includes a first extension option field and a payload corresponding to the first extension option field.

Referring to fig. 12, a block diagram of a data packet processing apparatus according to an embodiment of the present application is shown, where the apparatus has a function of implementing the above method example, and the function may be implemented by hardware or by hardware executing corresponding software. The apparatus 1200 may include: a message receiving module 1210, a flag bit reading module 1220 and a field analyzing module 1230.

A message receiving module 1210, configured to receive a data message;

a flag bit reading module 1220, configured to read n flag bits included in the data packet; the ith flag bit in the n flag bits is used for indicating whether the data message contains a field corresponding to the ith flag bit in predefined n fields, wherein n is a positive integer;

a field analyzing module 1230, configured to analyze m fields included in the data packet based on the n flag bits, where m is a positive integer less than or equal to n.

In an exemplary embodiment, the n flag bits include at least one of:

In an exemplary embodiment, the apparatus 1200 further includes: a message determination module and a field addition module (not shown in the figure).

The message determining module is used for determining whether the data message is a data message to be forwarded;

the field adding module is configured to determine, if the data packet is the data packet to be forwarded, that the flag bit includes the source address flag bit, and the source address flag bit is used to indicate that the data packet does not include the source address field, to add the field content of the source address field to the data packet, where the sending device address of the data packet is determined to be the field content of the source address field.

In an exemplary embodiment, the packet determining module is configured to:

comparing the destination device address with a receiving device address in response to the destination device address being included in the data message;

if the destination equipment address is the same as the receiving equipment address, determining that the data message is not the data message to be forwarded;

if the destination equipment address is different from the receiving equipment address, determining that the data message is the data message to be forwarded;

and determining that the data message is not the data message to be forwarded in response to the data message not containing the destination device address.

It should be noted that, when the apparatus provided in the foregoing embodiment implements the functions thereof, only the division of the functional modules is illustrated, and in practical applications, the functions may be distributed by different functional modules according to needs, that is, the internal structure of the apparatus may be divided into different functional modules to implement all or part of the functions described above. In addition, the apparatus and method embodiments provided by the above embodiments belong to the same concept, and specific implementation processes thereof are described in the method embodiments for details, which are not described herein again.

Referring to fig. 13, which shows a schematic structural diagram of a data packet sending device 1300 according to an embodiment of the present application, the data packet sending device 1300 may include: a processor 1301, a receiver 1302, a transmitter 1303, a memory 1304, and a bus 1305.

The processor 1301 includes one or more processing cores, and the processor 1301 executes various functional applications and information processing by running software programs and modules.

The receiver 1302 and the transmitter 1303 may be implemented as one communication component, which may be a piece of communication chip.

The memory 1304 is coupled to the processor 1301 via a bus 1305.

The memory 1304 may be used to store a computer program that the processor 1301 uses to execute in order to implement the steps performed by the data messaging device in the above-described method embodiments.

Further, the memory 1304 may be implemented by any type or combination of volatile or non-volatile storage devices, including, but not limited to: magnetic or optical disks, Electrically Erasable Programmable Read-Only memories (EEPROMs), Erasable Programmable Read-Only memories (EPROMs), Static Random Access Memories (SRAMs), Read-Only memories (ROMs), magnetic memories, flash memories, Programmable Read-Only memories (PROMs).

In an exemplary embodiment, the data messaging device includes a processor, a memory, and a transceiver that may include a receiver for receiving information and a transmitter for transmitting information.

the transceiver is further configured to send the data packet.

In an exemplary embodiment, the n flag bits include at least one of:

Referring to fig. 14, a schematic structural diagram of a data packet processing device 1400 according to an embodiment of the present application is shown, where the data packet processing device 1400 may include: a processor 1401, a receiver 1402, a transmitter 1403, a memory 1404, and a bus 1405.

The processor 1401 includes one or more processing cores, and the processor 1401 executes various functional applications and information processing by running software programs and modules.

Receiver 1402 and transmitter 1403 may be implemented as one communication component, which may be a piece of communication chip.

The memory 1404 is coupled to the processor 1401 by a bus 1405.

The memory 1404 may be used to store computer programs that the processor 1401 is used to execute in order to carry out the various steps performed by the data message processing device in the above-described method embodiments.

Further, memory 1404 may be implemented by any type or combination of volatile or non-volatile storage devices, including, but not limited to: magnetic or optical disks, Electrically Erasable Programmable Read-Only memories (EEPROMs), Erasable Programmable Read-Only memories (EPROMs), Static Random Access Memories (SRAMs), Read-Only memories (ROMs), magnetic memories, flash memories, Programmable Read-Only memories (PROMs).

In an exemplary embodiment, the data message process includes a processor, a memory, and a transceiver, which may include a receiver for receiving information and a transmitter for transmitting information.

The transceiver is used for receiving data messages;

In an exemplary embodiment, the n flag bits include at least one of:

In an exemplary embodiment, the processor is further configured to determine whether the data packet is a data packet to be forwarded;

the processor is further configured to determine, if the data packet is the to-be-forwarded data packet, that the flag bit includes the source address flag bit, and the source address flag bit is used to indicate that the data packet does not include the source address field, to add the field content of the source address field to the data packet, where the sending device address of the data packet is determined to be the field content of the source address field.

In an exemplary embodiment, the processor is further configured to compare the destination device address with a receiving device address in response to the data packet including the destination device address;

the processor is further configured to determine that the data packet is not the to-be-forwarded data packet if the destination device address is the same as the receiving device address;

the processor is further configured to determine that the data packet is the data packet to be forwarded if the destination device address is different from the receiving device address;

the processor is further configured to determine that the data packet is not the to-be-forwarded data packet in response to the data packet not including the destination device address.

In an exemplary embodiment, a computer readable storage medium is also provided, in which a computer program is stored, the computer program being loaded and executed by a processor of a data messaging device to implement the steps in the above-described data messaging method embodiments.

In an exemplary embodiment, a computer-readable storage medium is also provided, in which a computer program is stored, which is loaded and executed by a processor of a data message processing device to implement the steps in the above-mentioned data message processing method embodiments.

In an exemplary embodiment, a computer program product is provided that includes computer instructions stored in a computer readable storage medium. The processor of the data messaging device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions to cause the data messaging device to perform the data messaging method provided in the above aspect.

In an exemplary embodiment, a computer program product is provided that includes computer instructions stored in a computer readable storage medium. The processor of the data message processing device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions to cause the data message processing device to execute the data message processing method provided in the above aspect.

It should be understood that reference herein to "and/or" describing an associative relationship of associated objects means that there may be three relationships, e.g., a and/or B, may mean: a exists alone, A and B exist simultaneously, and B exists alone. "plurality" means two or more.

The above description is only exemplary of the present application and should not be taken as limiting the present application, and any modifications, equivalents, improvements and the like that are made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

1. A method for transmitting data messages, the method comprising:

and sending the data message.

2. The method of claim 1, wherein the n flag bits comprise at least one of:

3. The method of claim 2, wherein the transaction field comprises 32 bits, wherein the lower 31 bits of the 32 bits are used to indicate the identity of the transaction, and wherein the most significant bit of the 32 bits is used to indicate the operator type of the transaction.

4. The method of claim 1, wherein the data packet further comprises a first extension option field and a payload corresponding to the first extension option field.

5. The method of claim 4, wherein the data format of the payload is a serialized structured data format.

6. The method of claim 4, wherein an extension field corresponding to the first extension option field, a second extension option field, and an extension field corresponding to the second extension option field are included in the payload.

7. The method according to any of claims 1 to 6, wherein the datagram further comprises a protocol extension field for indicating an extension function associated with the datagram.

8. A method of data message processing, the method comprising:

receiving a data message;

9. The method of claim 8, wherein the n flag bits comprise at least one of:

10. The method of claim 9, wherein the transaction field comprises 32 bits, wherein the lower 31 bits of the 32 bits are used to indicate the identity of the transaction, and wherein the most significant bit of the 32 bits is used to indicate the operator type of the transaction.

11. The method of claim 9, further comprising:

determining whether the data message is a data message to be forwarded;

if the data message is the data message to be forwarded, the flag bit comprises the source address flag bit, and the source address flag bit is used for indicating that the data message does not contain the source address field, the sending equipment address of the data message is determined as the field content of the source address field and is added into the data message.

12. The method of claim 11, wherein the determining whether the data packet is a data packet to be forwarded comprises:

13. The method of claim 8, wherein the data packet further comprises a first extension option field and a payload corresponding to the first extension option field.

14. The method of claim 13, wherein the data format of the payload is a serialized structured data format.

15. The method of claim 13, wherein an extension field corresponding to the first extension option field, a second extension option field, and an extension field corresponding to the second extension option field are included in the payload.

16. The method according to any of claims 8 to 15, wherein the datagram further comprises a protocol extension field for indicating an extension function associated with the datagram.

17. An apparatus for transmitting data messages, the apparatus comprising:

and the message sending module is used for sending the data message.

18. A data message processing apparatus, the apparatus comprising:

the message receiving module is used for receiving a data message;

19. A data message transmission device, characterized in that the device comprises a processor, a memory and a transceiver;

the transceiver is further configured to send the data packet.

20. A data message processing apparatus, characterized in that the apparatus comprises a processor, a memory and a transceiver;

the transceiver is used for receiving data messages;

21. A data message for transmission between devices is characterized in that the data message is used for loading information during data transmission between devices, the data message comprises m fields of predefined n fields, n is a positive integer, and m is a positive integer less than or equal to n;

22. The data message of claim 21, wherein the n flag bits comprise at least one of: the length flag bit is used for indicating whether the data message contains a length field, and the length field is used for indicating the length of the data message; the destination address flag bit is used for indicating whether the data message contains a destination address field, and the destination address field is used for indicating the destination device address of the data message; the source address flag bit is used for indicating whether the data message contains a source address field, and the source address field is used for indicating the address of the sending equipment of the data message; the transaction flag bit is used for indicating whether a transaction field is contained in the data message or not, and the transaction field is used for indicating a transaction and tracking the processing process of the transaction;

and/or the presence of a gas in the gas,

the data message also comprises a first extension option field and a payload corresponding to the first extension option field;

and/or the presence of a gas in the gas,

the data message further comprises a protocol extension field, wherein the protocol extension field is used for indicating an extension function related to the data message;

and/or the presence of a gas in the gas,

the data message further comprises a version number field, and the version number field is used for indicating the current version of the data message.

23. The data message of claim 22,

the data format of the effective load is a serialization structure data format;

and/or the presence of a gas in the gas,

the payload includes an extension field corresponding to the first extension option field, a second extension option field, and an extension field corresponding to the second extension option field.

24. A computer-readable storage medium, in which a computer program is stored, which is loaded and executed by a processor to implement the data messaging method according to any one of claims 1 to 7, or to implement the data message processing method according to any one of claims 8 to 16.