Data communication method, device and system and storage medium

Abstract

The invention discloses a data communication method, device and system and a storage medium, and relates to the technical field of Ethernet communication, and the data communication method comprises the steps: firstly obtaining a plurality of data packets generated by an upper-layer application, and then constructing corresponding communication sub-packets according to the data length, the content and the check code of the data packets; and extracting a standard Ethernet frame header, inserting a combined identification field, splicing the communication sub-packets to the identification field in sequence, adding a frame verification sequence to generate a combined packet, and sending the combined packet to a receiving end. And the receiving end executes first integrity check through the frame check sequence, splits the communication sub-packets according to the merging identifier after the first integrity check passes, and executes second integrity check through the communication sub-packet check code to process the effective communication sub-packets. According to the invention, the redundancy overhead is reduced through merging and packaging of multiple small data packets, the equipment compatibility is guaranteed by the standard frame header, the anti-error-code capability is improved through double-layer verification, and the transmission efficiency and the anti-error-code performance of the small data packets can be optimized while the compatibility is considered.

Description

Technical Field

[0001] This application relates to the field of Ethernet communication technology, and in particular to data communication methods, apparatus, systems and storage media. Background Technology

[0002] With the development of Ethernet, high-frequency small data packet transmission scenarios are becoming increasingly common. When transmitting a large number of small data packets, traditional Ethernet requires each small data packet to carry a fixed-length frame header and checksum, resulting in a low proportion of effective data and wasted bandwidth. Furthermore, the independent transmission of multiple small data packets follows the Interframe Gap (IFG) rule, frequently competing for row channels and causing transmission delays.

[0003] To address these issues, frame aggregation technology has been proposed, which concatenates the data portions of multiple small data packets, retaining only a frame header and checksum. While this technology can improve bandwidth utilization, an error in any sub-packet within the merged packet results in the entire merged packet being discarded, requiring all sub-packets to be retransmitted, leading to poor transmission efficiency. Furthermore, this technology relies on specific Wi-Fi protocols, resulting in poor compatibility with traditional Ethernet devices. Therefore, how to improve the transmission efficiency and error resilience of small data packets while ensuring device compatibility has become a pressing problem. Summary of the Invention

[0004] This application provides a data communication method, apparatus, system, and storage medium to at least solve the problems of low transmission efficiency and low error resistance of small data packets in related technologies.

[0005] This application provides a data communication method, including:

[0006] Retrieve multiple data packets generated by the upper-layer application; Based on the data length, data content, and checksum of multiple data packets, construct the communication sub-packet corresponding to each data packet; Extract the Ethernet frame header and insert a merge identifier field after the Ethernet frame header; The communication sub-packets are concatenated in the transmission order after the merge identifier field, and the frame check sequence is added to the end of the last communication sub-packet to generate the merged packet; Send the merged packet to the receiving end; The receiving end performs a first integrity check on the merged packet based on the frame check sequence. If the merged packet passes the first integrity check, it further decomposes the merged packet into multiple communication sub-packets based on the merge identifier field. Then, it performs a second integrity check on the communication sub-packets based on their check codes. If the communication sub-packets pass the second integrity check, it performs data processing on the communication sub-packets.

[0007] This application also provides a data communication method, including: Retrieve the merged packet sent by the sender; Extract the frame verification sequence at the end of the merged packet and perform the first integrity check on the merged packet; If the merged packet passes the first integrity check, the merged packet is further divided into sub-packets based on the merge identifier field to obtain multiple communication sub-packets; Extract the checksum at the end of each communication sub-packet to perform a second integrity check on the communication sub-packet; If the communication sub-packet passes the second integrity check, the communication sub-packet is parsed into a data packet and submitted to the upper-layer protocol for data processing.

[0008] This application also provides a data communication device for use at a transmitting end, comprising: The data packet acquisition module is used to acquire multiple data packets generated by the upper-layer application; The communication sub-packet construction module is used to construct the communication sub-packet corresponding to each data packet based on the data length, data content, and checksum of multiple data packets; The encapsulation module is used to extract the Ethernet frame header and insert a merge identifier field after the Ethernet frame header; The merging module is used to concatenate communication sub-packets in the transmission order after the merge identifier field, and add the frame check sequence to the end of the last communication sub-packet to generate a merged packet; The sending module is used to send the merged packet to the receiving end.

[0009] This application also provides a data communication device for use at a receiving end, comprising: The acquisition module is used to acquire the merged packet sent by the sender. The first integrity verification module is used to extract the frame verification sequence at the end of the merged packet and perform the first integrity verification on the merged packet. The merged packet disassembly module is used to disassemble the merged packet into sub-packets based on the merge identifier field, after the merged packet has passed the first integrity check, to obtain multiple communication sub-packets. The second integrity verification module is used to extract the check code at the end of each communication sub-packet to perform a second integrity verification on the communication sub-packet. The communication sub-packet processing module is used to parse the communication sub-packet into a data packet when the communication sub-packet passes the second integrity check, and submit it to the upper-layer protocol for data processing.

[0010] This application also provides a data communication system, including: a transmitter and a receiver; The sending end acquires multiple data packets generated by the upper-layer application; constructs communication sub-packets corresponding to each data packet based on the data length, data content, and checksum of the multiple data packets; extracts the Ethernet frame header and inserts a merge identifier field after the Ethernet frame header; concatenates the communication sub-packets in the transmission order after the merge identifier field, and adds the frame check sequence to the end of the last communication sub-packet to generate a merged packet; and sends the merged packet to the receiving end. The receiving end acquires the merged packet sent by the sending end; extracts the frame check sequence at the end of the merged packet and performs a first integrity check on the merged packet; if the merged packet passes the first integrity check, it is disassembled into sub-packets according to the merge identifier field to obtain multiple communication sub-packets; the checksum at the end of each communication sub-packet is extracted to perform a second integrity check on the communication sub-packet; if the communication sub-packet passes the second integrity check, it is parsed into data packets for submission to the upper-layer protocol for data processing.

[0011] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described data communication methods.

[0012] In some embodiments of this application, communication sub-packets are constructed based on multiple data packets generated by upper-layer applications. These sub-packets are then embedded with a merge identifier field and a frame check sequence, concatenated into a merged packet for transmission. Simultaneously, a dual integrity check logic is designed at the receiving end. This approach balances device compatibility, improves the transmission efficiency of small data packets, and enhances error resilience. For example, by merging multiple communication sub-packets into a single merged packet, the number of repeated Ethernet frame header encapsulations and channel contention is reduced, significantly improving the transmission efficiency of small data packets. Furthermore, the two-layer mechanism at the receiving end—first performing an overall first integrity check based on the frame check sequence, and then performing a single second integrity check based on the sub-packet checksum—enhances error resilience. At the same time, the standard Ethernet frame header is preserved, and the merge identifier field does not disrupt the traditional frame structure, allowing traditional devices to recognize and process the data normally, ensuring device compatibility. Thus, while maintaining device compatibility, the transmission efficiency of small data packets and error resilience are improved. Attached Figure Description

[0013] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 A flowchart illustrating a data communication method provided for some embodiments of this application; Figure 2A flowchart illustrating a data communication method provided for further embodiments of this application; Figure 3 A schematic diagram of the sending end processing flow provided in this application; Figure 4 This is a schematic diagram of the merged package structure provided in this application; Figure 5 A schematic diagram of the error detection process provided for this application; Figure 6 Schematic diagrams of a data communication apparatus provided for some embodiments of this application; Figure 7 A schematic diagram of a data communication apparatus provided for further embodiments of this application; Figure 8 An embodiment of this application also provides a schematic diagram of a data communication system. Detailed Implementation

[0015] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0016] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0017] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0018] In some technical solutions, frame aggregation technology has been proposed to improve the bandwidth waste and transmission latency issues caused by traditional Ethernet when transmitting a large number of small data packets. While this can improve bandwidth utilization to some extent, an error in any sub-packet within the merged packet will cause the entire merged packet to be discarded, requiring all sub-packets to be retransmitted, resulting in poor transmission efficiency. Furthermore, this technology relies on WiFi-specific protocols, leading to poor compatibility with traditional Ethernet devices and making it unsuitable for the existing wired Ethernet ecosystem. Therefore, how to improve the transmission efficiency and error resilience of small data packets while ensuring device compatibility has become an urgent problem to be solved.

[0019] In view of this, this application provides a data communication method that can solve the above problems. The data communication method can be applied to the sending end. (See also...) Figure 1 This is a flowchart illustrating a data communication method provided in some embodiments of this application. Figure 1 In this context, the data communication method includes the following steps: Step S101: Obtain multiple data packets generated by the upper-layer application.

[0020] Specifically, upper-layer applications refer to programs or modules deployed on the sending end that can generate business-related raw data, such as sensor data acquisition applications, which are the source of raw data for data packets.

[0021] Specifically, a data packet refers to the raw data generated by an upper-layer application, such as small data packets generated frequently.

[0022] It is understandable that the MAC (Medium Access Control) layer at the sending end obtains the data to be transmitted generated and sent by the upper layer application during its operation, forming multiple data packets to be processed, with at least one data packet.

[0023] Step S102: Based on the data length, data content, and checksum of multiple data packets, construct the communication sub-packet corresponding to each data packet.

[0024] Specifically, the data length of a data packet refers to the number of bytes of data content in a single data packet. It is the basis for determining whether a data packet should be merged. The length field of the data length is 2 bytes.

[0025] Specifically, data content refers to the raw business data generated by upper-layer applications, such as data collected by sensors.

[0026] Specifically, the check code is calculated based on the data content of the data packet using a preset generator polynomial. It is used to verify the data integrity of the corresponding communication sub-packet individually and can be a 1-byte CRC-8 (Cyclic Redundancy Check-8) check code.

[0027] Specifically, a communication sub-packet refers to a data sub-unit designed specifically for multi-packet merged transmission. It is a component of the merged packet, and its structure includes three parts: a pre-length field, core data content, and a post-check code.

[0028] Understandably, the data length of the data packet is used to generate the pre-length field of the communication sub-packet, the data content serves as the payload of the communication sub-packet, and the checksum is used for independent integrity verification of the communication sub-packet. The communication sub-packet is constructed based on the above three parts.

[0029] Step S103: Extract the Ethernet frame header and insert a merge identifier field after the Ethernet frame header.

[0030] Optionally, the Ethernet frame header refers to a 14-byte basic identification field conforming to the IEEE 802.11n standard, which can ensure that the subsequently synthesized merged packets are compatible with traditional devices, including a 6-byte destination address, a 6-byte source address, and a 2-byte type field.

[0031] Optionally, the merge identifier field is a fixed-length custom field designed to distinguish merged packets from ordinary independent data packets. It is used by the receiving end to identify merged packets, has a fixed length of 2 bytes, and takes the value of hexadecimal 0xAABB.

[0032] Understandably, the Ethernet frame header is extracted from the standard Ethernet format corresponding to the first data packet involved in the merging. If the data packet does not have a preset frame header, a complete frame header is generated according to the IEEE 802.11n standard. The merge identifier field is inserted between the end of the Ethernet frame header and the communication sub-packet sequence. The insertion process maintains the original format and byte order of the Ethernet frame header.

[0033] Step S104: Concatenate the communication sub-packets in the transmission order after the merge identifier field, and add the frame check sequence to the end of the last communication sub-packet to generate a merged packet.

[0034] Optionally, the frame check sequence is calculated using a preset generator polynomial and is used to perform overall integrity verification on the entire merged packet. It is a 4-byte CRC-32 cyclic redundancy check sequence, which is different from the CRC-8 check code of the communication sub-packet itself.

[0035] Specifically, a merged packet refers to the final complete data unit that can be directly transmitted in Ethernet. It is the aggregated result of the traditional Ethernet frame header, merge identifier field, and multiple communication sub-packets after unified splicing and the addition of an overall check sequence.

[0036] Understandably, communication sub-packets are concatenated into the Ethernet frame header and merge identifier field in the order of transmission. The concatenation is performed in a first-in-first-out order to ensure accurate data transmission timing. After concatenation, the frame check sequence is added to the end of the last communication sub-packet.

[0037] Step S105: The merged packet is sent to the receiving end; wherein, the receiving end performs a first integrity check on the merged packet according to the frame check sequence, and if the merged packet passes the first integrity check, it decomposes the merged packet into multiple communication sub-packets according to the merge identifier field, and performs a second integrity check on the communication sub-packets according to the check codes of the communication sub-packets, and if the communication sub-packets pass the second integrity check, it processes the data of the communication sub-packets.

[0038] Specifically, the receiving end refers to the target device that receives the merged packets in Ethernet communication, and can be any device with Ethernet communication capabilities.

[0039] Specifically, the first integrity check refers to the overall check performed by the receiving end based on the frame check sequence at the end of the merged packet, and the check scope covers the entire merged packet.

[0040] Specifically, the second integrity check refers to the separate check performed by the receiving end based on the checksum appended to each communication sub-packet, and the check scope is only for the data content of a single communication sub-packet.

[0041] Understandably, when the merged packet is sent, it follows the Ethernet transmission protocol and is pushed to the target receiving end through the physical line. The receiving end first completes the overall verification through the frame check sequence, then disassembles the communication sub-packets based on the merge identifier, and finally verifies the individual communication sub-packets through the check code to ensure data reliability.

[0042] In summary, in the technical solutions of some embodiments of this application, communication sub-packets are constructed based on multiple data packets generated by upper-layer applications. These sub-packets are then embedded with a merge identifier field and a frame check sequence, concatenated into a merged packet for transmission. Simultaneously, dual integrity verification logic is designed at the receiving end. This approach balances device compatibility, improves the transmission efficiency of small data packets, and enhances error resilience. For example, by merging multiple communication sub-packets into a single merged packet, the number of repeated Ethernet frame header encapsulations and channel contention is reduced, significantly improving the transmission efficiency of small data packets. Furthermore, the two-layer mechanism at the receiving end—first performing an overall first integrity check based on the frame check sequence, and then performing a single second integrity check based on the sub-packet checksum—enhances error resilience. At the same time, the standard Ethernet frame header is preserved, and the merge identifier field does not disrupt the traditional frame structure, allowing traditional devices to correctly identify and process the data, thus ensuring device compatibility. Therefore, while ensuring device compatibility, the transmission efficiency of small data packets and error resilience are improved.

[0043] In some embodiments, step S103, which involves concatenating communication sub-packets in transmission order after the merge identifier field and adding a frame check sequence to the end of the last communication sub-packet to generate a merged packet, includes: Step S1031: Determine the data length of multiple communication sub-packets.

[0044] Step S1032: If the data length of the communication sub-packet is less than or equal to a preset threshold, the communication sub-packet is stored in the merged cache queue.

[0045] Step S1033: If the number of communication sub-packets in the merged buffer queue reaches a preset number, or if the waiting time of the first communication sub-packet in the merged buffer queue exceeds a preset duration, the communication sub-packets in the merged buffer queue are concatenated to the merge identifier field in the transmission order, and the frame verification sequence is added to the end of the last communication sub-packet to generate a merged packet.

[0046] Optionally, a preset threshold is used to distinguish between small data packets suitable for combined transmission and medium-to-large data packets that need to be transmitted independently. The threshold is set to 128 bytes, and communication sub-packets with a data length of no more than 128 bytes are included in the merging range.

[0047] Optionally, the merge buffer queue adopts a FIFO (First In First Out) temporary queue to store communication sub-packets that meet the merging conditions.

[0048] Optionally, the preset quantity is one of the conditions for triggering the merge, which means that the merge is started when the number of communication sub-packets in the merge cache queue reaches the preset quantity, which can be 5.

[0049] Specifically, the preset duration is one of the conditions for triggering the merge. It means that the merge will start when the waiting time of the first communication sub-packet in the merge cache queue expires, so as to avoid the communication sub-packet being cached for too long. It can be 10ms.

[0050] Understandably, after length determination, communication sub-packets with data lengths less than a preset threshold are selected, and the communication sub-packets that meet the conditions are stored in a FIFO queue. Finally, a merged packet is generated by satisfying either the preset number of communication sub-packets in the FIFO queue or the waiting time of the first communication sub-packet in the FIFO queue exceeds a preset duration.

[0051] Understandably, the preset number and duration of the merge buffer queue can be dynamically adjusted according to the bandwidth load of the Ethernet channel. When the channel load is higher than the preset threshold, the preset number of the merge buffer queue can be reduced and the preset duration can be shortened to reduce the transmission delay of the merged packets. When the channel load is lower, the preset number can be increased and the duration can be extended to improve the bandwidth utilization of the merged transmission.

[0052] In the above embodiments, the design of length-based filtering, FIFO queue temporary storage, and dual-condition merging is used to complete the filtering, temporary storage, and merging of communication sub-packets that are suitable for merging. This avoids resource waste and transmission delay caused by the merging of medium and large communication sub-packets, prevents communication sub-packet splicing sequence disorder and real-time performance degradation due to excessive buffering, and ensures the efficiency and accuracy of communication sub-packet transmission.

[0053] In some embodiments, the method of this application further includes: Step a1: If the data length of the communication sub-packet is greater than a preset threshold, the communication sub-packet is treated as an independent communication packet.

[0054] Step a2: Add an Ethernet frame header before the independent communication packet and a frame check sequence after the independent communication packet, and send the independent communication packet to the receiving end.

[0055] Specifically, an independent communication packet refers to a data unit that is encapsulated and transmitted separately, including communication sub-packets, Ethernet frame headers, and frame check sequences.

[0056] Understandably, when the data length of a communication sub-packet exceeds a preset threshold, the communication sub-packet is classified as a medium-to-large communication sub-packet and processed as an independent communication packet. A 14-byte Ethernet frame header is added to the independent communication packet, which is consistent with the frame header structure of the merged packet. A frame check sequence using the CRC-32 algorithm is added after the independent communication packet, which is consistent with the overall check rules of the merged packet. After encapsulation, it is sent directly to the receiving end according to the Ethernet transmission protocol, without needing to enter the merged buffer queue to wait for trigger conditions.

[0057] In the above embodiments, by using a differentiated transmission design for large and small communication sub-packets, the independent encapsulation and transmission of medium and large communication sub-packets are achieved, thus avoiding the problem of cache resource occupation caused by the merging of medium and large communication sub-packets.

[0058] This application also provides a data communication method that can be applied to a receiving end. (See also...) Figure 2 This is a flowchart illustrating a data communication method provided in some embodiments of this application. Figure 2 In this context, the data communication method includes the following steps: Step S201: Obtain the merged packet sent by the sending end.

[0059] Step S202: Extract the frame verification sequence at the end of the merged packet and perform the first integrity check on the merged packet.

[0060] Step S203: If the merged packet passes the first integrity check, the merged packet is disassembled into sub-packets according to the merge identifier field to obtain multiple communication sub-packets.

[0061] Step S204: Extract the checksum at the end of each communication sub-packet to perform a second integrity check on the communication sub-packet.

[0062] Step S205: If the communication sub-packet passes the second integrity check, the communication sub-packet is parsed into a data packet and submitted to the upper-layer protocol for data processing.

[0063] Understandably, when the receiving end detects a data packet, it first matches the 6-byte target address in the Ethernet frame header to confirm itself as the target receiving device, and then receives the merged packet. Next, based on the 4-byte frame check sequence at the end of the merged packet, it calculates a CRC-32 sequence for the remaining portion and compares the two sequences. If they match, the first integrity check is passed. Then, based on the length field of the first communication sub-packet, it determines its byte range, extracts it, and continues to locate the next communication sub-packet until all communication sub-packets are separated. Afterward, for each separated communication sub-packet, the receiving end extracts the 1-byte checksum at the end, recalculates the CRC-8 checksum for the communication sub-packet data content, and determines whether the communication sub-packet is intact, completing the second integrity check. Finally, the communication sub-packets that pass the second integrity check are parsed, and the parsed original data packets are submitted to the upper-layer protocol for processing.

[0064] In summary, in the technical solutions provided by some embodiments of this application, after the receiving end obtains the merged packet from the sending end, it performs a first integrity check using the frame check sequence, then disassembles the sub-packets based on the merge identifier field and performs a second integrity check using the checksum, and finally parses the valid sub-packets and submits them to the upper-layer protocol for processing. This approach balances device compatibility, improves the efficiency of small data packet reception and parsing, and enhances error resilience.

[0065] In some embodiments, the method of this application further includes: Step b1: If the merged packet fails the first integrity check, discard the merged packet and send a merged packet retransmission request to the sender.

[0066] Specifically, a merge packet retransmission request is a request instruction used to inform the sender that the corresponding merge packet transmission failed and needs to be retransmitted. It may include the merge packet identifier and the reason for the transmission error.

[0067] Understandably, if the receiving end compares the extracted 4-byte CRC-32 frame check sequence at the end of the merged packet with the CRC-32 sequence recalculated for the remaining part of the merged packet, and the two sequences are inconsistent, it indicates that there is data loss or transmission error, or the data is incomplete. In this case, the merged packet is cleared and does not proceed to the subsequent disassembly and verification process. Instead, a merged packet retransmission request is sent to the sending end, allowing the sending end to retransmit the abnormal merged packet.

[0068] In the above embodiments, merged packets that fail the first integrity check are discarded by comparing and verifying the CRC-32 sequence, and a targeted retransmission request is sent to the sending end to complete the identification and fault tolerance processing of abnormal merged packets, thus ensuring the reliability of data processing at the receiving end.

[0069] In some embodiments, the method of this application further includes: Step c1: If the communication sub-packet fails the second integrity check, the communication sub-packet is treated as an abnormal communication sub-packet.

[0070] Step c2: Send a retransmission request for the abnormal communication sub-packet to the sending end.

[0071] Specifically, a retransmission request for an abnormal communication sub-packet refers to precisely informing the sender of the specific communication sub-packet that needs to be retransmitted, which may include the merged packet identifier, the position sequence number of the abnormal sub-packet, and the reason for the verification failure.

[0072] Understandably, after the receiving end compares the extracted CRC-8 checksum at the end of the communication sub-packet with the CRC-8 sequence recalculated from the data content of the communication sub-packet, the two sequences are inconsistent, indicating that the communication sub-packet has data corruption during transmission. The receiving end will store it separately from the normal sub-packet, without proceeding to subsequent parsing and upper-layer protocol processing, and will send a retransmission request for the abnormal communication sub-packet to the sending end, so that the sending end can retransmit the abnormal communication sub-packet.

[0073] In the above embodiments, communication sub-packets that fail the second integrity check are discarded by comparing and verifying the CRC-8 sequence, and a targeted retransmission request is sent to the sending end to complete the identification and fault tolerance processing of communication sub-packets with abnormal transmission, thus ensuring the reliability of data processing at the receiving end.

[0074] See also Figure 3 This is a schematic diagram of the sending end processing flow provided in this application. Figure 3 In this process, the upper-layer data input serves as the starting point, providing the original business data to be transmitted. The merging judgment module uses 128 bytes as a threshold to determine the data length. Small data packets with a length ≤ 128 bytes will enter the buffer queue, while medium to large data packets with a length > 128 bytes will directly trigger the sending of the original packet. The buffer queue adopts a FIFO structure to temporarily store small data packets to be merged, waiting for the merging trigger condition to be met. When the buffer queue meets either the condition of reaching the number of communication sub-packets or the first communication sub-packet timing out, the merging process will be triggered. The merging and encapsulation module, based on the trigger instruction of the merging control module, splices the communication sub-packets in the buffer queue in sequence to generate a merged packet containing a standard Ethernet frame header, a merge identifier field, and a frame check sequence. The physical layer transmission is responsible for sending the merged packet or the original packet to the receiving end through the Ethernet physical link.

[0075] See also Figure 4 , Figure 4 This is a schematic diagram of the merged package structure provided in this application. Figure 4In standard Ethernet frames, the header is 14 bytes, including the destination address, source address, and type field; the merge identifier field is 2 bytes, used by the receiver to accurately identify that the data packet is a merged packet; each communication sub-packet consists of a 2-byte length field, sub-packet data content, and a 1-byte CRC checksum, which are concatenated in the order of transmission; the FCS is the Frame Check Sequence, generated using the CRC-32 algorithm, which performs integrity verification on the entire merged packet.

[0076] See also Figure 5 , Figure 5 A schematic diagram of the error detection process provided for this application. Figure 5 In the process, when the receiving end splits and merges packets, it first verifies the overall FCS to ensure the integrity of physical layer transmission. If the overall verification fails, the entire packet is discarded and a retransmission is triggered. If the overall verification passes, each sub-packet is further checked with CRC-8.

[0077] Corresponding to the data communication method, this application also provides a data communication apparatus. (See also...) Figure 6 This is a schematic diagram of a data communication device provided in some embodiments of this application. Figure 6 In this context, the data communication device includes: The data packet acquisition module 601 is used to acquire multiple data packets generated by the upper-layer application; The communication sub-packet construction module 602 is used to construct the communication sub-packet corresponding to each data packet based on the data length, data content and checksum of multiple data packets; Encapsulation module 603 is used to extract the Ethernet frame header and insert a merge identifier field after the Ethernet frame header; The merging module 604 is used to concatenate communication sub-packets in the transmission order after the merging identifier field, and add the frame check sequence to the end of the last communication sub-packet to generate a merged packet; The sending module 605 is used to send the merged packet to the receiving end.

[0078] In some embodiments, the merging module 604 includes: The length determination unit is used to determine the data length of multiple communication sub-packets. The merge cache unit is used to store the communication sub-packet into the merge cache queue when the data length of the communication sub-packet is less than or equal to a preset threshold. The merge packet generation unit is used to generate a merge packet when the number of communication sub-packets in the merge buffer queue reaches a preset number, or when the waiting time of the first communication sub-packet in the merge buffer queue exceeds a preset duration, by concatenating the communication sub-packets in the merge buffer queue according to the transmission order and appending the frame verification sequence to the end of the last communication sub-packet.

[0079] In some embodiments, the apparatus of this application further includes: An independent communication packet generation unit is used to treat a communication sub-packet as an independent communication packet when the data length of the communication sub-packet exceeds a preset threshold. The independent communication packet sending unit is used to add an Ethernet frame header before the independent communication packet and a frame check sequence after the independent communication packet, and then send the independent communication packet to the receiving end.

[0080] For a description of the features in the embodiment corresponding to the data communication device, please refer to the relevant description in the embodiment corresponding to the sample data processing method, which will not be repeated here.

[0081] Corresponding to the data communication method, this application also provides a data communication apparatus. (See also...) Figure 7 This is a schematic diagram of a data communication device provided in some embodiments of this application. Figure 7 In this context, the data communication device includes: The acquisition module 701 is used to acquire the merged packet sent by the sending end; The first integrity verification module 702 is used to extract the frame verification sequence at the end of the merged packet and perform the first integrity verification on the merged packet. The merged packet disassembly module 703 is used to disassemble the merged packet into multiple communication sub-packets based on the merge identifier field, provided that the merged packet passes the first integrity check. The second integrity verification module 704 is used to extract the check code at the end of each communication sub-packet to perform a second integrity verification on the communication sub-packet. The communication sub-packet processing module 705 is used to parse the communication sub-packet into a data packet when the communication sub-packet passes the second integrity check, so as to submit it to the upper layer protocol for data processing.

[0082] In some embodiments, the apparatus of this application further includes: The merge packet retransmission unit is used to discard the merge packet and send a merge packet retransmission request to the sender if the merge packet fails the first integrity check.

[0083] In some embodiments, the apparatus of this application further includes: An abnormal communication sub-packet construction unit is used to treat a communication sub-packet as an abnormal communication sub-packet if the communication sub-packet fails the second integrity check. The communication sub-packet retransmission unit is used to send a retransmission request for an abnormal communication sub-packet to the sending end.

[0084] For a description of the features in the embodiment corresponding to the data communication device, please refer to the relevant description in the embodiment corresponding to the sample data processing method, which will not be repeated here.

[0085] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0086] See also Figure 8 The embodiments of this application also provide a data communication system, including a transmitting end 10 and a receiving end 20. The transmitting end 10 stores a computer program, and the receiving end 20 is configured to run the computer program to perform the steps in any of the above-described data communication method embodiments.

[0087] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described data communication method embodiments at runtime.

[0088] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0089] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described data communication method embodiments.

[0090] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described data communication method embodiments.

[0091] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0092] The data communication method, apparatus, system, and storage medium provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A data communication method applied to a sending end, characterized in that, The method comprises: acquiring a plurality of data packets generated by an upper layer application; constructing a communication sub-packet corresponding to each of the data packets according to data lengths, data contents and check codes of the plurality of data packets; extracting an Ethernet frame header and inserting a merge identification field after the Ethernet frame header; splicing the communication sub-packets to the merge identification field in a transmission order and adding a frame check sequence to a tail of a last communication sub-packet to generate a merge packet; sending the merge packet to a receiving end; wherein the receiving end performs a first integrity check on the merge packet according to the frame check sequence, performs sub-packet disassembly on the merge packet according to the merge identification field to obtain a plurality of communication sub-packets and performs a second integrity check on the communication sub-packets according to check codes of the communication sub-packets in a case where the merge packet passes the first integrity check, and performs data processing on the communication sub-packets in a case where the communication sub-packets pass the second integrity check.

2. The data communication method according to claim 1, characterized by, The splicing of the communication sub-packets to the merge identification field in the transmission order and the addition of the frame check sequence to the tail of the last communication sub-packet to generate the merge packet comprise: performing data length determination on the plurality of communication sub-packets; storing the communication sub-packets in a merge cache queue in a case where data lengths of the communication sub-packets are less than or equal to a preset threshold; splicing the communication sub-packets in the merge cache queue to the merge identification field in the transmission order and adding a frame check sequence to a tail of a last communication sub-packet to generate a merge packet in a case where a number of communication sub-packets in the merge cache queue reaches a preset number or a waiting time of a first communication sub-packet in the merge cache queue exceeds a preset time length.

3. The data communication method according to claim 2, characterized by, The method further comprises: in a case where a data length of the communication sub-packet is greater than a preset threshold, regarding the communication sub-packet as an independent communication packet; adding an Ethernet frame header before the independent communication packet and adding a frame check sequence after the independent communication packet and sending the independent communication packet to the receiving end.

4. A data communication method applied to a receiving end, characterized in that, The method comprises: acquiring a merge packet sent by a sending end; extracting a frame check sequence at a tail of the merge packet to perform a first integrity check on the merge packet; in a case where the merge packet passes the first integrity check, performing sub-packet disassembly on the merge packet according to a merge identification field to obtain a plurality of communication sub-packets; extracting check codes at tails of the communication sub-packets to perform a second integrity check on the communication sub-packets; in a case where the communication sub-packets pass the second integrity check, parsing the communication sub-packets into data packets to submit upper layer protocol processing to perform data processing on the communication sub-packets.

5. The data communication method according to claim 4, characterized by, The method further comprises: in a case where the merge packet does not pass the first integrity check, discarding the merge packet and sending a merge packet retransmission request to the sending end.

6. The data communication method according to claim 4, characterized by, The method further comprises: in a case where the communication sub-packet does not pass the second integrity check, regarding the communication sub-packet as an abnormal communication sub-packet; sending a retransmission request of the abnormal communication sub-packet to the sending end.

7. A data communication device applied to a sending end, characterized in that, The apparatus comprises: a data packet acquisition module configured to acquire a plurality of data packets generated by an upper layer application; The communication sub-packet construction module is configured to construct a communication sub-packet corresponding to each data packet according to the data length, data content and check code of the data packet. The encapsulation module is configured to extract an Ethernet frame header and insert a merging identification field after the Ethernet frame header. The merging module is configured to splice the communication sub-packets to the merging identification field in a transmission order and add a frame check sequence to the tail of the last communication sub-packet to generate a merging packet. The sending module is configured to send the merging packet to a receiving end.

8. A data communication device applied to a receiving end, characterized in that, The apparatus comprises: The acquisition module is configured to acquire a merging packet sent by a sending end. The first integrity check module is configured to extract a frame check sequence at the tail of the merging packet and perform a first integrity check on the merging packet. The merging packet disassembling module is configured to, in the case that the merging packet passes the first integrity check, perform sub-packet disassembling on the merging packet according to a merging identification field to obtain a plurality of communication sub-packets. The second integrity check module is configured to extract a check code at the tail of each communication sub-packet to perform a second integrity check on the communication sub-packet. The communication sub-packet processing module is configured to, in the case that the communication sub-packet passes the second integrity check, parse the communication sub-packet into a data packet to submit to upper-layer protocol processing to perform data processing on the communication sub-packet.

9. A data communication system, characterized by The apparatus comprises: A sending end and a receiving end. The sending end is configured to acquire a plurality of data packets generated by an upper-layer application. A communication sub-packet corresponding to each data packet is constructed according to the data length, data content and check code of the data packet. An Ethernet frame header is extracted and a merging identification field is inserted after the Ethernet frame header. The communication sub-packets are spliced to the merging identification field in a transmission order and a frame check sequence is added to the tail of the last communication sub-packet to generate a merging packet. The merging packet is sent to a receiving end. The receiving end is configured to acquire a merging packet sent by a sending end and extract a frame check sequence at the tail of the merging packet to perform a first integrity check on the merging packet.

10. A computer-readable storage medium, characterized in that, In the case that the merging packet passes the first integrity check, sub-packet disassembling is performed on the merging packet according to a merging identification field to obtain a plurality of communication sub-packets. A check code at the tail of each communication sub-packet is extracted to perform a second integrity check on the communication sub-packet. In the case that the communication sub-packet passes the second integrity check, the communication sub-packet is parsed into a data packet to submit to upper-layer protocol processing to perform data processing on the communication sub-packet. The computer-readable storage medium stores a computer program, wherein the computer program is executed by a processor to implement the steps of the data communication method according to any one of claims 1 to 3 or the data communication method according to any one of claims 4 to 6.

Images