Data transmission method and device and electronic equipment

Abstract

The invention discloses a data transmission method and device and electronic equipment. The method is applied to a data sending end and comprises the steps that a user datagram protocol UDP message sent by a data receiving end is acquired, and the UDP message at least comprises message header data and a data packet type; performing dual verification on the message header data and the data packet type to obtain a verification result; under the condition that the verification result indicates that the UDP message is successfully verified, a response message is sent to the data receiving end, and the response message is used for indicating that handshake between the data sending end and the data receiving end is successful; and transmitting the data requested by the data receiving end to the data receiving end through a remote direct memory access (RDMA) protocol. According to the scheme provided by the invention, data transmission can be realized on the FPGA side, and the complexity of data transmission is reduced.

Description

Technical Field

[0001] The present application belongs to the field of data transmission technology, and in particular relates to a data transmission method, device and electronic equipment. Background Art

[0002] FPGAs (Field Programmable Gate Arrays) and CPUs (Central Processing Units) are integral components of radar signal processing. In related technologies, FPGAs are used for front-end processing, while CPUs are used for back-end processing. Data transmission is required between the FPGA and CPU.

[0003] After a successful handshake between the FPGA and the CPU, data can be transmitted between the data transmitter (i.e., the FPGA) and the data receiver (i.e., the CPU). In related technologies, handshake and synchronization typically utilize sockets based on the TCP / IP (Transmission Control Protocol / Internet Protocol). However, the TCP / IP protocol stack is complex, requiring multiple state transitions when starting and ending communication. Implementing data transmission using FPGAs is challenging, making it unsuitable for practical deployment. Summary of the Invention

[0004] The embodiments of the present application provide a data transmission method, apparatus, and electronic device, which can implement data transmission on the FPGA side and reduce the complexity of data transmission.

[0005] In a first aspect, an embodiment of the present application provides a data transmission method, which is applied to a data sending end, and the method includes: obtaining a User Datagram Protocol (UDP) message sent by a data receiving end, wherein the UDP message includes at least message header data and a data packet type; performing a double check on the message header data and the data packet type to obtain a check result; when the check result indicates that the UDP message check is successful, sending a response message to the data receiving end, wherein the response message is used to indicate that the handshake between the data sending end and the data receiving end is successful; and transmitting the data requested by the data receiving end to the data receiving end through the Remote Direct Memory Access (RDMA) protocol.

[0006] In the second aspect, an embodiment of the present application provides a data transmission device, which is applied to a data sending end, and the device includes: a message acquisition module, which is used to obtain a User Datagram Protocol UDP message sent by a data receiving end, wherein the UDP message includes at least message header data and a data packet type; a verification module, which is used to perform a double check on the message header data and the data packet type to obtain a verification result; a message response module, which is used to send a response message to the data receiving end when the verification result indicates that the UDP message verification is successful, wherein the response message is used to indicate that the handshake between the data sending end and the data receiving end is successful; a data transmission module, which is used to transmit the data requested by the data receiving end to the data receiving end through the Remote Direct Memory Access RDMA protocol.

[0007] In a third aspect, an embodiment of the present application provides an electronic device comprising: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, the data transmission method as described in the first aspect is implemented.

[0008] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having computer program instructions stored thereon. When the computer program instructions are executed by a processor, the data transmission method as described in the first aspect is implemented.

[0009] In a fifth aspect, an embodiment of the present application provides a computer program product. When the instructions in the computer program product are executed by a processor of an electronic device, the electronic device executes the data transmission method as described in the first aspect.

[0010] As can be seen from the above, in the embodiments of the present application, UDP is used to implement handshakes and data synchronization between the data sender and the data receiver. Compared to the TCP / IP protocol, the UDP protocol is connectionless, and there is no time delay required to establish a connection. In terms of space, there is no need to maintain the connection state, nor is there a need to track connection parameters. This reduces the difficulty of using FPGAs to implement data transmission, making it possible to implement handshakes and data synchronization through FPGAs. In addition, in the embodiments of the present application, a double check method is used to double-check UDP messages, so that the accuracy of the handshake process and the accuracy of data transmission can be guaranteed without multiple state switching at the beginning and end of communication. This not only makes up for the shortcomings of the UDP protocol in terms of reliability compared to the TCP\IP protocol, but also reduces the complexity of data transmission. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0012] Figure 1 It is a schematic diagram of data transmission in the related art;

[0013] Figure 2 It is a data transmission interaction diagram between a data receiving end and a data sending end in the related art;

[0014] Figure 3 This is a flowchart of a data transmission method provided by an embodiment of the present application;

[0015] Figure 4 This is a schematic diagram of data transmission provided by an embodiment of the present application;

[0016] Figure 5 This is a state transition diagram of an arbitration state machine of a data sending end provided by an embodiment of the present application;

[0017] Figure 6 This is a state transition diagram of a UDP message parsing state machine at a data sending end provided by one embodiment of the present application;

[0018] Figure 7 This is a schematic diagram of the interaction between a data sending end and a data receiving end provided by an embodiment of the present application;

[0019] Figure 8 is a structural diagram of a data transmission device provided by another embodiment of the present application;

[0020] Figure 9 This is a structural diagram of an electronic device provided in yet another embodiment of the present application. DETAILED DESCRIPTION

[0021] The features and exemplary embodiments of various aspects of the present application will be described in detail below. In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, rather than to limit the present application. For those skilled in the art, the present application can be implemented without the need for some of these specific details. The following description of the embodiments is merely to provide a better understanding of the present application by illustrating the examples of the present application.

[0022] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, the elements defined by the phrase "comprising..." do not exclude the presence of other identical elements in the process, method, article, or device comprising the elements.

[0023] For ease of understanding, before explaining the solution provided in this application, the background involved in the solution provided in this application is first introduced.

[0024] FPGAs and CPUs are integral components of radar signal processing. Typically, FPGAs are used for front-end processing, while CPUs are used for back-end processing. As radar systems increase in channel count and signal bandwidth increases, the demand for data transmission bandwidth between the FPGA and CPU is rapidly increasing. To this end, RDMA (Remote Direct Memory Access) technology is used in related technologies to achieve data transmission. RDMA can access and transmit data without the CPU participating in the actual data transmission (for example, it only sends and receives messages without processing them), thereby reducing network transmission latency.

[0025] In RDMA technology, data exchange between the data transmitter and receiver's queue pair (QP) can only take place via the RDMA protocol after a handshake. During the handshake, the two ends exchange parameters necessary for subsequent RDMA communication. The handshake is essential for formal RDMA communication. Therefore, implementing a reliable handshake on the FPGA is crucial for RDMA data transmission. The handshake mechanism must not only ensure ease of connection but also ensure the stability and accuracy of the handshake results.

[0026] Furthermore, during data transmission, the data transmitter can directly access and transfer data from the receiver's memory without the CPU's involvement, achieving high bandwidth and low latency. Because both the transmitter and receiver's CPUs can access the receiver's memory, this raises the issue of data consistency. Developers need to implement appropriate synchronization mechanisms to ensure data consistency. Therefore, implementing a simple and efficient synchronization mechanism on the FPGA is crucial for correct data transmission.

[0027] At present, the handshake methods commonly used by RDMA applications include the handshake method based on TCP / IP Socket and the handshake method based on CM (Communication Manager / Management). The handshake method based on TCP / IPSocket is implemented based on the TCP / IP protocol. In the handshake method based on CM, CM link establishment has certain particularities. For IB (RDMA technology based on InfiniBand architecture) / RoCE (RDMA technology based on Ethernet), it is based on the IB transport layer + CM protocol described in the IB specification; and for iWARP (RDMA technology based on TCP / IP protocol), it is based on the process described in TCP+IETF RFC 5044 / 6581. For the above two handshake methods, the entire transmission system needs to provide a separate hardware link that supports TCP / IP or CM protocol for handshake before data transmission during design. For example, in Figure 1 In the related art shown in the data transmission diagram, two communication links are deployed between the data transmitter and the data receiver: a handshake synchronization link and a data link. The handshake synchronization link is used to implement the handshake before data transmission, and the data link is used to implement data transmission after the handshake is successful. This approach increases the hardware cost and design complexity of the entire system. In addition, for FPGA devices, using RTL (Hardware Description Language) to implement a complete TCP / IP protocol stack is a huge workload and consumes a lot of resources.

[0028] Currently, the mainstream synchronization mechanism for RDMA applications is also implemented based on TCP / IP Sockets. For FPGA devices, this also has problems such as complex implementation, high resource consumption, and lack of cost-effectiveness.

[0029] In related technologies, handshake and synchronization methods use methods such as SOCKET based on TCP / IP protocol, and the protocol stack is complex, such as Figure 2 The data transmission interaction diagram between the data receiving end and the data sending end is shown in FIG. Figure 2It can be seen that in related technologies, data transmission between the data receiving end and the data sending end (i.e., the FPGA side) mainly includes four steps:

[0030] In step S201, the data receiving end broadcasts an ARP (Address Resolution Protocol) message, and the data sending end replies with an ARP response message, wherein the ARP response message includes the MAC (Media Access Control) address of the data sending end.

[0031] Step S202: The data receiving end and the data sending end perform a three-way handshake to establish a connection.

[0032] Specifically, the data receiving end sends a request message SYN_SENT to the data sending end to request to establish a connection; the data sending end returns a response message SYN_RECV to confirm the SYN on the FPGA side and request to establish a connection; the data receiving end responds to the SYN and returns a response message to the data sending end; after receiving the response message, the data sending end establishes a connection between the data sending end and the data receiving end.

[0033] Step S203: An RDMA handshake is performed between the data sending end and the data receiving end.

[0034] Specifically, the data receiving end sends RDMA handshake information to the data sending end; the data sending end feeds back a response message of the RDMA handshake information to the data receiving end.

[0035] Step S204: The data sending end transmits data to the data receiving end.

[0036] Step S205: The data sending end and the data receiving end perform a hand-waving operation to disconnect.

[0037] Specifically, the data receiving end sends a connection disconnection request to the data sending end, the data sending end confirms the FIN of the client and sends a connection disconnection request to the data receiving end; the data receiving end confirms the FIN of the server.

[0038] Depend on Figure 2 As you can see, due to the TCP / IP protocol, communication requires a three-way handshake. This means that establishing a TCP connection requires the data receiver and sender to send a total of three messages. The purpose of this three-way handshake is to connect to the designated port on the FPGA, establish a TCP connection, synchronize sequence numbers and acknowledgment numbers on both sides, and exchange TCP window size information. In socket programming, the client triggers the three-way handshake by executing the connect() function.

[0039] After the communication is complete, four handshakes are required to terminate the TCP connection. This means that when a TCP connection is disconnected, the client and server must send a total of four data packets to confirm the disconnection. In socket programming, this process is triggered by either the client or the server executing the close() function. Because TCP connections are full-duplex, each direction must be closed separately. When one party (for example, the data receiver) completes its data transmission task, it sends a FIN to terminate the connection in that direction. When the other party (for example, the data sender) receives a FIN, it only means that there is no data flowing in that direction, meaning that no more data will be received. However, data can still be sent on this TCP connection. For example, the other party can send data to the first party through the TCP connection until the first party also sends a FIN. The party that closes first performs an active close, while the other party performs a passive close.

[0040] It can be seen from this that the TCP / IP protocol stack is very complex, and there are many state switches involved when starting and ending communication. It is difficult to implement using FPGA and has no value for actual deployment.

[0041] In terms of hardware, the traditional method requires the design of a separate handshake link in addition to the data link, such as Figure 1 As shown, this approach increases the hardware cost of the entire system and also increases the complexity of the entire system design.

[0042] Based on the above introduction, it can be seen that how to efficiently implement the RDMA handshake and synchronization process in FPGA and reduce the complexity of the entire RDMA transmission system is an urgent problem to be solved by those skilled in the art.

[0043] To address the problems of the prior art, embodiments of the present application provide a data transmission method, apparatus, and electronic device. The following first describes the data transmission method provided by embodiments of the present application. The method can be applied to a data transmitter, which is deployed with a field-programmable gate array (FPGA). A data receiver, which transmits data to the data transmitter and is deployed with a processor (CPU), uses the FPGA to transmit high-bandwidth signals, such as radar signals, to the processor.

[0044] Figure 3 FIG. 1 shows a flow chart of a data transmission method provided by an embodiment of the present application. Figure 3 As shown, the method includes the following steps S301 to S304:

[0045] Step S301: Acquire a User Datagram Protocol (UDP) message sent by a data receiving end.

[0046] In step S301, the UDP message includes at least message header data and data packet type, wherein the data packet type may include but is not limited to Address Resolution Protocol ARP message, UDP message and synchronization completion message. The synchronization completion message is a response message sent by the data receiving end to the data sending end after the data transmission between the data receiving end and the data sending end is completed.

[0047] In the embodiment of the present application, in order to address the shortcomings of the TCP / IP protocol stack being complex and inconvenient to implement with FPGA deployment, the present application adopts the UDP protocol to implement the handshake before RDMA transmission and synchronization during transmission. Compared with the TCP / IP protocol, UDP is connectionless, so there is no time delay required to establish a connection; in terms of space, TCP needs to maintain the connection state in the end system, which requires a certain amount of overhead. This connection loads parameters including receive and send buffers, congestion control parameters, and sequence and acknowledgment numbers, while UDP does not need to maintain the connection state, nor does it need to track the above parameters, so the overhead is small. Based on this, in the embodiment of the present application, transmitting data between the data receiving end and the data sending end through UDP packets can reduce the data transmission overhead and complexity.

[0048] Step S302: Double-check the message header data and the data packet type to obtain a check result.

[0049] It should be noted that compared with the TCP / IP protocol, the UDP protocol has the defect of insufficient reliability. To address this defect, in an embodiment of the present application, the message header data and data packet type of the UDP message are double-checked to ensure the accuracy of the handshake process, so that the accuracy of the handshake process and the accuracy of data transmission can be guaranteed without multiple state switching at the beginning and end of the communication. This not only makes up for the shortcoming of the UDP protocol's insufficient reliability compared to the TCP\IP protocol, but also reduces the complexity of data transmission.

[0050] Step S303: When the verification result indicates that the UDP message verification is successful, a response message is sent to the data receiving end.

[0051] In step S303, the response message is used to indicate that the handshake between the data sending end and the data receiving end is successful. Therefore, in the embodiment of the present application, only two messages are required to complete the handshake between the data sending end and the data receiving end during the handshake process. Compared with the TCP / IP protocol, the number of handshakes is reduced, thereby reducing the complexity of data transmission.

[0052] Step S304: transmitting the data requested by the data receiving end to the data receiving end through the Remote Direct Memory Access (RDMA) protocol.

[0053] After a successful handshake between the data sender and the data receiver, the data sender can transfer the data requested by the data receiver to the memory of the data receiver through the RDMA protocol. This process does not require the CPU of the data receiver to participate in message processing. The CPU only needs to send and receive messages, thereby reducing the CPU workload to a certain extent and allowing the CPU to be better used for data processing.

[0054] Based on the scheme defined in steps S301 to S304 above, it can be seen that in the embodiment of the present application, UDP is used to implement handshake and data synchronization between the data sending end and the data receiving end. Compared with the TCP / IP protocol, the UDP protocol is connectionless, and there is no time delay required to establish a connection in time. In space, there is no need to maintain the connection state, nor is there any need to track connection parameters. This reduces the difficulty of using FPGA to implement data transmission, making it possible to implement handshake and data synchronization through FPGA. In addition, in the embodiment of the present application, a double check method is used to double check the UDP message, so that the accuracy of the handshake process and the accuracy of data transmission can be guaranteed without multiple state switching at the beginning and end of communication. This not only makes up for the shortcomings of the UDP protocol in terms of reliability compared to the TCP\IP protocol, but also reduces the complexity of data transmission.

[0055] The following describes the specific implementation process of the method provided in the embodiment of the present application.

[0056] In an embodiment of the present application, the data sending end and the data receiving end are connected via an aggregate link, which is connected between the data sending end and the data receiving end and is used to implement a handshake connection and data synchronization between the data sending end and the data receiving end.

[0057] It should be noted that, in view of the disadvantage of the handshake link that needs to be designed separately in the handshake in the related art, in the embodiment of the present application, a handshake and data link aggregation method is adopted to use a hardware link to realize the handshake and synchronization in the RDMA transmission process, such as Figure 4 As shown, an aggregation link is set between the data sending end and the data receiving end, and the aggregation link can realize data synchronization and handshake.

[0058] In the embodiment of the present application, the FPGA in the data sending end can determine the state switching of handshake and data synchronization through bus arbitration.

[0059] Specifically, the data sending end receives the data message sent by the data receiving end through the aggregated link, identifies the data message, and obtains the message type corresponding to the data message; then, feeds back a response message matching the message type to the data receiving end.

[0060] In the above embodiment, the message types include: Address Resolution Protocol ARP message, UDP message and synchronization completion message.

[0061] In one example, Figure 5 The figure shows the state transition diagram of the arbitration state machine at the data sending end, wherein the arbitration state machine is deployed in the user layer of Ethernet, which can realize the arbitration of ARP packets and UDP packets. Figure 5 As shown, the states of the arbitration state machine mainly include: idle state S_IDLE, waiting state S_WAIT_DATA_READY, UDP response state S_UDP_ACK, ARP response state S_ARP_ACK and completion state S_END.

[0062] For the idle state S_IDLE, this state is maintained when the FPGA is reset, and jumps to the next state after receiving an ARP message, UDP message or RDMA transmission completion signal. For example, Figure 5 In the process, when an ARP packet is received, it jumps to the ARP response state S_ARP_ACK; when a UDP packet is received, it jumps to the UDP response state S_UDP_ACK; when an RDMA transmission completion signal is received, it jumps to the UDP response state S_UDP_ACK.

[0063] In the waiting state S_WAIT_DATA_READY, after the data sender receives the UDP packet, the arbitration state machine jumps from the idle state S_IDLE to the waiting state S_WAIT_DATA_READY. In this state, the arbitration state machine waits for the UDP packet to be assembled. When it receives the packet assembly completion signal udp_data_ready, it jumps to the next state S_UDP_ACK.

[0064] For the UDP response state S_UDP_ACK, after the arbitration state machine enters this state, the Ethernet transmission bus resources are allocated to the UDP link. After the data sending end completes the UDP message sending and receives the udp_ack_over signal, the arbitration state machine jumps to the S_END state, indicating that a message transmission is completed.

[0065] For the ARP response state S_ARP_ACK, after the arbitration state machine enters this state, the Ethernet transmission bus resources are allocated to the ARP link. After the data sending end completes the ARP message transmission and receives the arp_ack_over signal, the arbitration state machine jumps to the S_END state, indicating that a message transmission is completed.

[0066] For the completion state S_END, after the arbitration state machine enters this state, it indicates that the arbitration transmission of a message is completed. The state machine unconditionally jumps to the S_IDLE state in the next clock cycle and returns to the initial state.

[0067] In the case that the data message is an ARP message, the data sending end obtains the target network address that the data receiving end requests to access from the ARP message, and when it detects that the target network address is the network address of the data sending end, it generates a first response message including the physical address corresponding to the data sending end, and sends the first response message to the data receiving end so that the data receiving end stores the physical address.

[0068] In one example, the data receiving end initiates an ARP broadcast, where ARP is a TCP / IP protocol that obtains a physical address based on an IP address. In an embodiment of the present application, the host at the data receiving end first broadcasts an ARP request containing the target network address to all devices on the local area network, and receives a return message to determine the physical address of the data sending end. After the data receiving end receives the return message (i.e., the first response message) from the RDMA sending end, the target network address and the physical address of the data sending end are stored in the host ARP cache of the data receiving end and retained for a certain period of time. The ARP cache is directly queried on the next request to save resources.

[0069] It should be noted that when the data message is a synchronous completion message, the data sending end determines that the previous data transmission is successful and generates a message containing the next data to transmit to the data receiving end. That is, after completing the transmission of the first data, the data sending end continues to send the second data to the data receiving end. The process of transmitting the second data between the data sending end and the data receiving end is similar to that of the first data and will not be repeated here.

[0070] Furthermore, after the data sender is identified from multiple devices through ARP messages, that is, after the data sender determines that it needs to transmit data to the data receiver, a handshake connection is performed between the data sender and the data receiver. During the handshake connection process, the data sender must double-check the message header data and the data packet type to obtain a verification result.

[0071] Specifically, the data sending end verifies the message header data to obtain a first verification result; when the first verification result indicates that the message header data verification is successful, the data packet type is verified to obtain a second verification result; when the second verification result indicates that the data packet type verification is successful, it is determined that the UDP message verification is successful.

[0072] In the above embodiment, the message header data may include connection parameters, such as the queue number QPN of the QP to which the data receiving end is to connect, the start message sequence number PSN, the remote key REMOTE KEY, etc.

[0073] It should be noted that, in order to address the drawback of the UDP protocol being less reliable than the TCP / IP protocol, in the embodiment of the present application, a double check method of packet header check and handshake packet type check is designed at the data sending end to ensure the accuracy of the handshake process. Specifically, a state machine can be used for implementation. As an example, Figure 6 The state transition diagram of the UDP message parsing state machine is shown. The states of the UDP message parsing state machine mainly include: idle state S_IDLE, message header check state S_HEAD_CHECK, packet type check state S_TYPE_CHECK, failure state S_UDP_DUMP, handshake state S_HANDSHARK and confirmation state S_UDP_ACK.

[0074] For the idle state S_IDLE, this state is maintained when the UDP message parsing state machine is reset. When the data sender receives the UDP message, that is, when UDP_TYPE_FLAG arrives, it jumps to the next state, that is, the message header check state S_HEAD_CHECK.

[0075] In the header check state S_HEAD_CHECK, the UDP packet parsing state machine jumps from the S_IDLE state to this state after the data sender receives the UDP packet. In this state, the UDP packet parsing state machine verifies the UDP packet header. If the verification is successful, it jumps to the next state, the packet type check state S_TYPE_CHECK. If the header verification fails, it jumps to the failure state S_UDP_DUMP.

[0076] The packet type check state, S_TYPE_CHECK, is entered after the data sender receives a UDP packet and successfully verifies the packet header. In this state, the UDP packet parsing state machine verifies and matches the packet type of the UDP handshake packet. If the matching packet type is MSG_TYPE_HANDSHARK, the state transitions to the handshake state, S_HANDSHARK. If the matching packet type is MSG_TYPE_ACK, the state transitions to the acknowledgement state, S_UDP_ACK. If the packet type fails to match, the state transitions to the failure state, S_UDP_DUMP.

[0077] For the failure state S_UDP_DUMP, when the UDP message parsing state machine enters this state, it indicates that the UDP message packet received by the data sender has failed to check and match. The data sender does not respond to such messages and directly gives the udp_ack_over signal. The UDP message parsing state machine unconditionally jumps to the S_IDLE state in the next clock cycle, ending the UDP message processing flow.

[0078] For the handshake state S_HANDSHARK, when the UDP message parsing state machine enters this state, it indicates that the UDP message packet received by the data sender is checked and matched as a handshake packet. The data sender performs the handshake processing logic and replies with the corresponding handshake message. After the reply is completed, the udp_ack_over signal is given; the UDP message parsing state machine unconditionally jumps to the S_IDLE state in the next clock cycle, ending the UDP message processing process.

[0079] For the confirmation state S_UDP_ACK, when the UDP message parsing state machine enters this state, it indicates that the UDP message packet received by the data sender is checked and matched as a UDP_ACK message. The data sender performs the UDP_ACK processing logic and replies to the corresponding message. After the reply is completed, the udp_ack_over signal is given; the UDP message parsing state machine unconditionally jumps to the S_IDLE state in the next clock cycle, ending the UDP message processing flow.

[0080] In an embodiment of the present application, the UDP message also includes the first private data held by the data receiving end. In this scenario, the data receiving end also needs to verify the first private data in the UDP message.

[0081] Specifically, the first private data is verified using a verification rule corresponding to the first private data to obtain a third verification result; when the third verification result indicates that the verification of the first private data is successful, the second private data held by the data sending end is written into the response message, so that the data receiving end verifies the second private data.

[0082] In one example, the data sending end is in a listening state after power-on initialization. After listening to the handshake request sent by the data receiving end, the data sending end verifies and records the connection parameters, and the first private data sent by the data receiving end will use the pre-set verification rules to verify the first private data. After the verification is passed, the data sending end sends a HAND_MSG_RESPONSE message to indicate that it accepts the previous connection request, and carries its own connection parameters in the message message - including QPN, starting PSN, etc. The message message can also carry the second private data customized by the data sending end, so that after the data receiving end receives the HAND_MSG_RESPONSE message returned by the data sending end, it verifies and records the content therein. After the verification is correct, it determines that the RDMA link is successful, and can use the QP agreed by both parties to interact with data.

[0083] It should be noted that by verifying private data, the security of data transmission can be improved.

[0084] In addition, when the second verification result indicates that the data packet type verification is successful and the data packet type is a handshake request message, a handshake connection is performed between the data receiving end and the data sending end; when the handshake connection is successful, a response message is returned to the data receiving end to notify the data receiving end that it is ready to receive data.

[0085] Furthermore, if the handshake between the data receiving end and the data sending end is successful, the data sending end can transmit the data requested by the data receiving end to the data receiving end via the Remote Direct Memory Access (RDMA) protocol. Specifically, the data sending end sends the data requested by the data receiving end to the data receiving end's memory via the RDMA protocol and transmits a synchronization word to the data receiving end via the socket port. Then, the data sending end receives the synchronization completion message returned by the data receiving end based on the synchronization word and sends the next data to the data receiving end.

[0086] In one example, when a data transmitter sends data, it initiates a DMA request to the data receiver and sends the data to the receiver's memory via the RDMA protocol. After completing the data transfer, the FPGA sends the RDMA_SYNC transmission completion synchronization word to the data receiver via the UDP socket port. After receiving the synchronization word, the data receiver determines that the current data transfer is complete and the data in the data receiver's memory is safe and operable. At this point, the data receiver responds with an RDMA_WR_ACK signal to the data transmitter via the UDP socket port. After receiving the RDMA_WR_ACK signal, the data transmitter determines that the RDMA transfer is complete and can proceed to initiate the next RDMA transfer.

[0087] In one embodiment, Figure 7 The diagram shows the interaction between the data sending end and the data receiving end. Figure 7 It can be seen that the data transmission method provided in the embodiment of the present application mainly includes the following steps:

[0088] Step S701: The data receiving end broadcasts an ARP message, and the data sending end replies with an ARP response message, wherein the ARP response message includes the MAC address of the data sending end.

[0089] Step S702: The data receiving end and the data sending end perform handshake to establish a connection.

[0090] Specifically, the data receiving end sends RDMA handshake information to the data sending end; the data sending end verifies the RDMA handshake information, and if the verification passes, sends a confirmation response message of the RDMA handshake information to the data receiving end.

[0091] In step S703, the data transmitter initiates a DMA request to the data receiver and sends the data to the data receiver's memory via the RDMA protocol. After completing the data transfer, the FPGA sends the RDMA_SYNC transmission synchronization word to the data receiver via the UDP socket port. After receiving the synchronization word, the data receiver determines that the current data transfer is complete and the data in the data receiver's memory is safe and operable. At this point, the data receiver responds with an RDMA_WR_ACK signal to the data transmitter via the UDP socket port. After receiving the RDMA_WR_ACK signal, the data transmitter determines that the RDMA transfer is complete and can proceed to initiate the next RDMA transfer.

[0092] This concludes the introduction to the methods provided in the embodiments of the present application.

[0093] As can be seen from the above content, the method provided in the embodiment of the present application uses UDP for RDMA handshake and synchronization, which solves the problem that the handshake synchronization using the TCP / IP protocol in the traditional way is difficult to deploy and implement on the FPGA side. In addition, in the embodiment of the present application, by designing a double verification method of message header verification and handshake data packet type verification at the data sending end, the accuracy of the handshake process is guaranteed, which makes up for the shortcoming of the UDP protocol's lack of reliability compared to the TCP / IP protocol. In addition, through the bus arbitration mechanism implemented inside the FPGA, a link is realized to complete the handshake, synchronization, data transmission and other tasks required for RDMA communication, which simplifies the design complexity of the system and greatly reduces the hardware cost of the system.

[0094] The embodiment of the present application also provides a data transmission device, which is applied to a data sending end, such as Figure 8As shown, the device 800 includes: a message acquisition module 801, a verification module 802, a message response module 803 and a data transmission module 804.

[0095] The message acquisition module 801 is used to acquire a User Datagram Protocol (UDP) message sent by a data receiving end, wherein the UDP message includes at least message header data and a data packet type;

[0096] Verification module 802, used to perform double verification on the message header data and the data packet type to obtain a verification result;

[0097] The message response module 803 is used to send a response message to the data receiving end when the verification result indicates that the UDP message verification is successful, wherein the response message is used to indicate that the handshake between the data sending end and the data receiving end is successful;

[0098] The data transmission module 804 is configured to transmit the data requested by the data receiving end to the data receiving end through the Remote Direct Memory Access (RDMA) protocol.

[0099] In one example, a data transmitter and a data receiver are connected via an aggregated link, wherein the data transmission device further comprises: a message receiving module, a message identification module, and a message sending module. The message receiving module is used to receive a data message sent by the data receiver via the aggregated link before a User Datagram Protocol (UDP) message is sent from the data receiver, wherein the aggregated link is connected between the data transmitter and the data receiver to implement a handshake connection and data synchronization between the data transmitter and the data receiver; the message identification module is used to identify the data message and obtain the message type corresponding to the data message, wherein the message types include: Address Resolution Protocol (ARP) message, UDP message, and synchronization completion message; the message sending module is used to feed back a message matching the message type to the data receiver.

[0100] In one example, the message sending module is specifically used to obtain the target network address that the data receiving end requests to access from the ARP message when the data message is an ARP message; when it is detected that the target network address is the network address of the data sending end, a first response message containing the physical address corresponding to the data sending end is generated, and the first response message is sent to the data receiving end so that the data receiving end stores the physical address.

[0101] In one example, the message sending module is specifically configured to, when the data message is a synchronization completion message, determine that the previous data transmission is successful, and generate a message containing the next data to transmit to the data receiving end.

[0102] In one example, the verification module is specifically used to verify the message header data to obtain a first verification result; when the first verification result indicates that the message header data verification is successful, the data packet type is verified to obtain a second verification result; when the second verification result indicates that the data packet type verification is successful, it is determined that the UDP message verification is successful.

[0103] In one example, the UDP message also includes first private data held by the data receiving end, wherein the data transmission device also includes: a first verification module, which is used to verify the message header data and obtain a first verification result, and then use the verification rule corresponding to the first private data to verify the first private data to obtain a third verification result; when the third verification result indicates that the verification of the first private data is successful, the second private data held by the data sending end is written into the response message, so that the data receiving end can verify the second private data.

[0104] In one example, the message response module is specifically used to perform a handshake connection between the data receiving end and the data sending end when the second verification result indicates that the data packet type verification is successful and the data packet type is a handshake request message; if the handshake connection is successful, the response message is returned to the data receiving end.

[0105] In one example, the data transmission module is specifically used to send the data requested by the data receiving end to the memory of the data receiving end through the RDMA protocol, and transmit the synchronization word to the data receiving end through the socket SOCKET port; obtain the synchronization completion message returned by the data receiving end based on the synchronization word, and send the next data to the data receiving end.

[0106] In one example, a field programmable gate array (FPGA) is deployed at the data transmitting end, and a processor is deployed at the data receiving end. The FPGA is used to transmit radar signals to the processor.

[0107] The data transmission device provided in the embodiment of the present application can implement each process implemented in the aforementioned method embodiment. To avoid repetition, they will not be described here.

[0108] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0109] Figure 9 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application is shown.

[0110] The electronic device may include a processor 901 and a memory 902 storing computer program instructions.

[0111] Specifically, the processor 901 may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0112] The memory 902 may include a large capacity memory for data or instructions. By way of example and not limitation, the memory 902 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory 902 may include removable or non-removable (or fixed) media. Where appropriate, the memory 902 may be inside or outside the integrated gateway disaster recovery device. In a specific embodiment, the memory 902 is a non-volatile solid-state memory.

[0113] The memory may include read-only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical or other physical / tangible memory storage devices. Thus, generally, the memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to an aspect of the present disclosure.

[0114] The processor 901 implements any one of the data transmission methods in the above embodiments by reading and executing computer program instructions stored in the memory 902 .

[0115] In one example, the electronic device may further include a communication interface 903 and a bus 910. Figure 9 As shown, the processor 901 , the memory 902 , and the communication interface 903 are connected via a bus 910 and communicate with each other.

[0116] The communication interface 903 is mainly used to implement communication between various modules, devices, units and / or equipment in the embodiments of the present application.

[0117] Bus 910 comprises hardware, software or both, couples the parts of electronic equipment to each other.For example, and not limitation, bus can comprise accelerated graphics port (AGP) or other graphics bus, enhanced industry standard architecture (EISA) bus, front side bus (FSB), hypertransport (HT) interconnection, industry standard architecture (ISA) bus, infinite bandwidth interconnection, low pin count (LPC) bus, memory bus, micro channel architecture (MCA) bus, peripheral component interconnection (PCI) bus, PCI-Express (PCI-X) bus, serial advanced technology attachment (SATA) bus, video electronics standard association local (VLB) bus or other suitable bus or two or more of these combinations.In suitable cases, bus 910 can comprise one or more buses.Although the present application embodiment describes and shows specific bus, the application considers any suitable bus or interconnection.

[0118] In addition, in conjunction with the data transmission method in the above embodiments, the present application embodiment may provide a computer-readable storage medium for implementation. The computer-readable storage medium stores computer program instructions; when the computer program instructions are executed by a processor, any one of the data transmission methods in the above embodiments is implemented.

[0119] In addition, in combination with the data transmission method in the above embodiment, the embodiment of the present application can provide a computer program product for implementation. When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device executes and implements any of the data transmission methods in the above embodiment.

[0120] It should be understood that the present application is not limited to the specific configurations and processes described above and illustrated in the figures. For the sake of brevity, a detailed description of known methods is omitted here. In the above embodiments, several specific steps are described and illustrated as examples. However, the method process of the present application is not limited to the specific steps described and illustrated. Those skilled in the art can make various changes, modifications, and additions, or change the order of the steps after understanding the spirit of the present application.

[0121] The functional modules shown in the above-described block diagram can be implemented as hardware, software, firmware or a combination thereof. When implemented in hardware, it can be, for example, an electronic circuit, an application specific integrated circuit (ASIC), appropriate firmware, a plug-in unit, a function card or the like. When implemented in software, the elements of the present application are programs or code segments that are used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link by a data signal carried in a carrier wave. "Machine-readable medium" can include any medium that can store or transmit information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROMs, flash memories, erasable ROMs (EROMs), floppy disks, CD-ROMs, optical disks, hard disks, optical fiber media, radio frequency (RF) links, etc. The code segment can be downloaded via a computer network such as the Internet, an intranet, etc.

[0122] It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or devices. However, this application is not limited to the order of the above steps. In other words, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0123] The above describes various aspects of the present disclosure with reference to the flowcharts and / or block diagrams of the data transmission method, device and electronic device according to the embodiments of the present disclosure. It should be understood that each box in the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine so that these instructions executed by the processor of the computer or other programmable data processing device enable the implementation of the function / action specified in one or more boxes of the flowchart and / or block diagram. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor or a field programmable logic circuit. It can also be understood that each box in the block diagram and / or flowchart and the combination of boxes in the block diagram and / or flowchart can also be implemented by dedicated hardware that performs the specified function or action, or can be implemented by a combination of dedicated hardware and computer instructions.

[0124] The above description is only a specific embodiment of the present application. Those skilled in the art will clearly understand that for the convenience and brevity of description, the specific working processes of the systems, modules and units described above can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here. It should be understood that the scope of protection of the present application is not limited thereto. Any person skilled in the art can easily think of various equivalent modifications or replacements within the technical scope disclosed in the present application, and these modifications or replacements should be included in the scope of protection of the present application.

Claims

1. A data transmission method, characterized in that: Applied to a data sending end, the method includes: Acquire a User Datagram Protocol (UDP) message sent by a data receiving end, wherein the UDP message includes at least message header data and a data packet type; Performing a double check on the message header data and the data packet type to obtain a check result; If the verification result indicates that the UDP message verification is successful, sending a response message to the data receiving end, wherein the response message is used to indicate that the handshake between the data sending end and the data receiving end is successful; The data requested by the data receiving end is transmitted to the data receiving end through a remote direct memory access (RDMA) protocol.

2. The method according to claim 1, characterized in that The data transmitting end and the data receiving end are connected via an aggregated link, wherein, before a User Datagram Protocol (UDP) message is sent from the data receiving end, the method further comprises: receiving a data message sent by the data receiving end through an aggregated link, wherein the aggregated link is connected between the data sending end and the data receiving end, and is used to implement a handshake connection and data synchronization between the data sending end and the data receiving end; Identify the data message to obtain a message type corresponding to the data message, wherein the message type includes: an Address Resolution Protocol ARP message, the UDP message, and a synchronization completion message; Feedback a message matching the message type to the data receiving end.

3. The method according to claim 2, characterized in that Feedback of a message matching the message type to the data receiving end includes: In a case where the data message is the ARP message, obtaining the target network address that the data receiving end requests to access from the ARP message; When it is detected that the target network address is the network address of the data sending end, a first response message including the physical address corresponding to the data sending end is generated, and the first response message is sent to the data receiving end so that the data receiving end stores the physical address.

4. The method according to claim 1, wherein Double checking the message header data and the data packet type to obtain a verification result, including: Verifying the message header data to obtain a first verification result; If the first verification result indicates that the packet header data verification is successful, verify the data packet type to obtain a second verification result; When the second verification result indicates that the data packet type verification is successful, it is determined that the UDP message verification is successful.

5. The method according to claim 4, characterized in that The UDP message also includes first private data held by the data receiving end, wherein, after verifying the message header data and obtaining a first verification result, the method further includes: Verifying the first private data using a verification rule corresponding to the first private data to obtain a third verification result; If the third verification result indicates that the verification of the first private data is successful, the second private data held by the data sending end is written into the response message, so that the data receiving end verifies the second private data.

6. The method according to claim 4, characterized in that Sending a response message to the data receiving end includes: When the second verification result indicates that the data packet type verification is successful and the data packet type is a handshake request message, performing a handshake connection between the data receiving end and the data sending end; If the handshake connection is successful, the response message is returned to the data receiving end.

7. The method according to claim 1, characterized in that Transmitting the data requested by the data receiving end to the data receiving end through a remote direct memory access (RDMA) protocol, including: Sending the data requested by the data receiving end to the memory of the data receiving end through the RDMA protocol, and transmitting a synchronization word to the data receiving end through a socket port; Acquire a synchronization completion message returned by the data receiving end based on the synchronization word, and send next data to the data receiving end.

8. The method according to any one of claims 1 to 7, characterized in that The data transmitting end is deployed with a field programmable gate array FPGA, and the data receiving end is deployed with a processor. The FPGA is used to transmit radar signals to the processor.

9. A data transmission device, characterized in that: Applied to a data transmitting end, the device comprises: A message acquisition module, configured to acquire a User Datagram Protocol (UDP) message sent by a data receiving end, wherein the UDP message includes at least message header data and a data packet type; A verification module, configured to perform a double check on the message header data and the data packet type to obtain a verification result; a message response module, configured to send a response message to the data receiving end if the verification result indicates that the UDP message verification is successful, wherein the response message is used to indicate that the handshake between the data sending end and the data receiving end is successful; The data transmission module is used to transmit the data requested by the data receiving end to the data receiving end through the remote direct memory access (RDMA) protocol.

10. An electronic device, characterized in that: The electronic device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, the data transmission method according to any one of claims 1 to 8 is implemented.

Images