Methods, apparatus, electronic devices and storage media for data transmission verification

Abstract

This application provides a method, apparatus, electronic device, and storage medium for data transmission verification, relating to the field of network communication technology. By allocating a unique connection identifier during the connection establishment phase between the two communicating parties, designing the sequence number field as a combination of message length information and a random number, and encapsulating the connection identifier and sequence number fields in the header and tail of the data packet respectively, while carrying a type-length-value structure message in the middle, and simultaneously verifying the consistency of the connection identifier and sequence number fields in the header and tail after decapsulating the received packet, if the verification fails, the current connection is terminated and a new connection is established to retransmit the data. Therefore, it can solve the problems in the prior art where RoCE data transmission is prone to packet loss, data tampering, or errors, and where traditional verification methods have high computational complexity, large bandwidth consumption, and traditional retransmission methods easily lead to system performance degradation or system anomalies caused by accessing incorrect memory addresses.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and in particular to a method and apparatus for data transmission verification, an electronic device, and a storage medium. Background Technology

[0002] RoCE (RDMA over Converged Ethernet), a crucial protocol for high-performance network communication, is widely used in scenarios with stringent requirements for low latency and high throughput, such as data centers, cloud computing, and distributed computing. This technology enables remote memory access without host CPU intervention by coordinating Ethernet with RDMA (Remote Direct Memory Access), significantly improving data transmission efficiency. Specifically, the RoCE protocol covers the entire process from data encapsulation and transmission control to error detection, including key aspects such as connection management, data verification, and sequence number control. Among these, data integrity verification and fast retransmission mechanisms are core supporting technologies for ensuring stable system operation, directly impacting the reliability and real-time performance of data transmission.

[0003] However, existing RoCE data transmission methods directly employ traditional verification mechanisms (such as CRC checksums) to verify data content. This not only incurs high computational complexity but also makes verification prone to failure in high-voltage network environments due to link switching, port failures, or data tampering, leading to system anomalies. Furthermore, existing retransmission mechanisms typically rely on source-end confirmation; the destination end may fail to respond promptly after detecting an error, potentially resulting in erroneous data being written to memory and causing system crashes. Since RoCE directly accesses memory based on RDMA, continued transmission during connection failures can easily lead to accessing incorrect addresses, resulting in irreversible failures. Therefore, achieving efficient data verification and rapid connection recovery without increasing computational overhead has become a key challenge in current RoCE protocol optimization. Summary of the Invention

[0004] This application provides a method, apparatus, electronic device, and storage medium for data transmission verification, aiming to at least partially solve one of the technical problems in the related art.

[0005] This application provides a method for data transmission verification, including:

[0006] During the connection establishment phase between the two communicating parties, a unique connection identifier is assigned to each party, and a sequence number field is predefined in the data packet. The sequence number field is generated by combining message length information with a random number.

[0007] In response to the transmission of the data packet, the connection identifier and the sequence number field are encapsulated in the header and footer of the data packet, respectively, and a type-length-value structure message is carried in the middle of the data packet;

[0008] The received data packets are decapsulated, and the connection identifier and sequence number fields in the header and trailer are checked to see if they are consistent. If they are inconsistent, the packet is judged to be abnormal.

[0009] If the verification fails, the receiver sends an error notification to the sender, terminates the current connection, and triggers the sender to re-establish the connection for data retransmission.

[0010] This application also provides a data transmission verification apparatus, comprising:

[0011] The allocation unit is used to allocate a unique connection identifier to both communicating parties during the connection establishment phase, and to predefine a sequence number field in the data packet, wherein the sequence number field is generated by combining message length information and a random number;

[0012] An encapsulation unit is configured to encapsulate the connection identifier and the sequence number field in the header and trailer of the data packet respectively in response to the transmission of the data packet, and carry a type-length-value structure message in the middle of the data packet;

[0013] The verification unit is used to decapsulate the received data packets and verify whether the connection identifier and sequence number fields in the header and trailer are consistent. If they are inconsistent, the packet is judged to be abnormal.

[0014] The retransmission unit is used to send an error notification to the sender if the verification fails, terminate the current connection, and trigger the sender to re-establish the connection for data retransmission.

[0015] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above methods.

[0016] 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 methods.

[0017] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above methods.

[0018] This application provides a method, apparatus, electronic device, and storage medium for data transmission verification. By allocating a unique connection identifier during the connection establishment phase between the communicating parties, designing the sequence number field as a combination of message length information and a random number, and encapsulating the connection identifier and sequence number fields in the header and tail of the data packet respectively, while carrying a type-length-value structure message in the middle, and simultaneously verifying the consistency of the connection identifier and sequence number fields in the header and tail after decapsulating the received packet, if the verification fails, the current connection is terminated and a new connection is established to retransmit the data. Therefore, it can solve the problems in the prior art where RoCE data transmission is prone to packet loss, data tampering, or errors (such as the source end believing the transmission is complete but the destination end has not received it), and where traditional verification methods (such as TCP / IP checksums) have high computational complexity and large bandwidth consumption, and traditional retransmission methods can easily lead to system performance degradation or access to incorrect memory addresses causing system anomalies. This achieves the technical effects of effectively verifying data packet integrity, reducing verification computational complexity, reducing bandwidth consumption, ensuring data retransmission security to avoid system anomalies, and improving data transmission reliability and system performance.

[0019] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0020] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0021] Figure 1 A flowchart illustrating a data transmission verification method provided in an embodiment of this application;

[0022] Figure 2 This is a schematic diagram of a data transmission verification device provided in an embodiment of this application. Detailed Implementation

[0023] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0024] 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.

[0025] The specific application environment architecture or specific hardware architecture on which the execution of the data transmission verification method depends is described here.

[0026] Embodiments of this application provide a method for data transmission verification. Figure 1 This is a flowchart illustrating a data transmission verification method provided in an embodiment of this application.

[0027] like Figure 1 As shown, the method includes the following steps:

[0028] Step 101: During the connection establishment phase between the two communicating parties, a unique connection identifier is assigned to each party, and a sequence number field is predefined in the data packet. The sequence number field is generated by combining message length information with a random number.

[0029] In this embodiment, step 101 focuses on configuring key information during the connection establishment phase between the two communicating parties. The specific implementation process is as follows: First, after the two communicating parties (such as the client and the server) initiate a ROCE connection establishment request, a unique connection identifier (i.e., connection ID) needs to be assigned to this connection through a preset connection management mechanism. Here, "unique" specifically means that within the network coverage of the current communication link and associated devices, this connection identifier will not be duplicated with the identifiers of other ROCE connections of the same time or type. Its function is to accurately identify the dedicated data transmission channel of specific communicating parties, providing a core basis for subsequent data packet attribution verification and avoiding data mistransmission or misjudgment caused by connection identifier confusion.

[0030] Meanwhile, a sequence number field (SEQ field) needs to be predefined in the data packet to be transmitted. The generation rule for this field is clearly defined as "a combination of message length information and a random number". Here, "message length information" refers to the total number of data bytes in the current data packet to be transmitted, including the total length of subsequent business data and necessary control information; "random number" is generated by the communication initiator using a random number generation algorithm that conforms to cryptographic security standards, ensuring that each generated random number is unpredictable and unique, and forms the final sequence number field with the message length information in a preset encoding format (such as binary concatenation, specific delimiter combination, etc.).

[0031] By completing the allocation of a unique connection identifier and the predefinition of the sequence number field during the connection establishment phase, a basic identity identification and data sequence verification framework can be established before the formal start of data transmission. This provides a prerequisite for the subsequent encapsulation, transmission, and verification of data packets, ensuring that data transmission has a clear identification and verification foundation from the initial stage.

[0032] The unique connection identifier can avoid confusion of data packets from different ROCE connections. The combination generation method of the sequence number field does not rely on data content calculation (such as traditional CRC check), which reduces the computational complexity of the initial field generation. At the same time, the introduction of random numbers improves the security of the sequence number, reduces the risk of malicious tampering or forgery, and lays the foundation for the accuracy and security of subsequent data transmission.

[0033] Step 102: In response to the data packet transmission, the connection identifier and sequence number fields are encapsulated in the header and trailer of the data packet, respectively, and a type-length-value structure message is carried in the middle of the data packet.

[0034] In this embodiment, step 102 is a crucial step connecting data packet generation and transmission, and the specific operation revolves around the structured encapsulation of the data packet. When the system triggers a data packet sending command (i.e., in response to a data packet sending request), the prepared raw data packet first needs to undergo multi-field encapsulation processing: the unique connection identifier allocated during the connection establishment phase and the predefined sequence number field need to be embedded into the header and trailer areas of the data packet respectively, according to the ROCE data transmission protocol encapsulation specification. Here, the "header" refers to the starting byte segment of the data packet, which is the part that the receiving end reads first when parsing the packet, and the "trailer" refers to the last byte segment of the packet. Both embed the connection identifier and sequence number fields, forming a "double identifier at the beginning and end" structure. This structure ensures that the receiving end can quickly obtain core verification information from either the beginning or the end position during the packet parsing process, reducing the verification failure problem caused by damage to a single identifier position.

[0035] Simultaneously, a Type-Length-Value (TLV) structure message must be carried in the middle area of ​​the data message. The "Type" field specifies the exact category of the content carried by the current data message, such as a business data message or a control command message, helping the receiver quickly identify the message's purpose. The "Length" field indicates the total byte length of the TLV structure itself and subsequent associated data, providing a basis for the receiver to accurately truncate TLV-related data and avoiding field overflow or incomplete truncation during data parsing. The "Value" field stores the specific data content corresponding to the "Type," such as the actual business information for a business data message or the operation command parameters for a control command message. The length of the "Value" field must be consistent with the value indicated by the "Length" field to ensure the integrity and validity of the TLV structure.

[0036] The entire encapsulation process must strictly adhere to the underlying protocol format requirements of ROCE data transmission, ensuring that the byte offsets and encoding formats of each field in the header, middle, and trailer are consistent. This prevents the receiving end from being unable to parse the data correctly due to non-standard encapsulation formats. Through this structured encapsulation, the data packet carries complete identification and content description information before transmission, providing clear data structure support for subsequent verification and parsing by the receiving end.

[0037] The dual encapsulation at the beginning and end connects the identifier and sequence number fields, improving the redundancy and security of core verification information and reducing the risk of verification failure due to damage to a single field. The middle TLV structure can clearly define the message content attributes and data range, helping the receiving end to efficiently complete message classification and data interception, reducing parsing time, and improving the standardization of data message transmission and the efficiency of subsequent processing.

[0038] Step 103: Decapsulate the received data packet and verify whether the connection identifier and sequence number fields in the header and trailer are consistent. If they are inconsistent, the packet is determined to be abnormal.

[0039] In this embodiment, step 103 is the core verification step to ensure the accuracy of data reception. The specific operation revolves around the decapsulation of the data packet and the consistency verification of key fields by the receiving end. When the receiving end (such as the server or client) receives the data packet through the ROCE network link, it first needs to perform the decapsulation operation in reverse according to the preset encapsulation format. That is, based on the field offsets and encoding rules of the data packet header, middle, and tail, it gradually extracts the header connection identifier, header sequence number field, tail connection identifier, tail sequence number field, and the TLV structure message encapsulated at the sending end. During this process, it is necessary to ensure that the decapsulation tool or module can accurately identify the boundaries of each field to avoid affecting the subsequent verification results due to field extraction errors.

[0040] After decapsulation, the receiving end will enter the critical consistency verification phase. The verification focuses on two sets of core information: the connection identifier in the header and the sequence number field in the header and the sequence number field in the tail. On the one hand, it compares whether the character sequence or value of the connection identifier in the header and the connection identifier in the tail are completely the same. Since the connection identifier is the unique identifier of the connection between the two communicating parties, if the beginning and end are inconsistent, it means that the message may have been tampered with, fragments lost, or spliced ​​out of order during transmission, and cannot accurately match the current communication connection. On the other hand, it compares whether the combined content of the sequence number field in the header and the sequence number field in the tail (including message length information and random number) is completely consistent. The sequence number field is an important identifier of the order and integrity of the data message. If the beginning and end are inconsistent, it means that the message may have problems such as data fragment replacement or length information tampering.

[0041] If either of the two sets of fields is inconsistent, the receiving end will directly determine that the data packet is an abnormal packet. At this time, the subsequent TLV structure parsing and business data processing of the packet will be suspended to prevent abnormal data from entering the subsequent business process and causing system errors. If both sets of fields are completely consistent, the packet is determined to have passed the initial verification and can proceed to the next stage for further processing of the TLV structure message and business data.

[0042] By verifying the consistency of the first and last fields after decapsulation, it is possible to quickly identify tampering, loss, or out-of-order issues in data packets during transmission. Compared with traditional verification methods that rely on only a single field or data content, the verification logic is simpler and more efficient. It can intercept abnormal packets before data enters business processing, reduce the impact of abnormal data on the receiving system, and ensure the accuracy and security of ROCE data transmission.

[0043] Step 104: If the verification fails, the receiver sends an error notification to the sender, terminates the current connection, and triggers the sender to re-establish the connection for data retransmission.

[0044] In this embodiment, step 104 is a key processing step for verification failure scenarios. The core of this step is to avoid data transmission risks through a clear exception response mechanism. When the receiving end completes the verification in step 103 and determines that the message is abnormal (i.e., the connection identifier and sequence number fields in the header and trailer are inconsistent), it will immediately initiate a preset exception handling process: First, the receiving end will generate an error notification message containing key information such as the exception type (e.g., inconsistent fields) and the current connection identifier according to the message format specified by the ROCE protocol. This notification will be transmitted to the data sender through the original communication link to ensure that the sender can promptly learn about the verification failure result and related context, thus avoiding the sender from continuously waiting or repeatedly sending invalid data due to not receiving confirmation.

[0045] Next, the receiving end will actively terminate the current ROCE connection. Specific operations include releasing the local network resources occupied by the connection (such as ports and cache space), clearing the identification information associated with the connection (such as connection identifiers and sequence number records), and stopping the monitoring of data that may be transmitted by the connection in the future, so as to prevent abnormal connections from continuously occupying resources or receiving more invalid messages, which would affect the transmission efficiency of other normal ROCE connections.

[0046] Meanwhile, error notifications sent by the receiving end trigger the sender to re-establish the connection. Upon receiving the error notification, the sender first terminates the current connection and releases related resources. Then, following the standard ROCE connection establishment process, it re-initiates a connection request to the receiving end. Once the new connection is established (including reallocating a unique connection identifier and predefining a new sequence number field), it re-encapsulates and transmits the previously failed data packets, ensuring reliable data transmission through the new valid connection. Timely error notifications and connection termination prevent abnormal connections from consuming resources and reduce the waste of network bandwidth caused by invalid data transmission. Triggering connection re-establishment instead of direct retransmission avoids the risk of incorrect address access that may result from ROCE's direct memory access based on RDMA, preventing system anomalies. Furthermore, re-establishing the connection ensures the validity of subsequent data transmission, improving the overall reliability of data transmission.

[0047] This application provides a method for data transmission verification. By allocating a unique connection identifier during the connection establishment phase between the communicating parties, designing the sequence number field as a combination of message length information and a random number, and encapsulating the connection identifier and sequence number fields in the header and tail of the data packet respectively, while carrying a type-length-value structure message in the middle, and simultaneously verifying the consistency of the connection identifier and sequence number fields in the header and tail after decapsulating the received packet, if the verification fails, the current connection is terminated and a new connection is established to retransmit the data. Therefore, it can solve the problems in existing technologies where RoCE data transmission is prone to packet loss, data tampering, or errors (e.g., the source end believes the transmission is complete but the destination end has not received it), and where traditional verification methods (such as TCP / IP checksums) have high computational complexity and large bandwidth consumption, and traditional retransmission methods can easily lead to system performance degradation or access to incorrect memory addresses causing system anomalies. This method achieves the technical effects of effectively verifying data packet integrity, reducing verification computational complexity, reducing bandwidth consumption, ensuring data retransmission security to avoid system anomalies, and improving data transmission reliability and system performance.

[0048] Furthermore, within the framework of the technical solution disclosed in the foregoing embodiments, this implementation is further specified as follows: the connection identifier is generated by negotiation between the two communicating parties when the connection is established, and remains unchanged throughout the entire connection lifecycle.

[0049] Specifically, when the two communicating parties (such as the client and the server) initiate the ROCE connection establishment process, the connection identifier is not assigned by a single device, but is generated through interactive negotiation between the two parties: the connection initiator first generates a candidate identifier based on network environment parameters (such as device IP and port number) and sends it to the receiver; the receiver checks whether the candidate identifier conflicts with the existing local connection identifier. If there is no conflict, it sends back a confirmation message; if there is a conflict, it proposes an adjustment suggestion. The two parties repeat the negotiation until a unique and conflict-free connection identifier is determined.

[0050] Furthermore, once generated, this connection identifier remains fixed throughout the entire connection lifecycle—the connection lifecycle refers to the entire process from the moment both parties confirm the establishment of the connection to the normal disconnection after data transmission is completed, or the termination of the connection due to an anomaly (such as a verification failure). During this period, regardless of how many rounds of data packets are transmitted, the same connection identifier is used, without the need for repeated generation or modification.

[0051] Furthermore, within the technical framework disclosed in the foregoing embodiments, this implementation is further specified as follows: the random number in the sequence number field is generated incrementally according to a preset rule each time a data packet is sent, so as to ensure its uniqueness and order.

[0052] Specifically, each time a data packet transmission operation is triggered, instead of randomly generating an unrelated random number, the random number is generated incrementally according to a preset rule. This "preset rule" can be set according to actual transmission needs, such as increasing by a fixed step size (e.g., incrementing by 1, 5, etc. each time), or calculating the increment value based on the previous random number combined with the current timestamp segment, ensuring that each generated random number is both sequentially related to the previous one and does not repeat. This incremental generation method allows the sequence number field to possess both uniqueness and orderliness: uniqueness is reflected in the fact that the random number for each transmitted packet is unique, avoiding sequence number conflicts; orderliness is achieved through the incremental relationship, assisting the receiving end in determining the order in which data packets are sent, providing a reference for subsequent possible packet sorting or packet loss detection.

[0053] Furthermore, within the framework of the technical solution disclosed in the foregoing embodiments, this implementation is further specified as follows: the connection identifier and sequence number fields in the header and footer are encapsulated in a fixed-length binary format to improve message parsing efficiency.

[0054] Specifically, when encapsulating these two types of fields, a fixed-length binary format is uniformly adopted: first, based on the bandwidth requirements of ROCE data transmission, the device processing capability, and the verification accuracy requirements, the fixed byte length of the connection identifier and sequence number fields is preset (e.g., the connection identifier is set to 8 bytes, the sequence number field is set to 16 bytes, etc.), and then the original data of the two types of fields is converted into binary data of the corresponding length according to the binary encoding rules and embedded in the specified positions of the header and footer of the data packet.

[0055] This fixed-length binary format allows the receiving end to extract field content directly by truncating data to the preset length without needing to additionally parse the field length information during decapsulation, significantly reducing the calculation and judgment steps in the parsing process.

[0056] Furthermore, within the technical framework disclosed in the foregoing embodiments, this implementation is further specified as follows: the type field in the type-length-value structure message is used to identify the message type, the length field is used to indicate the data length, the value field is used to carry the actual data content, and supports extensible message type definitions.

[0057] Specifically, the type field, as the core identifier of the TLV structure, clarifies the specific category of the message carried by the current data packet. For example, message types can be divided into business data messages, connection control messages, error feedback messages, etc. By reading the value of this field, the receiving end can quickly determine the purpose of the message and provide a basis for subsequent targeted processing.

[0058] The length field precisely indicates the total byte length of the "value field" and associated data in the current TLV structure. The receiving end can accurately truncate data segments of the corresponding length based on this field value, avoiding parsing errors caused by data being too long or too short, and ensuring the integrity of the extracted data. The value field is the core data-carrying area of ​​the TLV structure, used to store the actual content corresponding to the "type field," such as the specific business data of business data messages and the operation command parameters of control messages.

[0059] Meanwhile, the TLV structure supports extensible message type definitions. When new business scenarios require the addition of new message types, there is no need to reconstruct the overall TLV structure. You only need to add the corresponding identifier value in the type field and match the defined length rules and value field data format to adapt to the expansion of different business needs.

[0060] Furthermore, within the technical framework disclosed in the foregoing embodiments, this implementation is further specified as follows: the verification step further includes: if the header connection identifier does not match the current connection, then the data packet is directly discarded.

[0061] Specifically, after the receiving end decapsulates the received message and extracts the header connection identifier, it will add an extra step of "connection matching verification": the extracted header connection identifier will be compared one by one with the connection identifiers corresponding to the ROCE connections that the receiving end has established and are currently active, to determine whether the header connection identifier belongs to any valid connection at present.

[0062] If the comparison result shows that the header connection identifier does not match the identifiers of all currently active connections, it indicates that the packet may belong to an erroneous connection, an expired connection, or an illegally forged packet. In this case, the receiving end does not need to continue to perform subsequent tail field verification and other operations, but directly discards the data packet according to the preset rules, and does not return any additional response to the sender except for necessary error logs, so as to avoid invalid interaction occupying network resources.

[0063] Furthermore, within the technical framework disclosed in the foregoing embodiments, this implementation is further specified as follows: if the sequence number fields of the header and the tail are inconsistent, the sequence number range of the abnormal message is recorded, and the information is fed back to the sender for data consistency recovery during subsequent connection reconstruction.

[0064] Specifically, when the receiving end decapsulates the data packet and finds that the sequence number field in the header is inconsistent with the sequence number field in the tail, it does not simply determine that the packet is abnormal, but also initiates an abnormal information recording process: first, it extracts the sequence number field of the abnormal packet (including message length information and random number), determines its corresponding sequence number value range, and then stores the key information of the abnormal packet in the format of timestamp, current connection identifier, abnormal type (sequence number inconsistency) and sequence number range through the local preset log recording module, to ensure that abnormal data is traceable.

[0065] After recording is complete, the receiving end will integrate the information including the "abnormal message sequence number range" into the error notification that was previously to be sent, and transmit it to the sending end together. The core function of this sequence number range information is to provide a basis for the sending end's subsequent operations after re-establishing the connection—after receiving this information, the sending end can clearly know which range of sequence numbers corresponds to the abnormal message transmission. After the new connection is established, it only needs to re-encapsulate and transmit the data packets corresponding to that sequence number range, without retransmitting all the data, thus achieving accurate data consistency recovery.

[0066] Recording and reporting the range of abnormal message sequence numbers can help the sender accurately locate the data that needs to be retransmitted after the connection is rebuilt, avoiding bandwidth waste and increased latency caused by invalid data retransmission. At the same time, the traceability of abnormal information also provides data support for subsequent investigation of the cause of transmission abnormalities (such as link instability or field tampering), further improving the efficiency of data transmission and the convenience of problem investigation.

[0067] Furthermore, within the technical framework disclosed in the foregoing embodiments, this implementation is further specified as follows: the error notification carries an exception type identifier, which is used by the sender to distinguish the cause of the error and take corresponding processing strategies.

[0068] Specifically, when the receiving end determines that the message verification has failed and needs to send an error notification to the sending end, it will additionally carry an "exception type identifier" in the notification. This identifier is a predefined encoded value based on the specific reason for the verification failure. For example, "header and tail connection identifiers do not match" corresponds to identifier "01", "header and tail sequence number fields do not match" corresponds to identifier "02", and "header connection identifier does not match the current connection" corresponds to identifier "03". Each identifier uniquely corresponds to a verification failure scenario, and the two communicating parties have pre-agreed on the correspondence between identifiers and exception types during the connection establishment phase.

[0069] After receiving an error notification containing an exception type identifier, the sender can quickly determine the specific reason for the verification failure by directly parsing the identifier, without having to parse complex error description information: if the identifier is "01", it is determined that the connection identifier verification is abnormal, and the negotiation and encapsulation of the connection identifier should be carefully checked when rebuilding the connection; if the identifier is "02", it is determined that the sequence number field is abnormal, and it is necessary to check whether there are problems in the sequence number generation or encapsulation process, so as to take targeted processing strategies and avoid blindly implementing a uniform error handling process.

[0070] Error type identification allows the sender to quickly locate the cause of the error, reducing the time spent on error troubleshooting. At the same time, targeted handling strategies can reduce the waste of resources caused by invalid operations, further improve the efficiency of connection reconstruction and data retransmission, and ensure the continuity and stability of ROCE data transmission.

[0071] Furthermore, within the framework of the technical solution disclosed in the foregoing embodiments, this implementation method is further specified as follows: if multiple verification failure messages are received within a preset time, the abnormal frequency is counted and a network link abnormality alarm is triggered, and the network management system is notified to perform link status detection and fault investigation.

[0072] Specifically, the receiving end needs to pre-configure a "preset time" parameter (such as 30 seconds, 1 minute, etc., which can be adjusted according to network transmission stability requirements) and a "verification failure message count threshold" within that time period (such as 5 times, 10 times). During data transmission, the receiving end records the number of all verification failure messages within the preset time period in real time, forming an anomaly count.

[0073] When the preset time is reached or the anomaly count reaches the threshold, the receiver initiates anomaly frequency statistics: calculating the average number of failed verification packets per unit time (i.e., the anomaly frequency) and comparing this frequency with the preset normal frequency threshold. If the anomaly frequency exceeds the normal range, it is determined that the current network link may have a persistent fault (such as link packet loss, signal interference, etc.). At this time, the receiver triggers the network link anomaly alarm mechanism—generating alarm information in a preset format, including key data such as alarm time, current connection identifier, anomaly frequency, and failed packet type, and sending it to the network management system through the network management interface.

[0074] Upon receiving an alarm, the network management system automatically initiates a link status detection process (such as detecting link bandwidth utilization, packet loss rate, port status, etc.) and notifies maintenance personnel to troubleshoot the problem, locate and resolve the link anomaly, and prevent it from continuously affecting subsequent data transmission.

[0075] By triggering alarms through high-frequency verification failures, potential network link faults can be detected in a timely manner, preventing the faults from escalating. The alarm information provides the network management system with accurate troubleshooting information, shortens fault handling time, ensures the long-term stability of ROCE data transmission links, and reduces frequent reconnections and data transmission interruptions caused by link problems.

[0076] Furthermore, within the technical framework disclosed in the foregoing embodiments, this implementation is further specified as follows: the step of re-establishing the connection includes: after receiving the error notification, the sender immediately initiates a new connection request and resends the unacknowledged data packets in the new connection.

[0077] Specifically, when the sender receives a verification failure notification from the receiver via the ROCE network link, it will immediately trigger the process of initiating a new connection request: the sender first releases the local resources occupied by the currently terminated connection (such as ports, caches and connection identifier records), clears the configuration information related to the old connection, and then sends a connection establishment message containing a new connection request identifier and sender device information to the receiver in accordance with the standard protocol process for establishing a ROCE connection, ensuring that the new connection request can be accurately identified by the receiver.

[0078] During the establishment of a new connection, the sender simultaneously reviews "unacknowledged data packets"—that is, data packets previously sent that did not receive confirmation from the receiver after successful verification, and whose transmission was interrupted due to verification failure. The scope of these packets can be determined through locally recorded sequence numbers or transmission logs. After the sender and receiver complete the negotiation of the new connection (including reallocating a unique connection identifier and predefining a new sequence number field) and confirm the successful establishment of the connection, the sender will re-encapsulate the unacknowledged data packets according to the encapsulation rules of the new connection, processing the connection identifier and sequence number fields. Subsequently, these packets are retransmitted to the receiver through the newly established ROCE connection, ensuring that data that was not successfully transmitted can continue to be reliably transmitted.

[0079] Upon receiving an error notification, the sender immediately initiates a new connection request, shortening the interval between connection interruption and reconstruction and reducing data transmission latency. Retransmitting unacknowledged data packets avoids the loss of valid data, ensuring the integrity of data transmission. Furthermore, relying on the new connection for transmission can avoid the abnormal risks that may exist in the old connection, further improving the success rate of data retransmission.

[0080] It should be noted that the embodiments of this disclosure may include multiple steps. For ease of description, these steps are numbered, but these numbers are not a limitation on the execution time slots or execution order between the steps; these steps can be implemented in any order, and the embodiments of this disclosure do not limit this.

[0081] Corresponding to the data transmission verification method described above, this disclosure also proposes a data transmission verification apparatus. Since the apparatus embodiments of this disclosure correspond to the method embodiments described above, details not disclosed in the apparatus embodiments can be referred to the method embodiments described above, and will not be repeated here.

[0082] Figure 2 This is a schematic diagram of a data transmission verification device provided in an embodiment of the present disclosure, as shown below. Figure 2 As shown, it includes:

[0083] The allocation unit 21 is used to allocate a unique connection identifier to both communication parties during the connection establishment phase, and to predefine a sequence number field in the data packet, wherein the sequence number field is generated by combining message length information and a random number;

[0084] Encapsulation unit 22 is used to encapsulate the connection identifier and the sequence number field in the header and tail of the data packet respectively in response to the transmission of the data packet, and to carry a type-length-value structure message in the middle of the data packet;

[0085] Verification unit 23 is used to decapsulate the received data packet and verify whether the connection identifier and sequence number fields in the header and trailer are consistent. If they are inconsistent, the packet is determined to be abnormal.

[0086] The retransmission unit 24 is used to send an error notification to the sender if the verification fails, terminate the current connection, and trigger the sender to re-establish the connection for data retransmission.

[0087] It should be noted that the foregoing explanation of the method embodiments also applies to the apparatus of this embodiment, and the principle is the same, so it is not limited in this embodiment.

[0088] For a description of the features in the embodiment corresponding to the data transmission verification device, please refer to the relevant description in the embodiment corresponding to the data transmission verification method, which will not be repeated here.

[0089] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above-described methods for data transmission verification.

[0090] 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 methods for data transmission verification.

[0091] 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.

[0092] 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 methods for data transmission verification.

[0093] 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 methods for data transmission verification.

[0094] 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.

[0095] The present application provides a detailed description of a data transmission verification method, apparatus, electronic device, and storage medium. Specific examples have been used to illustrate the principles and implementation methods of the present application. The descriptions of these embodiments are merely illustrative of the method and its core concepts. It should be noted that those skilled in the art can make various improvements and modifications to the present application without departing from its principles, and these improvements and modifications also fall within the scope of protection of the claims.

Claims

1. A method of data transmission verification, characterized by, The application comprises: allocating a unique connection identifier for both parties during the connection establishment stage, and defining a sequence number field in the data packet, which is generated by combining message length information and random number; in response to the data packet sending, encapsulating the connection identifier and the sequence number field in the head and tail of the data packet respectively, and carrying a type-length-value structure message in the middle part of the data packet; decapsulating the received data packet, and checking whether the connection identifier and the sequence number field in the head and the tail are consistent, and determining that the packet is abnormal if they are inconsistent; if the checking fails, sending an error notification to the sender from the receiver, terminating the current connection, and triggering the sender to re-establish the connection for data retransmission.

2. The method of data transmission verification of claim 1, wherein, The connection identifier is generated by negotiation between both parties during the connection establishment, and remains unchanged during the entire connection life cycle.

3. The method of data transmission verification of claim 1, wherein, The random number in the sequence number field is generated by increasing according to a preset rule every time the data packet is sent, so as to ensure its uniqueness and sequence.

4. The method of data transmission verification of claim 1, wherein, The connection identifier and the sequence number field in the head and the tail are encapsulated in a fixed-length binary format, so as to improve the packet parsing efficiency.

5. The method of data transmission verification of claim 1, wherein, The type field in the type-length-value structure message is used to identify the message type, the length field is used to indicate the data length, and the value field is used to carry the actual data content, and the message type definition is supported.

6. The method of data transmission verification of claim 1, wherein, Further comprising: if the head connection identifier does not match the current connection, the data packet is directly discarded.

7. The method of data transmission verification of claim 1, wherein, if the sequence number fields in the head and the tail are inconsistent, the sequence number range of the abnormal packet is recorded, and the information is fed back to the sender, which is used for data consistency recovery during subsequent connection reconstruction.

8. The method of data transmission verification of claim 1, wherein, The error notification carries an abnormal type identifier, which is used for the sender to distinguish the error cause and adopt the corresponding processing strategy.

9. The method of data transmission verification of claim 1, wherein, If multiple packets with checking failure are received within a preset time, the abnormal frequency is counted, and a network link abnormal alarm is triggered to inform the network management system to detect the link state and troubleshoot the fault.

10. The method of data transmission verification of claim 1, wherein, The step of re-establishing the connection comprises: the sender initiates a new connection request immediately after receiving the error notification, and re-sends the unconfirmed data packet in the new connection.

11. An apparatus for data transmission verification, the apparatus comprising: The application comprises: an allocation unit for allocating a unique connection identifier for both parties during the connection establishment stage, and defining a sequence number field in the data packet, which is generated by combining message length information and random number; an encapsulation unit for encapsulating the connection identifier and the sequence number field in the head and the tail of the data packet respectively in response to the data packet sending, and carrying a type-length-value structure message in the middle part of the data packet; a checking unit for decapsulating the received data packet, and checking whether the connection identifier and the sequence number field in the head and the tail are consistent, and determining that the packet is abnormal if they are inconsistent; a retransmission unit for sending an error notification to the sender from the receiver if the checking fails, terminating the current connection, and triggering the sender to re-establish the connection for data retransmission.

12. A system for data transmission verification, characterized by The system comprises: the data transmission checking device as claimed in claim 11.

13. An electronic device, comprising: The application comprises: at least one processor; and a memory in communication with the at least one processor; wherein the memory has stored instructions executable by the at least one processor, the instructions being executable by the at least one processor to enable the at least one processor to perform the method of data transmission verification of any one of claims 1-11.

14. A non-transitory computer-readable storage medium having stored thereon computer instructions, wherein, the computer instructions are for causing the computer to perform the method of data transmission verification of any one of claims 1-11.

15. A computer program product, characterised in that, a computer program comprising instructions which, when executed by a processor, implement the method of data transmission verification of any one of claims 1-11.

Images