Data processing method and device and electronic equipment

Abstract

The invention provides a data processing method and device and electronic equipment, and can be applied to the technical field of server management. The data processing method comprises the following steps: in response to a plurality of data packets received from a sending end via a target transmission channel, verifying sequence identifiers of the plurality of data packets based on a receiving sequence of the plurality of data packets to obtain a verification result; under the condition that the verification result represents that verification is passed, matching the protocol information of the plurality of data packets with the physical layer protocol information of the receiving end to obtain a matching result; under the condition that the matching result represents that the protocol information of the plurality of data packets is matched with the physical layer protocol information, assembling the plurality of data packets based on respective sequence identifiers of the plurality of data packets to obtain an assembled data packet; and transmitting the assembled data packet to a receiving end.

Description

Technical Field

[0001] The present application relates to the field of server management technology, specifically to the field of data transmission and communication technology, and more specifically to a data processing method, device and electronic device. Background Art

[0002] As solid-state drives (SSDs) based on the Non-Volatile Memory Host Controller Interface Specification (NVMHCI) become mainstream storage due to their low latency, high performance, and low energy consumption, the importance of out-of-band management technology is growing. Out-of-band management, independent of the host operating system, implements low-level control of the device through dedicated hardware modules to support high-value operations such as firmware upgrades, health monitoring, and log collection, ensuring stable operation even in the event of a host failure.

[0003] However, most current related technologies rely on the System Management Bus (SMBUS) channel for out-of-band management verification. Due to the low transmission rate of the SMBUS channel, it cannot cover high-speed out-of-band management scenarios such as large-capacity firmware upgrades and real-time diagnostic log collection. Therefore, it is difficult to meet the high bandwidth requirements of solid-state drives in complex application environments. Summary of the Invention

[0004] In view of the above problems, the present application provides a data processing method, device and electronic device that improve the reliability of out-of-band data management.

[0005] According to the first aspect of the present application, a data processing method is provided, comprising: in response to receiving multiple data packets from a transmitting end via a target transmission channel, verifying the sequence identifiers of the multiple data packets based on the order in which the multiple data packets are received to obtain a verification result; when the verification result indicates that the verification is passed, matching the protocol information of the multiple data packets with the physical layer protocol information of the receiving end to obtain a matching result; when the matching result indicates that the protocol information of the multiple data packets matches the physical layer protocol information, assembling the multiple data packets based on the sequence identifiers of the multiple data packets to obtain an assembled data packet; and transmitting the assembled data packet to the receiving end.

[0006] The second aspect of the present application provides a data processing device, including: a verification module, which is used to respond to receiving multiple data packets from a sending end via a target transmission channel, and based on the reception order of the above multiple data packets, verify the sequence identifiers within the above multiple data packets to obtain a verification result; a matching module, which is used to match the protocol information of the above multiple data packets with the physical layer protocol information of the receiving end to obtain a matching result when the above verification result indicates that the verification is passed; an assembling module, which is used to assemble the above multiple data packets based on the sequence identifiers of the multiple data packets to obtain an assembled data packet when the above matching result indicates that the protocol information of the above multiple data packets matches the above physical layer protocol information; and a transmission module, which is used to transmit the above assembled data packet to the above receiving end.

[0007] The third aspect of the present application provides an electronic device, comprising: one or more processors; a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the above method.

[0008] The fourth aspect of the present application further provides a computer-readable storage medium having a computer program or instructions stored thereon, which implements the steps of the above method when the computer program or instructions are executed by a processor.

[0009] According to an embodiment of the present application, by performing a sequence check on each data packet before assembling the data packets, the integrity of the multiple data packets received is ensured, thereby avoiding message fragmentation caused by data packet loss or disorder during transmission. By performing protocol matching on the data packets that pass the sequence check, data packets with target terminal identification errors or unsupported protocol versions are filtered out to ensure the compatibility of the sending and receiving ends, so that management instructions can be accurately routed to the target device. In addition, for application scenarios with large amounts of data to be transmitted, by performing integrity and compatibility checks on multiple data packets and dynamically assembling them, the data processing efficiency is improved and the reliability of the out-of-band management function is ensured. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The above contents and other objects, features and advantages of the present application will become more apparent through the following description of the embodiments of the present application with reference to the accompanying drawings, in which:

[0011] Figure 1 A diagram schematically illustrates an application scenario of a data processing method, device, and electronic device according to an embodiment of the present application;

[0012] Figure 2 The schematic diagram of the structure of the NVMe-MI protocol is shown schematically;

[0013] Figure 3The following schematically shows a flow chart of a data processing method according to an embodiment of the present application;

[0014] Figure 4 The following schematically shows a flow chart of a data processing method according to a specific embodiment of the present application;

[0015] Figure 5 A block diagram schematically illustrates a structure of a data processing device according to an embodiment of the present application; and

[0016] Figure 6 A block diagram of an electronic device suitable for implementing a data processing method according to an embodiment of the present application is schematically shown. DETAILED DESCRIPTION

[0017] Hereinafter, embodiments of the present application will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the present application. In the detailed description below, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present application. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of known structures and technologies are omitted to avoid unnecessarily confusing the concepts of the present application.

[0018] The terms used herein are only for describing specific embodiments and are not intended to limit this application. The terms "comprise," "include," etc. used herein indicate the presence of the features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0019] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification and should not be interpreted in an idealized or overly rigid manner.

[0020] When expressions such as "at least one of A, B, and C, etc." are used, they should generally be interpreted in accordance with the meaning commonly understood by those skilled in the art (for example, "a system having at least one of A, B, and C" should include but is not limited to a system having A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, C, etc.).

[0021] As solid-state drives (SSDs) based on the Non-Volatile Memory Express (NVMe) host controller interface specification protocol become mainstream storage due to their advantages of low latency, high performance and low energy consumption, the importance of their out-of-band management technology is becoming increasingly prominent.

[0022] Among them, out-of-band management is independent of the host operating system. It implements low-level control of the device through dedicated hardware modules such as the Board Management Controller (BMC), the Non-Volatile Memory express-Management Interface (NVMe-MI) protocol controller based on the Non-Volatile Memory Host Controller Interface Specification Protocol, and physical interfaces such as the System Management Bus (SMBUS) channel and the Peripheral Component Interconnect express-Vendor Defined Message (PCIe VDM) channel based on the Peripheral Component Interconnect high-speed bus to support high-value operations such as firmware upgrades, health monitoring, and log collection, and can still run stably even if the host crashes.

[0023] Among them, the Management Component Transport Protocol (MCTP) is the transport layer core of the NVMe-MI specification, responsible for encapsulating management instructions into MCTP messages and transmitting them to target devices such as NVMe SSDs through SMBUS or PCIe VDM channels.

[0024] Therefore, validating MCTP control messages for SSDs that support the MCTP transport protocol is a critical step in ensuring the reliability of their out-of-band management capabilities. If the host cannot obtain the terminal identifier using the Get EID command, or if the Set EID command fails to correctly assign the terminal ID, management commands issued by the BMC (such as firmware updates and health status polling) will not be accurately routed to the target SSD through the out-of-band transmission channel, subsequently affecting the entire NVMe-MI function.

[0025] However, most current related technologies rely on the SMBUS channel for out-of-band management verification. Due to the low transmission rate of the SMBUS channel, it cannot cover high-speed out-of-band management scenarios such as large-capacity firmware upgrades and real-time diagnostic log collection. Therefore, it is difficult to meet the high bandwidth requirements of NVMe SSDs in complex application environments.

[0026] Based on this, an embodiment of the present application provides a data processing method that performs a sequence check on each data packet before assembling the data packets to ensure the integrity of the multiple data packets received, thereby avoiding message fragmentation caused by data packet loss or disorder during transmission; protocol matching is performed on the data packets that pass the sequence check, and data packets with target terminal identification errors or unsupported protocol versions are filtered out to ensure compatibility between the sending and receiving ends, so that management instructions can be accurately routed to the target device. In addition, for application scenarios with large amounts of data to be transmitted, integrity and compatibility checks are performed on multiple data packets, and they are dynamically assembled to improve data processing efficiency and ensure the reliability of out-of-band management functions.

[0027] Specifically, an embodiment of the present application provides a data processing method, including: in response to receiving multiple data packets from a sending end via a target transmission channel, based on the reception order of the multiple data packets, checking the sequence identifiers of the multiple data packets to obtain a verification result; when the verification result indicates that the verification is passed, matching the protocol information of the multiple data packets with the physical layer protocol information of the receiving end to obtain a matching result; when the matching result indicates that the protocol information of the multiple data packets matches the physical layer protocol information, assembling the multiple data packets based on the respective sequence identifiers of the multiple data packets to obtain an assembled data packet; and transmitting the assembled data packet to the receiving end.

[0028] Figure 1 The application scenario diagram of the data processing method, device and electronic device according to the embodiments of the present application is schematically shown.

[0029] like Figure 1 As shown, an application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 is used as a medium for providing communication links between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables. The network 104 may also dynamically switch transmission protocols, such as TCP / IP, MCTP over PCIe VDM, etc., based on application requirements.

[0030] A user may use a first terminal device 101, a second terminal device 102, or a third terminal device 103 to interact with a server 105 via a network 104 to receive or send messages, etc. Various communication client applications may be installed on the first terminal device 101, the second terminal device 102, or the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (for example only).

[0031] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with display screens and supporting web browsing, including but not limited to smartphones, tablet computers, laptop computers, and desktop computers. The first terminal device 101, the second terminal device 102, and the third terminal device 103 support users initiating data processing requests through a graphical interface or an API interface.

[0032] The server 105 may be a server that provides various services, such as a background management server (for example only) that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103. The background management server may perform background management, protocol parsing, data verification, and other processing on received user requests and other data, and feedback the processing results (e.g., web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0033] For example, the first terminal device 101, the second terminal device 102 or the third terminal device 103 generates a data processing request and sends it to the server 105 via the network 104 such as the target transmission channel; the server 105 identifies the protocol information, sequence identifiers, etc. of multiple data packets to perform a verification operation, reassembles the data packets based on the verification results, and generates an assembled data packet that complies with the receiving end protocol specification; the server 105 transmits the processing result to the terminal device that initiated the request, such as the first terminal device 101, the second terminal device 102 or the third terminal device 103, via the network 104.

[0034] It should be noted that the data processing method provided in the embodiment of the present application can generally be executed by the server 105. Accordingly, the data processing device provided in the embodiment of the present application can generally be set in the server 105. The data processing method provided in the embodiment of the present application can also be executed by a server or server cluster that is different from the server 105 and can communicate with the first terminal device 101, the second terminal device 102, the third terminal device 103 and / or the server 105. Accordingly, the data processing device provided in the embodiment of the present application can also be set in a server or server cluster that is different from the server 105 and can communicate with the first terminal device 101, the second terminal device 102, the third terminal device 103 and / or the server 105.

[0035] It should be understood that Figure 1 The number of terminal devices, networks and servers in the embodiment is merely illustrative. Any number of terminal devices, networks and servers may be provided as required.

[0036] It should be noted that the data processing method, device and electronic equipment provided in this application can be applied to the field of server management technology, specifically to the field of data transmission and communication technology. The data processing method, device and electronic equipment provided in this application can also be used in any field other than the field of data transmission and communication technology, such as storage device management and control technology. The application field of the data processing method, device and electronic equipment provided in this application is not limited.

[0037] For ease of understanding, based on Figure 2 This section provides a unified explanation of the terms used in the NVMe-MI protocol structure. The NVMe-MI protocol uses MCTP to implement reliable and ordered message transmission between the management controller and the management interface. In the MCTP protocol, the smallest unit of data transmission is the MCTP packet. One or more MCTP packets can be assembled into an MCTP message. An MCTP packet always contains at least one byte of payload, but the total length must not exceed the negotiated MCTP transmission unit size.

[0038] Figure 2 The schematic diagram shows the structure of the NVMe-MI protocol.

[0039] like Figure 2 As shown in the figure, the structure of the NVMe-MI protocol includes a physical medium specific header, a physical medium specific trailer, a header version, a destination endpoint ID, a source endpoint ID, a start of message (SOM), an end of message (EOM), a packet sequence number (Pkt Seq#), a tag owner bit (TO), and a message tag (Msg Tag).

[0040] The Physical Medium Specific Header is used to transmit physical addressing and framing information for MCTP packets between devices on a specific physical medium. The size and type of any subfields or data are defined by the corresponding transport binding specification for MCTP messaging on a given medium.

[0041] A physical medium-specific trailer represents any additional media-specific trailer fields required to transmit MCTP packets between devices on a specific physical medium. This trailer is used to hold per-packet data integrity fields specified for the specific medium, such as CRC, checksum, etc.

[0042] The header version identifies the format of the MCTP common fields, physical frame, and data integrity mechanism in the transport message.

[0043] Target terminal ID, indicating the EID of the receiving MCTP, is used to determine the message recipient.

[0044] Source endpoint ID, which indicates the EID of the MCTP sender. It is used to identify the sender for response routing and message tracking.

[0045] The start of message marker SOM indicates the start of a multi-packet message and triggers the initialization of the receiver's reassembly buffer.

[0046] The end-of-message marker EOM marks the end of a multi-packet message and triggers the receiver to process the complete message.

[0047] Packet sequence number, which stands for packet sequence number. For messages that span multiple packets, the packet sequence number is increased modulo 4 on each consecutive packet, allowing the receiver to detect up to three consecutive lost data packets between the start and end of a message.

[0048] The Tag Owner bit identifies whether the message tag was initiated by the endpoint that is the source of the message or the endpoint that is the destination of the message. MCTP message types can override this bit with additional meaning, for example, to distinguish between "request" and "response" messages.

[0049] Message Tag: This field, along with the Source Endpoint ID and Tag Owner fields, uniquely identifies a message at the MCTP transport level. This allows the Source Endpoint ID to concurrently interleave packets from multiple messages to the same destination endpoint, provided each message has a unique message tag.

[0050] The following will be based on Figure 1 The scene described by Figure 3 The data processing method of the embodiment of the present application is described in detail.

[0051] Figure 3 The flowchart of the data processing method according to the embodiment of the present application is schematically shown.

[0052] like Figure 3 As shown, the data processing method of this embodiment includes operations S310 to S340.

[0053] In operation S310, in response to receiving a plurality of data packets from a transmitting end via a target transmission channel, sequence identifiers of the plurality of data packets are verified based on a receiving order of the plurality of data packets to obtain a verification result.

[0054] In operation S320 , if the verification result indicates that the verification is passed, the protocol information of the plurality of data packets is matched with the physical layer protocol information of the receiving end to obtain a matching result.

[0055] In operation S330 , when the matching result indicates that the protocol information of the plurality of data packets matches the physical layer protocol information, the plurality of data packets are assembled based on respective sequence identifiers of the plurality of data packets to obtain an assembled data packet.

[0056] In operation S340 , the assembled data packet is transmitted to a receiving end.

[0057] According to an embodiment of the present application, the sending end may represent the device that initiates out-of-band management instructions, such as the baseboard management controller (BMC) or out-of-band management module in a server, which is responsible for encapsulating NVMe-MI instructions into MCTP packets. The receiving end may represent the target device that receives out-of-band management data, such as an NVMe SSD that supports the MCTP protocol, whose built-in Management Endpoint is responsible for data verification and processing.

[0058] In this embodiment, the target transmission channel may be represented as a physical interface for transmitting out-of-band management data, and may be used to transmit data packets with a data volume greater than a predetermined threshold. For example, the target transmission channel may include a PCIe VDM channel for transmitting large amounts of data.

[0059] In a specific application scenario, such as data transmission based on the MCTP protocol, the data packet received from the sender can be used to represent a segmented data packet of the MCTP protocol, which is used to carry out-of-band management messages, such as NVMe-MI instructions. The segmented data packet of the MCTP protocol can be obtained by dividing a complete out-of-band management message, such as a firmware upgrade, download, or status query instruction, into multiple data segments according to the MCTP protocol specification. Each segmented data packet carries part of the message content and control fields, such as a sequence identifier and protocol information.

[0060] In this embodiment, the sequence identifier may be a field used to identify the position and role of a data packet in a multi-packet message, and may include, for example, a segment identifier, a packet sequence number, etc. The segment identifier may include, for example, a start identifier and an end identifier, and the packet sequence number may include, for example, the sequence number of each data packet.

[0061] In this embodiment, multiple data packets sent by a transmitting end, such as a BMC, are received via a target transmission channel, such as a PCIe VDM. The sequence identifier of each data packet is verified to determine whether it complies with a preset sequence rule, based on the order in which each data packet is received, to obtain a verification result. This verification process can be used to ensure the sequence integrity of the received multiple data packets. The preset sequence rule may include increasing packet sequence numbers, a preset sequence of segment identifiers, and the like.

[0062] In this embodiment, if the sequence identifier of the current data packet meets the sequence preset rule, a verification result indicating that the verification has passed can be obtained. If the sequence identifier of the current data packet does not meet the sequence preset rule, a verification result indicating that the verification has failed can be obtained.

[0063] According to an embodiment of the present application, the protocol information of a data packet may represent fields related to the transmission protocol carried in the data packet. For example, in a specific application scenario such as data transmission based on the MCTP protocol, the protocol information of the data packet may include the MCTP protocol header version, source endpoint ID, destination terminal ID, transmission unit size, etc.

[0064] In this embodiment, the physical layer protocol information may indicate the underlying protocol parameters supported by the receiving end. For example, in a specific application scenario such as data transmission based on the MCTP protocol, the physical layer protocol information may include the MCTP protocol version supported by the solid-state drive, the target terminal ID, the maximum transmission unit size, etc.

[0065] In this embodiment, when the sequence identification verification of multiple data packets is passed, the protocol information carried by each of the multiple data packets is matched with the physical layer protocol information of the receiving end to obtain a matching result to filter out incompatible data packets, such as the header version not supported by the receiving end or the wrong target terminal ID.

[0066] According to an embodiment of the present application, when the protocol information carried by multiple data packets matches the physical layer protocol information of the receiving end, the multiple data packets are assembled according to their respective sequence identifiers to obtain an assembled data packet.

[0067] The assembled data packet may be used to represent a complete data unit formed after integrity verification, protocol matching, and sequential assembly. The complete data unit may be a message carrier conforming to the MCTP protocol format and may carry complete out-of-band management instructions or data, such as firmware upgrade messages and health query messages. The firmware upgrade message may include firmware image data and activation instructions, etc.

[0068] According to an embodiment of the present application, the assembled data packet obtained after assembly is transmitted to a receiving end to trigger an instruction corresponding to the assembled data.

[0069] Based on this, the embodiment of the present application performs a sequence check on each data packet before assembling the data packets to ensure the integrity of the multiple data packets received, thereby avoiding message fragmentation caused by data packet loss and disorder during transmission. Protocol matching is performed on the data packets that pass the sequence check, and data packets with target terminal identification errors or unsupported protocol versions are filtered to ensure the compatibility of the sending and receiving ends, so that management instructions can be accurately routed to the target device. In addition, for application scenarios with large amounts of data transmitted, integrity and compatibility checks are performed on multiple data packets, and they are dynamically assembled to improve data processing efficiency and ensure the reliability of out-of-band management functions.

[0070] According to an embodiment of the present application, multiple data packets are assembled based on their respective sequence identifiers to obtain an assembled data packet, including: upon detecting that the first data packet received sequentially carries a start identifier and the Kth data packet carries an end identifier, obtaining an assembled data packet based on the first to Kth data packets.

[0071] According to an embodiment of the present application, the sequence identifier includes a start identifier and an end identifier. Specifically, in a specific application scenario such as data transmission based on the MCTP protocol, the start identifier and the end identifier can both serve as segment identifiers in the MCTP protocol. The start identifier may include a start-of-message identifier (SOM), which indicates the beginning of a message. The end identifier may include an end-of-message identifier (EOM), which indicates the end of a message.

[0072] In this embodiment, K represents the total number of message segments, and K is a positive integer. For example, K=1 represents a single-packet message, and K>1 represents a message that is segmented into multiple data packets, i.e., a multi-packet message.

[0073] In a specific embodiment, if the data packet is the first data packet of a multi-packet message, its segmentation flag bits may be configured as SOM=1b and EOM=0b to indicate the start of the message. If the data packet is the last data packet of a multi-packet message, its segmentation flag bits may be configured as SOM=0b and EOM=1b to indicate the end of the message. In another specific embodiment, if the data packet is the data packet of a single-packet message, its segmentation flag bits may be configured as SOM=1b and EOM=1b.

[0074] According to an embodiment of the present application, when executing message assembly, it can include checking the sequence identifier carried by each data packet to determine the current message assembly process.

[0075] Specifically, when performing message assembly, if any data packet is detected to carry a start identifier, it can be used as the first data packet. In this case, if the Kth data packet after the first data packet is detected to carry an end identifier, the first to Kth data packets can be assembled into a complete message.

[0076] For example, when multiple data packets are transmitted for firmware upgrade, if the segment identification bits of the second data packet received are identified as SOM=1b, EOM=0b, then it is used as the first data packet, i.e., the start data packet. Then, if the segment identification bits of the fifth data packet received are identified as SOM=0b, EOM=1b, then the fifth data packet is used as the Kth data packet, i.e., the end data packet. In this case, the second to fifth data packets can be assembled to obtain an assembled data packet.

[0077] Based on this, during the assembly process, the embodiments of the present application identify the start and end identifiers to clarify the starting and ending positions of multi-packet messages, ensure that only data packet sequences belonging to the same message are assembled, and avoid data packets of different messages from being incorrectly spliced.

[0078] According to an embodiment of the present application, obtaining an assembled data packet based on the first to K-th data packets includes: in response to detecting that the received k+1-th data packet carries a start identifier, discarding the first to k-th data packets; in response to detecting that the received K-th data packet carries an end identifier, assembling the k+1-th data packet to the K-th data packet to obtain an assembled data packet.

[0079] According to an embodiment of the present application, k represents the number of data packets received in the current assembly process, where k>1 and k <K-1。

[0080] In this embodiment, when assembling the first data packet to the k-th data packet, the received k+1-th data packet carries a new start identifier. For example, the start identifier of the k+1-th data packet is SOM=1b, which means that a new start packet is received when executing message assembly. At this time, the ongoing message assembly process will be terminated, and the received first data packet to the k-th data packet will be discarded to avoid mixed assembly of new and old messages.

[0081] In this embodiment, the newly received k+1th data packet is used as a new starting packet, and data packets continue to be received after the k+1th data packet until it is detected that the received Kth data packet carries an end identifier, then the assembly of the k+1th data packet to the Kth data packet is restarted to obtain an assembled data packet.

[0082] Based on this, in the embodiment of the present application, if a new start data packet is received during the assembly process, the mixed assembly of new and old messages is avoided by discarding the incomplete data packet that has been received, thereby ensuring the accuracy and completeness of the final assembled data packet.

[0083] According to an embodiment of the present application, in response to detecting that the received K-th data packet carries an end identifier, assembling the k+1-th data packet to the K-th data packet to obtain an assembled data packet, including: sequentially identifying the sequence identifiers in the k+1-th to K-th data packets; when the sequence identifiers match the receiving order of the k+1-th to K-th data packets, assembling the k+1-th to K-th data packets to obtain an assembled data packet.

[0084] According to an embodiment of the present application, when it is detected that the received k+1th data packet carries a start identifier and the received Kth data packet carries an end identifier, the sequence identifiers of the k+1th data packet to the Kth data packet are extracted in sequence. Only when the sequence identifiers of the k+1th data packet to the Kth data packet match the received sequence, assembly is performed to obtain an assembled data packet. If the sequence identifier of any data packet from the k+1th data packet to the Kth data packet does not match the received sequence, the k+1th data packet to the Kth data packet are discarded.

[0085] In one embodiment, the sequence identifier further includes a packet sequence number (Pkt Seq#).

[0086] Specifically, if the packet sequence numbers of the k+1th to the kth packets are arranged consecutively according to a pre-set sequence rule, it can be said that the sequence identifier matches the received order. The pre-set sequence rule, for example, requires that the packet sequence numbers be incremented modulo 4 without skipping or repeating numbers, to ensure the order and integrity of multi-packet messages.

[0087] For example, in a specific application scenario using the MCTP protocol for data transmission, the packet sequence number of the k+2th packet is the sum of the packet sequence number of the k+1th packet and the remainder of 1 divided by 4. The packet sequence number (Pkt Seq#) is a two-bit binary number with a value range of 0, 1, 2, and 3. The starting packet sequence number is usually 0, and the sequence number of each subsequent packet is the previous packet sequence number plus 1. If the number exceeds 3, it will re-start at 0.

[0088] In another embodiment, the sequence identifier further includes an intermediate identifier. The intermediate identifier can also serve as a segment identifier in the MCTP protocol. If the data packet is an intermediate packet in a multi-packet message, its segment identifier can be configured as SOM=0b and EOM=0b.

[0089] In this embodiment, if the k+1th data packet to the Kth data packet include a complete start packet, a middle packet, and an end packet, and are received in the sequence order, it can be said that the sequence identifier matches the receiving order, and the k+1th data packet to the Kth data packet can be assembled.

[0090] For example, if the segment identification bits of the received 5th data packet are identified as SOM=1b, EOM=0b, then it is used as the start packet. Then, if the segment identification bits of the received 6th to 9th data packets are identified as SOM=0b, EOM=0b, then the 6th to 9th data packets are all used as intermediate packets. If the segment identification bits of the received 10th data packet are further identified as SOM=0b, EOM=1b, then the 10th data packet is used as the end packet. In this case, the 5th to 10th data packets can be assembled to obtain an assembled data packet.

[0091] Based on this, the embodiments of the present application accurately detect data packet disorder during transmission through sequence continuity verification, ensure that multi-packet messages are assembled in the order intended by the sender, and avoid message parsing errors caused by data misalignment.

[0092] According to an embodiment of the present application, the data processing method also includes: in response to detecting that the received K-th data packet carries an end identifier, identifying the functional type identifier of the K-th data packet; when the functional type identifier matches any functional type of the receiving end, assembling the k+1-th data packet to the K-th data packet to obtain an assembled data packet.

[0093] According to an embodiment of the present application, the function type identifier of a data packet can be used to identify the specific function of the message corresponding to the data packet. For example, in the NVMe-MI protocol, the function type identifier can be a field in the MCTP protocol message payload, such as 0x01 for log collection, 0x02 for firmware image transmission, and 0x03 for firmware activation.

[0094] In this embodiment, the function type of the receiving end may represent a set of function types of messages that can be processed by the receiving end, which is predefined. The message type of the receiving end may be determined by hardware or firmware configuration.

[0095] In this embodiment, when the received Kth data packet is detected as a termination packet, the function type identifier of the data packet is identified and obtained. If the function type identifier of the data packet matches any type in the function type set of the receiving end, message assembly can be performed on the k+1th to Kth data packets to obtain assembled data packets. If the function type identifier of the data packet does not match any type in the function type set of the receiving end, it indicates that the receiving end does not support the function type, and the k+1th to Kth data packets can be discarded.

[0096] In another embodiment, when it is detected that the received k+1th data packet is an intermediate packet, the function type identifier of the data packet is identified. If the function type identifier of the data packet matches any type in the function type set of the receiving end, identification of the k+2th data packet can be continued. If the function type identifier of the data packet does not match any type in the function type set of the receiving end, it indicates that the receiving end does not support the function type, and the message assembly process can be terminated and the k+1th data packet can be discarded.

[0097] In another embodiment, when the received k+1th data packet is detected as a start packet, the function type identifier of the data packet is identified. If the function type identifier of the data packet matches any type in the function type set of the receiving end, identification of the k+2th data packet can be continued. If the function type identifier of the data packet does not match any type in the function type set of the receiving end, it indicates that the receiving end does not support the function type, and the message assembly can be rejected and the k+1th data packet can be discarded.

[0098] Based on this, during the assembly process of the data packet, the embodiment of the present application verifies whether the function type identifier carried by the data packet matches the function supported by the receiving end, rejects the functions that the receiving end cannot handle, and avoids operation failure or device abnormality due to function incompatibility.

[0099] According to an embodiment of the present application, the data processing method further includes: assembling the multiple data packets based on the transmission duration and preset waiting duration of each of the multiple data packets to obtain an assembled data packet.

[0100] In this embodiment, when executing message assembly, the transmission duration of each data packet may be verified to determine the current message assembly process. Specifically, after receiving the first data packet, in response to detecting that the transmission duration of the received K data packets does not exceed the preset waiting duration, the first to K-th data packets are assembled to obtain an assembled data packet. If, in response to detecting that the transmission duration of the k-th data packet exceeds the preset waiting duration, it is determined that the waiting data packet has timed out. In this case, the current message assembly process is terminated, the k-th data packet is discarded, and an error log is recorded, where the log content includes but is not limited to the timeout duration, information related to the received data packets, etc.

[0101] Based on this, the embodiments of the present application verify the transmission duration of the data packet to avoid indefinite waiting due to situations such as data packet transmission delay or loss, thereby improving system efficiency and response speed.

[0102] According to an embodiment of the present application, the data processing method further includes: assembling the multiple data packets based on the sequence identifiers and valid data volumes of the multiple data packets to obtain assembled data packets.

[0103] In this embodiment, the effective data volume can be used to represent the transmission unit size corresponding to the data packet, that is, the length of the effective data actually carried by each data packet. The effective data does not include the data portion of the protocol control information such as the packet header and tail.

[0104] In this embodiment, when executing message assembly, the effective data amount of multiple data packets may be checked to determine the current message assembly process.

[0105] In a specific embodiment, when verifying the effective data volume of multiple data packets, for multiple intermediate data packets carrying intermediate identifiers, it is verified whether the effective data volume carried by each of the multiple intermediate data packets is consistent. If the verification results indicate consistency, the multiple data packets are assembled to obtain an assembled data packet.

[0106] For example, in response to receiving a start data packet carrying a start identifier, an end data packet carrying an end identifier, and m intermediate data packets with intermediate identifiers received between the start data packet and the end data packet, the effective data amounts carried by each of the m intermediate data packets are checked to see if they are consistent. If the effective data amounts carried by each of the m intermediate data packets are consistent, the start data packet, the m intermediate data packets, and the end data packet are message assembled to obtain an assembled data packet. If the effective data amount carried by any of the m intermediate data packets is inconsistent with the effective data amount carried by the other intermediate data packets, the current message assembly process is terminated and the data packet currently being message assembled is discarded, where m is a positive integer.

[0107] In another specific embodiment, when verifying the effective data volume of multiple data packets, for an end data packet carrying an end identifier, the effective data volume of the end data packet is verified to determine whether the effective data volume carried by the effective data volume of the end data packet is less than or equal to the effective data volume carried by the start data packet and the intermediate data packets. If the verification result indicates that the verification passes, the multiple data packets are assembled to obtain an assembled data packet. If the verification result indicates that the effective data volume carried by the effective data volume of the end data packet is greater than the effective data volume carried by the start data packet and / or any of the intermediate data packets, the current message assembly process is terminated and the data packet currently being assembled is discarded.

[0108] Based on this, during the packet assembly process, embodiments of the present application verify the valid data volume of intermediate packets to ensure that message segmentation complies with protocol specifications such as MCTP, thereby avoiding assembly misalignment or parsing errors caused by inconsistent segment sizes. If a valid data mismatch is detected during the verification, assembly is immediately terminated and the abnormal packet is discarded, preventing invalid data from occupying computing and storage resources and quickly freeing up buffer space for subsequent message processing.

[0109] According to an embodiment of the present application, the data processing method further includes: assembling the multiple data packets based on their respective sequence identifiers, valid data volumes, and preset data volumes to obtain assembled data packets.

[0110] In this embodiment, the preset data volume can be used to represent the standard transmission unit size determined by the communicating parties, i.e., the receiving end and the sending end, through a protocol such as the MCTP protocol before transmitting data.

[0111] In this embodiment, when executing message assembly, the effective data volume of each data packet can be verified. For data packets carrying a start identifier or an intermediate identifier, the effective data volume of the data packet is matched with the preset data volume, and the current message assembly process is determined based on the matching result.

[0112] Specifically, in response to receiving the start identifier or intermediate identifier carried by the kth data packet, it is determined whether the amount of valid data carried in the kth data packet matches the preset data amount. If the amount of valid data carried in the kth data packet matches the preset data amount, it indicates that the verification of the amount of valid data carried by the kth data packet has passed.

[0113] Based on this, the embodiments of the present application ensure that the intermediate segment size of the multi-packet message meets the negotiated standard by matching the effective data volume of the data packet carrying the start or intermediate identifier with the preset data volume during the data packet assembly process, avoiding assembly dislocation or parsing failure caused by inconsistent segment sizes, and ensuring the standardization and consistency of message segment transmission; when the verification finds that the effective data volume does not match the preset value, the abnormal assembly process is immediately terminated and invalid data packets are filtered to prevent incomplete or erroneous data from entering the subsequent processing flow, significantly improving the integrity and reliability of message assembly, and providing key guarantees for the accurate execution of out-of-band management instructions and the safe operation of equipment.

[0114] According to an embodiment of the present application, based on the reception order of multiple data packets, the sequence identifiers within the multiple data packets are checked to obtain a verification result, including: when the sequence identifier within any data packet among the multiple data packets matches the reception order of any data packet, a verification result indicating that the verification has passed is obtained.

[0115] According to an embodiment of the present application, based on the reception order of multiple data packets, the sequence identifiers within the multiple data packets are checked, and the verification result obtained also includes: when the verification result indicates that the sequence identifier within any data packet does not match the reception order of any data packet, or the matching result indicates that the protocol information of any data packet does not match the physical layer protocol information, a matching result indicating that the match fails is obtained, and any data packet is discarded.

[0116] According to an embodiment of the present application, before assembling the data packets, the sequence identifiers carried in each of the received multiple data packets may be verified to ensure the integrity of the multiple data packets.

[0117] Specifically, in response to previously receiving an intermediate data packet carrying an intermediate identifier, or in response to previously receiving an end data packet carrying an end identifier, but not receiving a start data packet carrying a start identifier, it means that the sequence identifier in a certain data packet does not match the receiving order, that is, the check fails, indicating that the intermediate data packet and the end data packet are unexpected data packets, and the intermediate data packet and the end data packet are discarded.

[0118] Since the start packet can indicate the starting boundary of a message or assembled packet and define the header version, mark owner bit, etc., if the start packet is missing in the reception of the packet, the subsequent packets cannot be correctly parsed.

[0119] Therefore, only in response to first receiving a start data packet carrying a start identifier such as SOM=0 and EOM=0, then receiving an intermediate data packet carrying an intermediate identifier such as SOM=0 and EOM=1, and finally receiving an end data packet carrying an end identifier such as SOM=1 and EOM=0, it means that the sequence identifiers in multiple data packets all match the acceptance order, that is, the verification is passed.

[0120] According to another embodiment of the present application, before assembling the data packets, the protocol information carried in each of the received multiple data packets may be verified to ensure the physical layer compliance and protocol compatibility of the data packets.

[0121] The protocol information carried in the data packet may include data link information, target endpoint ID, and header version.

[0122] In a specific embodiment, data packets may be damaged during physical layer transmission due to physical medium problems or signal interference. Therefore, when verifying the data link information carried by each of the multiple received data packets, if the cyclic redundancy check code (CRC) at the end of any data packet does not match the calculated value, it means that the data packet has been tampered with or damaged during transmission, or the segmentation identifiers in the data packet, such as the start identifier or end identifier, do not meet the frame format requirements included in the physical layer, or the data packet length is not padded according to the byte alignment specified by the physical layer protocol, or the data packet length exceeds the transmission unit size negotiated with the receiving end physical layer. If any of the above error types are met, it means that the protocol information of the data packet does not match the physical layer protocol information, indicating that the verification has failed. In this case, the unmatched data packet is directly discarded.

[0123] In another specific embodiment, the target endpoint ID is a unique address used to identify a terminal device in the MCTP protocol. Therefore, it is necessary to verify whether the target endpoint ID carried in the data packet matches the preset ID actually assigned by the receiving end's physical layer to ensure that the data packet can be routed to the receiving end. Therefore, when verifying the target endpoint IDs carried in each of the multiple received data packets, in response to the target endpoint ID of any received data packet not matching the preset ID actually assigned by the receiving end, such as the preset ID actually assigned by the receiving end is 0x10, but the target endpoint ID carried in the data packet is 0x20; or there is no valid path from the transmitting end to the target endpoint ID in the data link. If any of the above error types are met, it indicates that the target endpoint ID carried in the data packet does not match the preset ID actually assigned by the receiving end's physical layer, indicating that the verification failed. In this case, the mismatching data packet is directly discarded.

[0124] In another specific embodiment, the header version field is used to indicate MCTP protocol version information, such as 1.0, 1.1, or 1.2. Therefore, it is necessary to verify whether the header version carried in the data packet matches the preset version supported by the receiving end to ensure data packet format compatibility. Therefore, when verifying the header versions carried in each of the multiple received data packets, if the header version of any received data packet does not match the preset version supported by the receiving end, indicating that the header version field has been tampered with or damaged, the verification fails. In this case, the mismatching data packet is directly discarded.

[0125] According to another embodiment of the present application, before assembling the data packets, the tag owner bit information and message tag information carried in each of the multiple received data packets may be verified to ensure the message consistency of the data packets.

[0126] The message tag (Msg Tag) uniquely identifies a message in the MCTP protocol and, together with the tag owner bit (Tag Owner), determines the message's ownership. A tag owner bit of 0 indicates that the receiving end is the message owner and that the message tag should be generated by the receiving end. A tag owner bit of 1 indicates that the sending end is the message owner and that the message tag is generated by the sending end.

[0127] Therefore, when verifying the message tag information and tag owner bit information carried by each of the multiple received data packets, in response to receiving a data packet with a tag owner bit of 0, but the receiving end did not assign the message tag information, it means that the ownership of the data packet does not match that of the receiving end; or in response to receiving multiple segmented data packets representing the same message, such as the start packet, the middle packet, and the end packet, the message tag information of each packet is inconsistent; or in response to the message tag information carried by the received data packet has been used and no response is received within the timeout window, it means that the message tag information of the data packet is expired. In the case of any of the above error types, it means that the message tag information and tag owner bit information carried by the data packet do not match the message tag information and tag owner bit information of the receiving end, indicating that the verification failed. In this case, the unmatched data packet is directly discarded.

[0128] Based on this, the embodiments of the present application perform layered verification before assembling data packets to intercept invalid data packets caused by transmission errors, protocol conflicts, or routing anomalies, preventing erroneous data from entering the assembly process and reducing the risk of system crashes or data contamination. In addition, protocol compatibility verification is performed before assembling data packets, ensuring that multiple packets that pass the verification are physically compliant and protocol compatible, preventing illegal operations or routing errors.

[0129] According to an embodiment of the present application, the data processing method also includes: performing field integrity check and protocol standardization check on the assembled data packet to obtain an assembly check result, wherein the field integrity check is used to verify whether the fields in the assembled data packet are complete, and the protocol standardization check is used to verify whether the type of the assembled data packet is compatible with the protocol type of the receiving end; when the assembly check result indicates that the check is passed, the assembled data packet is transmitted to the receiving end.

[0130] In this embodiment, after assembling multiple data packets to obtain an assembled data packet, a field integrity check can be performed on the assembled data packet. The field integrity check can be used to verify whether the assembled data packet structure is complete to ensure that all required fields exist and comply with the format requirements defined by the protocol.

[0131] Specifically, the assembled data packet is checked to see if it contains all the fields required by the protocol, such as the MCTP Header, Payload, and MIC fields. If any field is missing, it means that the assembled data packet field is incomplete and the assembled data packet is discarded.

[0132] For example, for the MIC field, the protocol-specified hash algorithm can be used to calculate the payload of the assembled data packet to generate a hash value. The calculated hash value is then matched with the MIC field value in the assembled data packet. If the matching result represents a consistent value, the verification passes. If the matching result represents an inconsistent value, the assembled data packet is discarded.

[0133] The length of each field included in the assembled data packet can also be checked to ensure compliance with the protocol specification. For example, the protocol specification for the MCTP Header version field is 1 byte. If 2 bytes are detected, it indicates that the assembled data packet field is incorrect and the assembled data packet is discarded.

[0134] In this embodiment, after assembling multiple data packets to obtain an assembled data packet, a protocol compliance check may be performed on the assembled data packet. The protocol compliance check may be used to ensure that the assembled data packet complies with multiple protocol types and semantic rules supported by the receiving end, thereby preventing illegal or unauthorized operations from being performed.

[0135] Specifically, the message types in the assembled data packet, such as firmware upgrade commands and log read commands, are verified to be within the protocol range supported by the receiving end. For example, if the receiving end only supports health monitoring commands, receiving a firmware upgrade command indicates a verification failure.

[0136] Based on this, after obtaining the assembled data packet, the embodiment of the present application verifies the field integrity of the assembled data packet to ensure that all key fields required by the protocol are complete and in the correct format, effectively avoiding message parsing failures or execution anomalies due to missing or incorrect fields; at the same time, the protocol standardization check ensures that the type of the assembled data packet is compatible with the protocol type and semantic rules supported by the receiving end, effectively preventing the execution of illegal or unauthorized operations and ensuring the security and stability of the system. For example, when the receiving end only supports specific health monitoring commands, it can accurately identify and reject unsupported firmware upgrade commands, avoiding equipment failures or safety risks caused by incorrect operations.

[0137] According to an embodiment of the present application, when the verification of the data packet before, during and after assembly is passed, the assembled data packet is transmitted to the receiving end.

[0138] Figure 4 The flowchart of the data processing method according to the specific embodiment of the present application is schematically shown.

[0139] In a specific application scenario such as data transmission based on the MCTP protocol, the data processing method includes operations S401 to S409.

[0140] In operation S401 , a PCLeVDM channel of a solid state drive is started.

[0141] In operation S402, it is determined whether the received multiple data packets have passed the integrity check and the adaptability check. If so, operation S403 is executed to assemble the multiple data packets that have passed the check. If not, operation S404 is executed to discard the assembled data packets that have not passed the check.

[0142] In operation S405, it is determined whether the plurality of data packets pass the sequence continuity check and the function type compatibility check. If so, operation S406 is executed to obtain an assembled data packet. If not, operation S404 is executed to discard the assembled data packets that fail the check.

[0143] In operation S407, it is determined whether the assembled data packet passes the field integrity check and the protocol compliance check. If so, operation S408 is executed to transmit the assembled data packet to the receiving end. If not, operation S409 is executed to discard the assembled data packet that failed the check.

[0144] Based on the above data processing method, this application also provides a data processing device. Figure 5 The device is described in detail.

[0145] Figure 5 The structural block diagram of a data processing device according to an embodiment of the present application is schematically shown.

[0146] like Figure 5 As shown, the data processing device 500 of this embodiment includes a verification module 510 , a matching module 520 , an assembly module 530 , and a transmission module 540 .

[0147] The verification module 510 is configured to, in response to receiving a plurality of data packets from a transmitting end via a target transmission channel, verify sequence identifiers within the plurality of data packets based on a receiving order of the plurality of data packets to obtain a verification result.

[0148] The matching module 520 is configured to perform matching based on the protocol information of the plurality of data packets and the physical layer protocol information of the receiving end to obtain a matching result when the verification result indicates that the verification has passed.

[0149] The assembling module 530 is configured to assemble the multiple data packets based on their respective sequence identifiers to obtain an assembled data packet when the matching result indicates that the protocol information of the multiple data packets matches the physical layer protocol information.

[0150] The transmission module 540 is configured to transmit the assembled data packet to a receiving end.

[0151] According to an embodiment of the present application, the assembly module 530 includes a first detection submodule.

[0152] The first detection submodule is configured to obtain an assembled data packet based on the first to K-th data packets upon detecting that the first data packet received sequentially carries a start identifier and the K-th data packet carries an end identifier.

[0153] According to an embodiment of the present application, the first detection submodule includes a first detection unit and a second detection unit.

[0154] The first detection unit is configured to discard the first to kth data packets in response to detecting that the received k+1th data packet carries a start identifier.

[0155] The second detection unit is configured to, in response to detecting that the received K-th data packet carries an end identifier, assemble the k+1-th data packet to the K-th data packet to obtain an assembled data packet.

[0156] According to an embodiment of the present application, the second detection unit includes a first identification subunit and a first matching subunit.

[0157] The first identification subunit is used to sequentially identify sequence identifiers in the k+1th to Kth data packets.

[0158] The first matching subunit is configured to assemble the k+1th data packet to the Kth data packet to obtain an assembled data packet when the sequence identifier matches the receiving sequence of the k+1th data packet to the Kth data packet.

[0159] According to an embodiment of the present application, the second detection unit further includes a second identification subunit and a second matching subunit.

[0160] The second identification subunit is configured to identify the function type identifier of the K th data packet in response to detecting that the received K th data packet carries an end identifier.

[0161] The second matching subunit is used to assemble the k+1th data packet to the Kth data packet to obtain an assembled data packet when the function type identifier matches any function type of the receiving end.

[0162] According to an embodiment of the present application, the verification module 510 includes a first determination submodule.

[0163] The first determining submodule is configured to obtain a verification result indicating that the verification has passed when the sequence identifier in any data packet among the multiple data packets matches the receiving order of any data packet.

[0164] According to an embodiment of the present application, the verification module 510 further includes a second determination submodule.

[0165] The second determination submodule is used to obtain a matching result indicating that the match fails and discard any data packet when the verification result indicates that the sequence identifier in any data packet does not match the receiving order of any data packet, or when the matching result indicates that the protocol information of any data packet does not match the physical layer protocol information.

[0166] According to an embodiment of the present application, the data processing method further includes an assembly verification module and an assembly transmission module.

[0167] The assembly verification module is used to perform field integrity verification and protocol standardization verification on the assembled data packet to obtain the assembly verification result. Among them, the field integrity verification is used to verify whether the fields in the assembled data packet are complete, and the protocol standardization verification is used to verify whether the type of the assembled data packet is compatible with the protocol type of the receiving end.

[0168] The assembly transmission module is used to transmit the assembled data packet to the receiving end when the assembly verification result indicates that the verification has passed.

[0169] According to embodiments of the present application, any multiple modules among the verification module 510, matching module 520, assembly module 530, and transmission module 540 may be combined into a single module, or any one of these modules may be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules may be combined with at least part of the functionality of other modules and implemented in a single module. According to embodiments of the present application, at least one of the verification module 510, matching module 520, assembly module 530, and transmission module 540 may be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on a chip, a system on a substrate, a system on a package, an application-specific integrated circuit (ASIC), or may be implemented in hardware or firmware through any other reasonable means of circuit integration or packaging, or may be implemented in any one of the three implementation methods of software, hardware, and firmware, or any appropriate combination of these. Alternatively, at least one of the verification module 510, matching module 520, assembly module 530, and transmission module 540 may be at least partially implemented as a computer program module that, when executed, performs the corresponding functionality.

[0170] Figure 6 A block diagram of an electronic device suitable for implementing a data processing method according to an embodiment of the present application is schematically shown.

[0171] like Figure 6As shown, an electronic device 600 according to an embodiment of the present application includes a processor 601, which can perform various appropriate actions and processes based on a program stored in a read-only memory (ROM) 602 or a program loaded from a storage unit 608 into a random access memory (RAM) 603. The processor 601 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or a related chipset and / or a dedicated microprocessor (e.g., an application-specific integrated circuit (ASIC)). The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for executing different actions of the method flow according to an embodiment of the present application.

[0172] Various programs and data required for the operation of the electronic device 600 are stored in the RAM 603. The processor 601, ROM 602, and RAM 603 are connected to each other via a bus 604. The processor 601 performs various operations of the method flow according to the embodiment of the present application by executing the programs in the ROM 602 and / or RAM 603. It should be noted that the programs may also be stored in one or more memories other than the ROM 602 and RAM 603. The processor 601 may also perform various operations of the method flow according to the embodiment of the present application by executing the programs stored in the one or more memories.

[0173] According to an embodiment of the present application, electronic device 600 may further include an input / output (I / O) interface 605, which is also connected to bus 604. Electronic device 600 may also include one or more of the following components connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including devices such as a cathode ray tube (CRT), liquid crystal display (LCD), and speakers; a storage section 608 including a hard disk; and a communication section 609 including a network interface card such as a LAN card or modem. Communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 605 as needed. Removable media 611, such as a magnetic disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed in drive 610 as needed, so that computer programs read from the removable media can be installed into storage section 608 as needed.

[0174] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments, or may exist independently and not be incorporated into the device / apparatus / system. The computer-readable storage medium carries one or more programs, and when the one or more programs are executed, the data processing method according to the embodiments of this application is implemented.

[0175] According to an embodiment of the present application, a computer-readable storage medium may be a non-volatile computer-readable storage medium, and may include, for example, but not limited to: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present application, a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to an embodiment of the present application, a computer-readable storage medium may include the ROM 602 and / or RAM 603 described above and / or one or more memories other than ROM 602 and RAM 603.

[0176] The embodiments of the present application also include a computer program product, which includes a computer program containing program code for executing the method shown in the flowchart. When the computer program product is run in a computer system, the program code is used to enable the computer system to implement the data processing method provided in the embodiments of the present application.

[0177] The computer program executes the above functions defined in the system / device of the embodiment of the present application when the computer program is executed by the processor 601. According to the embodiment of the present application, the system, device, module, unit, etc. described above can be implemented by a computer program module.

[0178] In one embodiment, the computer program may be stored on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may be transmitted and distributed in the form of a signal on a network medium, downloaded and installed via the communication portion 609, and / or installed from a removable medium 611. The program code contained in the computer program may be transmitted using any appropriate network medium, including but not limited to wireless, wired, or any suitable combination thereof.

[0179] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 609, and / or installed from a removable medium 611. When the computer program is executed by the processor 601, the above-mentioned functions defined in the system of the embodiment of the present application are performed. According to the embodiment of the present application, the systems, devices, means, modules, units, etc. described above can be implemented by computer program modules.

[0180] According to an embodiment of the present application, the program code for executing the computer program provided by the embodiment of the present application can be written in any combination of one or more programming languages. Specifically, these computer programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages include, but are not limited to, languages such as Java, C++, Python, "C" or similar programming languages. The program code can be executed entirely on the user computing device, partially on the user device, partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (for example, using an Internet service provider to connect via the Internet).

[0181] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the above-mentioned module, program segment, or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of the boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0182] Those skilled in the art will appreciate that the features described in the various embodiments of this application may be combined and / or coupled in various ways, even if such combinations or couplings are not explicitly described in this application. In particular, the features described in the various embodiments of this application may be combined and / or coupled in various ways without departing from the spirit and teachings of this application. All such combinations and / or couplings fall within the scope of this application.

[0183] The embodiments of the present application have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of the present application. Although each embodiment has been described separately above, this does not mean that the measures in each embodiment cannot be advantageously used in combination. Without departing from the scope of the present application, those skilled in the art may make various substitutions and modifications, and these substitutions and modifications should all fall within the scope of the present application.

Claims

1. A data processing method, wherein: The method comprises: In response to receiving a plurality of data packets from a transmitting end via a target transmission channel, verifying sequence identifiers of the plurality of data packets based on a receiving order of the plurality of data packets to obtain a verification result; If the verification result indicates that the verification is passed, matching the protocol information of the multiple data packets with the physical layer protocol information of the receiving end to obtain a matching result; When the matching result indicates that the protocol information of the plurality of data packets matches the physical layer protocol information, assembling the plurality of data packets based on respective sequence identifiers of the plurality of data packets to obtain an assembled data packet; The assembled data packet is transmitted to the receiving end.

2. The method according to claim 1, wherein The sequence identifier includes a start identifier and an end identifier, and the assembling of the multiple data packets based on the sequence identifiers of the multiple data packets to obtain an assembled data packet includes: When it is detected that the first data packet received sequentially carries the start identifier and the Kth data packet carries the end identifier, the assembled data packet is obtained according to the first to Kth data packets, where K is a positive integer.

3. The method according to claim 2, wherein: The step of obtaining the assembled data packet according to the first to Kth data packets includes: In response to detecting that the received k+1th data packet carries the start identifier, discarding the first to kth data packets, where k is an integer greater than 1 and less than K-1; In response to detecting that the received K-th data packet carries the end identifier, assembling the k+1-th data packet to the K-th data packet to obtain the assembled data packet.

4. The method according to claim 3, wherein: In response to detecting that the received K-th data packet carries the end identifier, assembling the k+1-th data packet to the K-th data packet to obtain the assembled data packet, including: sequentially identifying sequence identifiers in the k+1th to Kth data packets; In a case where the sequence identifier matches the receiving order of the k+1th data packet to the Kth data packet, the k+1th data packet to the Kth data packet are assembled to obtain the assembled data packet.

5. The method according to claim 3, wherein: The method further comprises: In response to detecting that the received K-th data packet carries the end identifier, identifying the function type identifier of the K-th data packet; In a case where the function type identifier matches any function type of the receiving end, the k+1th data packet to the Kth data packet are assembled to obtain the assembled data packet.

6. The method according to claim 1, wherein The step of verifying the sequence identifiers in the plurality of data packets based on the order in which the plurality of data packets are received, and obtaining verification results, comprises: In the case where the sequence identifier in any data packet among the multiple data packets matches the receiving order of the any data packet, the verification result indicating that the verification is passed is obtained.

7. The method according to claim 6, wherein: The method further comprises: In the case where the verification result indicates that the sequence identifier within any data packet does not match the reception order of any data packet, or the matching result indicates that the protocol information of any data packet does not match the physical layer protocol information, the matching result indicating that the match fails is obtained, and any data packet is discarded.

8. The method according to claim 1, wherein The method further comprises: Performing a field integrity check and a protocol standardization check on the assembled data packet to obtain an assembly verification result, wherein the field integrity check is used to verify whether the fields in the assembled data packet are complete, and the protocol standardization check is used to verify whether the type of the assembled data packet is compatible with the protocol type of the receiving end; If the assembly verification result indicates that the verification is passed, the assembled data packet is transmitted to the receiving end.

9. A data processing device, wherein: The device comprises: a verification module, configured to, in response to receiving a plurality of data packets from a transmitting end via a target transmission channel, verify sequence identifiers within the plurality of data packets based on a reception order of the plurality of data packets to obtain a verification result; a matching module, configured to, when the verification result indicates that the verification has passed, perform matching based on the protocol information of the plurality of data packets and the physical layer protocol information of the receiving end to obtain a matching result; an assembling module, configured to assemble the multiple data packets based on respective sequence identifiers of the multiple data packets to obtain an assembled data packet when the matching result indicates that the protocol information of the multiple data packets matches the physical layer protocol information; A transmission module is used to transmit the assembled data packet to the receiving end.

10. An electronic device comprising: one or more processors; a memory for storing one or more computer programs, It is characterized in that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 8.

Images