Communication method, device, equipment and medium based on data link layer

Abstract

The present disclosure provides a communication method, device, equipment and medium based on the data link layer, which belongs to the field of communication technology. The communication method based on the data link layer in the sending end includes: sending a network connection request to the receiving end; responding to the network connection request reply message of the receiving end for the network connection request, establishing a communication connection after handshaking with the receiving end, and obtaining the target queue pair sequence number and target data packet sequence number required for the transmission process; constructing a data transmission message based on the target queue pair sequence number and the target data packet sequence number, and determining that the Ethernet type in the data transmission message is a preset target type, and pre-creating a first flow rule table containing the target type in the receiving end; sending the data transmission message to the receiving end through the data link layer, so that the receiving end identifies the Ethernet type in the data transmission message based on the first flow rule table, and processes the data transmission message after identification. The embodiment of the present disclosure can improve bandwidth utilization.

Description

Technical Field

[0001] The present disclosure relates to the field of communication technology, and in particular to a communication method, apparatus, device, and medium based on a data link layer. Background Art

[0002] Remote Direct Memory Access (RDMA) is a high-performance network communication technology that allows a computer to directly access the memory of a remote computer. To implement RDMA over an Ethernet network, the RoCEv2 (RDMA over Converged Ethernet version 2) protocol is typically used.

[0003] In related technologies, under the RoCEv2 protocol, data packets (also called messages) transmitted between networks contain fields at multiple levels, such as IP fields and UDP fields. However, in the process of data transmission based on the data link layer, too many fields increase the total length of the message, thereby reducing the proportion of payload data, resulting in low bandwidth utilization. Summary of the Invention

[0004] The main purpose of the embodiments of the present disclosure is to provide a communication method, apparatus, device and medium based on the data link layer, which can improve bandwidth utilization.

[0005] To achieve the above objectives, a first aspect of an embodiment of the present disclosure proposes a data link layer-based communication method, which is applied to a transmitting end. The communication method includes:

[0006] Send a network connection request to the receiving end;

[0007] In response to a network connection request reply message from the receiving end to the network connection request, establishing a communication connection after shaking hands with the receiving end, and obtaining a target queue pair sequence number and a target data packet sequence number required for a transmission process;

[0008] Constructing a data transmission message based on the target queue pair sequence number and the target data packet sequence number, and determining an Ethernet type in the data transmission message as a preset target type, wherein a first flow rule table containing the target type is pre-created in the receiving end;

[0009] The data transmission message is sent to the receiving end through the data link layer, so that the receiving end identifies the Ethernet type in the data transmission message based on the first flow rule table, and processes the data transmission message after the identification is successful.

[0010] In some embodiments, the target queue pair sequence number is a preset initial sequence number; and constructing a data transmission message based on the target queue pair sequence number and the target data packet sequence number includes:

[0011] Obtaining a source address in the sending end and a destination address in the receiving end;

[0012] Constructing a data transmission message based on the target queue pair sequence number, the target data packet sequence number, the source address and the destination address;

[0013] Among them, the receiving end identifies the Ethernet type in the data transmission message based on the first flow rule table, and obtains the target queue pair sequence number and the target data packet sequence number in the data transmission message after identification; if the target queue pair sequence number is the same as the preset initial sequence number, the target queue pair sequence number is adjusted based on the source address and the destination address, and the data transmission message is processed based on the target data packet sequence number and the adjusted target queue pair sequence number.

[0014] In some embodiments, responding to a network connection request reply message from the receiving end to the network connection request, establishing a communication connection after handshaking with the receiving end, and obtaining a target queue pair sequence number and a target data packet sequence number required for the transmission process include:

[0015] sending a handshake request to the receiving end in response to a network connection request reply message sent by the receiving end to the network connection request;

[0016] In response to a handshake request reply message from the receiving end to the handshake request, establishing a communication connection after shaking hands with the receiving end, and exchanging corresponding queue pair sequence numbers and data packet sequence numbers with the receiving end;

[0017] The queue pair sequence number and the data packet sequence number exchanged and obtained from the receiving end are used as the target queue pair sequence number and the target data packet sequence number required for the transmission process.

[0018] In some embodiments, the target type is determined by the following steps, including:

[0019] Determining an arbitrary fixed-value Ethernet type as the target type;

[0020] Alternatively, an Ethernet type of any initial type is selected, an Ethernet type determination request is constructed based on the initial type, and the Ethernet type determination request is sent to the receiving end. When an Ethernet type determination request reply message for the Ethernet type determination request sent by the receiving end is received, the initial type is determined to be the target type.

[0021] To achieve the above-mentioned purpose, a second aspect of an embodiment of the present disclosure proposes a communication method based on a data link layer, which is applied to a receiving end. The communication method includes:

[0022] Receive the network connection request sent by the sender;

[0023] Sending a network connection request reply message for the network connection request to the sending end, and establishing a communication connection after shaking hands with the sending end;

[0024] Obtaining a preset target type and creating a first-flow rule table containing the target type;

[0025] receiving, through a data link layer, a data transmission message sent by the transmitting end, wherein the data transmission message is constructed by the transmitting end based on a target queue pair sequence number and a target data packet sequence number, an Ethernet type in the data transmission message is a preset target type, and the target queue pair sequence number and the target data packet sequence number are determined by the transmitting end during a handshake operation;

[0026] The Ethernet type in the data transmission message is identified based on the first flow rule table, and the data transmission message is processed after the identification is successful.

[0027] In some embodiments, identifying the Ethernet type in the data transmission message based on the first flow rule table, and processing the data transmission message after the identification is successful, includes:

[0028] Identifying the Ethernet type in the data transmission message based on the first flow rule table, and obtaining the target queue pair sequence number and the target data packet sequence number in the data transmission message after the identification is successful;

[0029] If the target queue pair sequence number is the same as the preset initial sequence number, the target queue pair sequence number is adjusted based on the source address and the destination address, and the data transmission message is processed based on the target data packet sequence number and the adjusted target queue pair sequence number.

[0030] In some embodiments, adjusting the target queue pair sequence number based on the source address and the destination address, and processing the data transmission message based on the target data packet sequence number and the adjusted target queue pair sequence number, includes:

[0031] Obtain the source address and the destination address in the data transmission message, and obtain a corresponding target sequence number in the first flow rule table based on the source address and the destination address;

[0032] The target sequence number is used as the adjusted target queue pair sequence number, and the data transmission message is processed based on the target data packet sequence number and the adjusted target queue pair sequence number.

[0033] In some embodiments, creating a first flow rule table containing the target type includes:

[0034] Obtaining a source address in the sending end and a destination address in the receiving end, and assigning corresponding target sequence numbers to the source address and the destination address;

[0035] A first flow rule table containing the target type is created, and the target sequence number is added to the first flow rule table using the source address and the destination address as indexes.

[0036] In some embodiments, adding the target sequence number to the first flow rule table using the source address and the destination address as indexes includes:

[0037] The source address is bound to the target sequence number, the destination address is stored in the address book of the target sequence number, and the target sequence number is added to the first flow rule table.

[0038] In some embodiments, the sending of a network connection request reply message in response to the network connection request to the sending end, and establishing a communication connection after shaking hands with the sending end, includes:

[0039] generating a network connection request reply message based on the network connection request, and sending the network connection request reply message to the sending end;

[0040] In response to the handshake request sent by the sending end for the network connection request reply message, a handshake request reply message for the handshake request is sent to the sending end, a communication connection is established after shaking hands with the sending end, and the corresponding queue pair sequence number and data packet sequence number are exchanged with the sending end, so that the sending end uses the queue pair sequence number and the data packet sequence number obtained from the exchange from the receiving end as the target queue pair sequence number and target data packet sequence number required for the transmission process.

[0041] In some embodiments, the target type is determined by the following steps, including:

[0042] Determining an arbitrary fixed-value Ethernet type as the target type;

[0043] Alternatively, receiving an Ethernet type determination request sent by the transmitting end, extracting an initial type from the Ethernet type determination request, and sending an Ethernet type determination request reply message for the Ethernet type determination request to the transmitting end, and then using the initial type as the target type;

[0044] The Ethernet type determination request is constructed based on any initial Ethernet type selected by the sending end.

[0045] To achieve the above-mentioned purpose, a third aspect of the embodiments of the present disclosure provides a data link layer-based communication device, which is applied to a transmitting end. The communication device includes:

[0046] A request sending module, used for sending a network connection request to a receiving end;

[0047] a first handshake module, configured to respond to a network connection request reply message from the receiving end to the network connection request, establish a communication connection after shaking hands with the receiving end, and obtain a target queue pair sequence number and a target data packet sequence number required for a transmission process;

[0048] a message construction module, configured to construct a data transmission message based on the target queue pair sequence number and the target data packet sequence number, and determine an Ethernet type in the data transmission message as a preset target type, wherein a first flow rule table containing the target type is pre-created in the receiving end;

[0049] The message transmission module is used to send the data transmission message to the receiving end through the data link layer, so that the receiving end identifies the Ethernet type in the data transmission message based on the first flow rule table and processes the data transmission message after the identification is passed.

[0050] To achieve the above-mentioned purpose, a fourth aspect of the embodiments of the present disclosure provides a data link layer-based communication device, which is applied to a receiving end. The communication device includes:

[0051] A request receiving module, used to receive a network connection request sent by a sending end;

[0052] A second handshake module is configured to send a network connection request reply message for the network connection request to the sending end, and establish a communication connection after shaking hands with the sending end;

[0053] A flow rule creation module, configured to obtain a preset target type and create a first flow rule table containing the target type;

[0054] a message receiving module, configured to receive, through a data link layer, a data transmission message sent by the transmitting end, wherein the data transmission message is constructed by the transmitting end based on a target queue pair sequence number and a target data packet sequence number, and the Ethernet type in the data transmission message is the preset target type, and the target queue pair sequence number and the target data packet sequence number are determined by the transmitting end during a handshake operation;

[0055] The message processing module is used to identify the Ethernet type in the data transmission message based on the first flow rule table, and process the data transmission message after the identification is successful.

[0056] To achieve the above-mentioned purpose, the fifth aspect of the embodiments of the present disclosure proposes an electronic device, which includes a memory and a processor, and the memory stores a computer program. When the processor executes the computer program, it implements the data link layer-based communication method described in the first aspect embodiment, or the data link layer-based communication method described in the second aspect embodiment.

[0057] To achieve the above-mentioned purpose, the sixth aspect of the embodiment of the present disclosure proposes a storage medium, which is a computer-readable storage medium, and the storage medium stores a computer program. When the computer program is executed by the processor, it implements the data link layer-based communication method described in the first aspect embodiment, or the data link layer-based communication method described in the second aspect embodiment.

[0058] In the embodiment of the present disclosure, a network connection request is sent from a sending end to a receiving end. After the receiving end sends a network connection request reply message to the sending end in response to the network connection request, a communication connection is established after a handshake with the sending end. Subsequently, the target queue pair sequence number and the target data packet sequence number required for the transmission process can be obtained. Then, the sending end can construct a data transmission message based on the target queue pair sequence number and the target data packet sequence number. Since the data transmission message is transmitted at the data link layer, the data transmission message does not contain an IP field, and further, the data transmission message does not contain a UDP field. To facilitate the identification of the data transmission message, the sending end also determines that the Ethernet type in the data transmission message is a preset target type. A first flow rule table containing the target type is pre-created in the receiving end. When the sending end sends the data transmission message to the receiving end through the data link layer, the receiving end can identify the Ethernet type in the data transmission message based on the first flow rule table, so that the data transmission message can be normally identified even if it does not contain a UDP message. Finally, the receiving end can normally process the data transmission message after the identification is passed. Therefore, the data transmission message in the embodiment of the present disclosure does not contain IP fields and UDP fields, and can be transmitted at the data link layer, thereby reducing the total length of the message field, effectively increasing the proportion of load data, and thus improving bandwidth utilization. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 It is a schematic diagram of message fields in the prior art proposed by the embodiment of the present disclosure;

[0060] Figure 2 is a schematic diagram of a communication system provided by an embodiment of the present disclosure;

[0061] Figure 3 is a flow chart of a communication method based on a data link layer provided by an embodiment of the present disclosure;

[0062] Figure 4 yes Figure 3 A schematic diagram of a process flow further included in step S103;

[0063] Figure 5 yes Figure 3 A schematic diagram of a process flow further included in step S102;

[0064] Figure 6 is a schematic diagram of a data transmission process between a transmitting end and a receiving end provided by an embodiment of the present disclosure;

[0065] Figure 7 1 is a flow chart of a target type determination process in a transmitting end provided by an embodiment of the present disclosure;

[0066] Figure 8is a flow chart of a communication method based on a data link layer provided by another embodiment of the present disclosure;

[0067] Figure 9 yes Figure 8 A schematic diagram of a process flow further included in step S505;

[0068] Figure 10 yes Figure 9 A schematic diagram of a process flow further included in step S602;

[0069] Figure 11 yes Figure 8 A schematic diagram of a process flow further included in step S503;

[0070] Figure 12 yes Figure 8 A schematic diagram of a process flow further included in step S502;

[0071] Figure 13 1 is a flow chart of a target type determination process in a receiving end provided by an embodiment of the present disclosure;

[0072] Figure 14 is a schematic diagram of functional modules of a data link layer-based communication device provided by an embodiment of the present disclosure;

[0073] Figure 15 is a functional module diagram of a data link layer-based communication device provided by another embodiment of the present disclosure;

[0074] Figure 16 Schematic diagram of the hardware structure of the electronic device provided by the embodiment of the present disclosure. DETAILED DESCRIPTION

[0075] In order to make the purpose, technical solutions and advantages of the present disclosure more clearly understood, the present disclosure is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present disclosure and are not intended to limit the present disclosure.

[0076] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art in the art of the present disclosure. The terms used herein are only for the purpose of describing the embodiments of the present disclosure and are not intended to limit the present disclosure.

[0077] First, some terms used in this disclosure are analyzed:

[0078] Artificial intelligence (AI) is a new technical discipline that studies and develops theories, methods, technologies, and application systems for simulating, extending, and expanding human intelligence. A branch of computer science, AI seeks to understand the essence of intelligence and produce new intelligent machines that can respond in a manner similar to human intelligence. Research in this field includes robotics, speech recognition, image recognition, natural language processing, and expert systems. AI can simulate the information processes of human consciousness and thinking. It also encompasses the theories, methods, technologies, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, to perceive the environment, acquire knowledge, and use that knowledge to achieve optimal results.

[0079] Fundamental AI technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interaction systems, and mechatronics. AI software technologies primarily encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0080] Remote Direct Memory Access (RDMA) is a high-performance network communication technology that allows a computer to directly access the memory of a remote computer without copying data between the local and remote computers. Due to its high performance, low latency, and efficient data transmission capabilities, RDMA has been widely used in data centers, high-performance computing, distributed storage, cloud computing, and other fields.

[0081] RoCEv2 (RDMA over Converged Ethernet version 2) is an advanced version of Ethernet-based remote direct memory access technology. It is designed to achieve high-performance, low-latency data transmission over Ethernet networks while overcoming some of the limitations of RoCEv1. RoCEv2 allows data to be transferred directly from the memory of one computer to the memory of another without involving the host CPU, significantly reducing data transmission overhead and latency.

[0082] The IP field, also known as the Internet Protocol field, is used to identify the logical addresses of the sender and receiver in the IP network layer to ensure that the data packet can be correctly routed to the destination.

[0083] The User Datagram Protocol (UDP) is a data packet mode that provides packet switching computer communications in a group of interconnected computer network environments. The protocol assumes the use of IP as the underlying protocol and works at the transport layer according to the OSI model.

[0084] In related technologies, under the RoCEv2 protocol, data packets (also called messages) transmitted between networks contain fields at multiple levels. Figure 1 , Figure 1 This is a schematic diagram of message fields in the prior art proposed in an embodiment of the present disclosure. The message shown in the figure includes the Eth L2 Header field, Ethertype field, IP Header field (IP field), Protocol field, UDP Header field (UDP field), Port field, IB BTH+ (L4 Hdr) field, IB Payload field, ICRC field, and FCS field. However, during data transmission based on the data link layer, the excessive number of fields increases the total length of the message, thereby reducing the proportion of payload data and resulting in low bandwidth utilization.

[0085] For example, the IP field is mainly used for routing-related operations in Ethernet applications, and the UDP field is used to identify messages. However, when data is transmitted based on the data link layer, routing-related operations are not required, so some fields can be deleted to further improve bandwidth utilization.

[0086] Based on this, the embodiments of the present disclosure provide a data link layer-based communication method, apparatus, device, and medium, which can improve bandwidth utilization.

[0087] The data link layer-based communication method in the embodiment of the present disclosure can be described through the following embodiments. First, the communication system in the embodiment of the present disclosure is introduced.

[0088] See also Figure 2 , Figure 2 The communication system in the embodiment of the present disclosure is provided with a sending end (client end) and a receiving end (server end), and the sending end and the receiving end are connected in communication.

[0089] The sending end can send a network connection request to the receiving end; in response to the network connection request reply message of the receiving end for the network connection request, establish a communication connection after shaking hands with the receiving end, and obtain the target queue pair sequence number and the target data packet sequence number required for the transmission process; construct a data transmission message based on the target queue pair sequence number and the target data packet sequence number, and determine the Ethernet type in the data transmission message as a preset target type, wherein a first flow rule table containing the target type is pre-created in the receiving end; send the data transmission message to the receiving end through the data link layer, so that the receiving end identifies the Ethernet type in the data transmission message based on the first flow rule table, and processes the data transmission message after the identification is passed.

[0090] The receiving end can receive a network connection request sent by the sending end; send a network connection request reply message for the network connection request to the sending end, and establish a communication connection after shaking hands with the sending end; obtain a preset target type, and create a first flow rule table containing the target type; receive a data transmission message sent by the sending end through the data link layer, wherein the data transmission message is constructed by the sending end based on the target queue pair sequence number and the target data packet sequence number, and the Ethernet type in the data transmission message is the preset target type, and the target queue pair sequence number and the target data packet sequence number are determined by the sending end during the handshake operation; identify the Ethernet type in the data transmission message based on the first flow rule table, and process the data transmission message after identification.

[0091] The embodiments of the present disclosure can acquire and process relevant data based on artificial intelligence technology.

[0092] The transmitting end or receiving end provided by the embodiments of the present disclosure may be a terminal, a server, or software in a terminal or server. In some embodiments, the terminal may be a smartphone, tablet computer, laptop computer, desktop computer, etc.; the server may be configured as an independent physical server, or as a server cluster or distributed system composed of multiple physical servers, or as a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software may be an application that implements a communication method based on the data link layer, etc., but is not limited to the above forms.

[0093] The present disclosure can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, and the like. The present disclosure can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. The present disclosure can also be practiced in distributed computing environments in which tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media, including storage devices.

[0094] It should be noted that in each specific embodiment of the present disclosure, when obtaining messages or other data for related processing, the user's permission or consent will be obtained first. Moreover, the collection, use and processing of such data will comply with relevant laws, regulations and standards. In addition, when the embodiment of the present disclosure needs to obtain messages or other data, the user's separate permission or consent can be obtained through a pop-up window or by jumping to a confirmation page. After clearly obtaining the user's separate permission or consent, the necessary messages or other data for the normal operation of the embodiment of the present disclosure can be obtained.

[0095] Figure 3 : is a flow chart of a communication method based on a data link layer provided by an embodiment of the present disclosure, which can be applied in a transmitting end. Figure 3 The communication method may include but is not limited to steps S101 to S104.

[0096] Step S101, sending a network connection request to a receiving end;

[0097] Step S102, in response to the network connection request reply message of the receiving end to the network connection request, establish a communication connection after handshaking with the receiving end, and obtain the target queue pair sequence number and target data packet sequence number required for the transmission process;

[0098] Step S103, constructing a data transmission message based on the target queue pair sequence number and the target data packet sequence number, and determining the Ethernet type in the data transmission message as a preset target type, wherein a first flow rule table containing the target type is pre-created in the receiving end;

[0099] Step S104: sending the data transmission message to the receiving end through the data link layer, so that the receiving end identifies the Ethernet type in the data transmission message based on the first flow rule table, and processes the data transmission message after passing the identification.

[0100] Regarding step S101 above, in protocols such as RoCEv2, in order to achieve efficient data transmission, a stable network connection must first be established. In the disclosed embodiments, the sender is responsible for initiating data transmission and initiating the network connection process, while the receiver is the party receiving data and needs to respond to the sender's connection request and receive and process data after the connection is established.

[0101] A network connection request is a message or signal sent by a sender to a receiver, requesting a direct communication connection with the receiver. For example, a network connection request may include information for authentication, negotiation of connection parameters (such as queue pair sequence numbers), and other necessary information to ensure successful data exchange between the two parties. Furthermore, the network connection request may be a TCP request.

[0102] Regarding the above step S102, after receiving the network connection request, the receiving end will perform a series of checks and verifications to ensure that the network connection request is valid. If the receiving end agrees to establish the connection, it will send a network connection request reply message to the sending end for the network connection request. This reply message may include the receiving end's confirmation information, connection parameters and other information, or it may be a confirmation of the sending end's request.

[0103] A handshake is a two-way communication process used to establish a reliable connection between a sender and a receiver. In the RoCEv2 protocol, the handshake corresponds to the three-way handshake in the TCP / IP protocol and follows a similar principle: both parties exchange a series of messages to confirm each other's identities, connection parameters, and so on. In the disclosed embodiments, during the handshake process, the sender and receiver confirm each other's requests and responses, ensuring that both parties agree on all details of the connection.

[0104] Then, once the connection is established, the sender and receiver need to know how to send and receive data correctly. In the RoCEv2 protocol, queue pairs are used to manage the sending and receiving of data. Among them, the queue pair sequence number (QueuePair Number, QPN) is a unique identifier used to identify the sending and receiving queue pairs in the RoCEv2 protocol. During the data transmission process, each data packet carries a queue pair sequence number so that the receiving end can correctly place it in the corresponding receiving queue. The packet sequence number (Packet Sequence Number, PSN) is used to identify the order of data packets sent by the sender. The receiving end will ensure the order and integrity of the data packets based on the packet sequence number. In the embodiment of the present disclosure, the target queue pair sequence number and the target data packet sequence number are the QPN and PSN used in the subsequent message transmission process after confirmation by the sender and the receiver.

[0105] After the above steps, a reliable communication connection is established between the sender and the receiver in Ethernet, allowing the two parties to exchange data through the data link layer.

[0106] With respect to step S103 above, the sending end constructs a data transmission message based on the protocol specifications and the parameters negotiated with the receiving end. Since the message is transmitted at the data link layer, it does not need to include network layer and transport layer fields such as the IP field and the UDP field. Furthermore, the data transmission message constructed in the embodiment of the present disclosure may include necessary control information, such as the target queue pair sequence number, the target data packet sequence number, length information, and the actual payload data (i.e., the data to be transmitted).

[0107] Since the data transmission message is transmitted at the data link layer, the data transmission message does not contain an IP field, and further, the data transmission message does not contain a UDP field. In order to facilitate the identification of the data transmission message, the embodiment of the present disclosure can limit the Ethernet type in the data transmission message as the target type.

[0108] The EtherType field, located in the Ethernet frame header, identifies the data type carried in the frame. In the RoCEv2 protocol, since messages are transmitted at the data link layer, a specific EtherType must be assigned to these messages so that the receiving end can correctly identify and process them. Based on this, the transmitting end in the disclosed embodiment determines a preset target type as the EtherType value and includes it in the data transmission message to identify the message as a RoCEv2 message or another specific message type.

[0109] The first flow rule table is created by the receiving end and is the flow rule table that can be searched first when parsing and processing the message. It is also called a flow table or classification table and is used to store information related to the flow rules so that the receiving end can classify and process the received message. Furthermore, the first flow rule table can contain multiple entries (rules), each of which is associated with one or more matching conditions, such as Ethernet type, source MAC address, destination MAC address, etc., or is associated with one or more actions, such as forwarding, discarding, modifying fields, etc. The first flow rule table in the embodiment of the present disclosure can store relevant information of the target type, which is helpful for the subsequent identification of the received message based on the first flow rule table.

[0110] Furthermore, in the disclosed embodiments, a second flow rule table may also be created on the sending end. This second flow rule table, created by the sending end and the first flow rule table to be searched when parsing and processing messages, is also known as a flow table or classification table. It is used to store information related to flow rules, allowing the sending end to classify and process received messages. Furthermore, the second flow rule table is similar to the first flow rule table and will not be described in detail here.

[0111] Regarding the above step S104, in the RoCEv2 protocol, data transmission messages are transmitted through the data link layer. The data link layer is the second layer in the OSI model and is responsible for transmitting data frames between adjacent network nodes.

[0112] After constructing a data transmission message, the transmitter in the disclosed embodiment encapsulates it into a data frame and sends it to the receiver via the data link layer. Upon receiving the data transmission message via the data link layer, the receiver first parses the frame header information. During this process, the receiver pays attention to the value of the EtherType field in the data transmission message. Next, after parsing the EtherType field, the receiver matches its value with an entry in a pre-created first flow rule table at the receiver. If the receiver finds an entry in the flow rule table that matches the EtherType of the data transmission message, it determines that the message is a valid RoCEv2 message, confirms that the data transmission message has been identified, and prepares for subsequent processing.

[0113] Once the receiving end confirms the validity of the data transmission message, it can proceed normally. For example, the receiving end can extract the payload data from the data transmission message and perform further processing as needed, such as verifying sequence numbers and reassembling fragmented messages. Ultimately, the receiving end successfully processes the data transmission message and passes the data to the upper-layer protocol or application for further use.

[0114] In summary, the embodiment of the present disclosure, through steps S101 to S104, sends a network connection request from the sending end to the receiving end. After the receiving end sends a network connection request reply message to the sending end in response to the network connection request, it establishes a communication connection after handshaking with the sending end, and then can obtain the target queue pair sequence number and target data packet sequence number required for the transmission process. Then, the sending end can construct a data transmission message based on the target queue pair sequence number and the target data packet sequence number. Since the data transmission message is transmitted at the data link layer, the data transmission message does not contain an IP field, and further, the data transmission message does not contain a UDP field. In order to facilitate the identification of the data transmission message, the sending end also determines that the Ethernet type in the data transmission message is a preset target type. The receiving end pre-creates a first flow rule table containing the target type. When the sending end sends the data transmission message to the receiving end through the data link layer, the receiving end can identify the Ethernet type in the data transmission message based on the first flow rule table, so that the data transmission message can be normally identified even if it does not contain a UDP message. Finally, the receiving end can normally process the data transmission message after the identification is passed. Therefore, the data transmission message in the embodiment of the present disclosure does not contain IP fields and UDP fields, and can be transmitted at the data link layer, thereby reducing the total length of the message field, effectively increasing the proportion of load data, and thus improving bandwidth utilization.

[0115] It should be noted that the RoCEv2 protocol also requires handshake-related operations before RDMA transmission. One of the purposes of the handshake is to exchange queue pair sequence numbers and data packet sequence numbers for use in subsequent message transmission. The disclosed embodiments provide multiple ways to determine queue pair sequence numbers and data packet sequence numbers, wherein the queue pair sequence numbers can be determined based on the source address and the destination address. Therefore, during the handshake process, it is not necessary to exchange the queue pair sequence numbers and data packet sequence numbers. When the data transmission message is constructed, the queue pair sequence numbers and data packet sequence numbers in the message are not empty. Therefore, a preset initial sequence number can be used to identify the queue pair sequence numbers in the message.

[0116] See also Figure 4 , Figure 4 yes Figure 3 In some embodiments, the target queue pair sequence number is a preset initial sequence number, and the above step S103 may further include steps S201 to S202:

[0117] Step S201, obtaining the source address of the sending end and the destination address of the receiving end;

[0118] Step S202, constructing a data transmission message based on the target queue pair sequence number, target data packet sequence number, source address and destination address;

[0119] Among them, the receiving end identifies the Ethernet type in the data transmission message based on the first flow rule table, and obtains the target queue pair sequence number and target data packet sequence number in the data transmission message after the identification is passed; if the target queue pair sequence number is the same as the preset initial sequence number, the target queue pair sequence number is adjusted based on the source address and destination address, and the data transmission message is processed based on the target data packet sequence number and the adjusted target queue pair sequence number.

[0120] In the above steps, in the disclosed embodiment, the queue pair sequence number required for subsequent message transmission, i.e., the target queue pair sequence number in the above embodiment, is identified as a preset initial sequence number. The initial sequence number can be a value pre-agreed upon by both the transmitter and receiver, allowing the receiver to determine whether to readjust the target queue pair sequence number after identification. For example, the initial sequence number can be 0.

[0121] The source address is the source MAC address, and the destination address is the destination MAC address. Since the source MAC address and destination MAC address are unique between two devices during message transmission, they can be used to identify communication messages between the two devices. Specifically, the sending end can obtain the source address from the sending end and the destination address from the receiving end. When constructing the message, the data transmission message is constructed based on the target queue sequence number, the target data packet sequence number, the source address, and the destination address, so that the data transmission message contains relevant information about the source address and the destination address.

[0122] After the receiving end receives the data transmission message and determines that the Ethernet type in the data transmission message is the target type, it can obtain the target queue pair sequence number and target data packet sequence number in the data transmission message. The receiving end needs to determine the value of the target queue pair sequence number. If the target queue pair sequence number is the same as the preset initial sequence number, it indicates that the sending end and the receiving end did not exchange the corresponding queue pair sequence number and data packet sequence number during the handshake process. Therefore, the sending end pre-sets the target queue pair sequence number to the preset initial sequence number.

[0123] In an embodiment of the present disclosure, if the sending end and the receiving end do not exchange the corresponding queue pair sequence number and data packet sequence number during the handshake process, the two parties can pre-negotiate a queue pair sequence number to be provided in the subsequent data transmission process. Furthermore, the agreed queue pair sequence number can be a target sequence number, and as for the target data packet sequence number, it can start from a fixed value, so it does not need to be confirmed in advance through a negotiated manner. It is understandable that the target sequence number can be bound to the source address and the destination address. When the receiving end obtains the source address and the destination address, it can determine the unique corresponding target sequence number based on the source address and the destination address, and use the target sequence number as the adjusted target queue pair sequence number.

[0124] It should be noted that the target data packet sequence number can also be pre-configured as an original sequence number, which can be a fixed value, such as 0. During subsequent data transmission, the target data packet sequence number starts from this fixed value by default. The embodiments of the present disclosure do not impose specific restrictions on this.

[0125] For example, if the initial sequence number and the original sequence number are both 0, meaning the sender has pre-set the target queue pair sequence number and the target data packet sequence number to 0, then when the receiver recognizes that the target queue pair sequence number is 0, it can obtain the source MAC address and destination MAC address in the data transmission message. Because the source MAC address and destination MAC address are pre-bound to the target sequence number at the receiver, the receiver can determine the unique corresponding target sequence number based on the source MAC address and destination MAC address, and replace 0 with this target sequence number to become the adjusted target queue pair sequence number. The target data packet sequence number can then start from 0.

[0126] Ultimately, the receiving end can process the data transmission message based on the target data packet sequence number and the adjusted target queue pair sequence number, so that subsequent data packets can be processed in the correct queue order, thereby improving the reliability of data transmission. In the embodiment of the present disclosure, by binding the target sequence number with the source address and the destination address, the target queue pair sequence number can be adjusted when the sending end and the receiving end do not exchange the corresponding queue pair sequence number and data packet sequence number during the handshake process, so that the receiving end can distinguish between data packets from different paths and process them separately, thereby supporting more efficient multi-path transmission.

[0127] See also Figure 5 , Figure 5 yes Figure 3 In some embodiments, the above step S102 may further include steps S301 to S303:

[0128] Step S301, in response to a network connection request reply message from a receiving end to a network connection request, sending a handshake request to the receiving end;

[0129] Step S302, in response to the handshake request reply message of the receiving end to the handshake request, establish a communication connection after shaking hands with the receiving end, and exchange corresponding queue pair sequence numbers and data packet sequence numbers with the receiving end;

[0130] In step S303, the queue pair sequence number and the data packet sequence number exchanged from the receiving end are used as the target queue pair sequence number and the target data packet sequence number required for the transmission process.

[0131] In the above steps, the queue pair sequence number and the data packet sequence number can be obtained after exchange between the sender and the receiver, that is, in the embodiment of the present disclosure, the required target queue pair sequence number and target data packet sequence number can also be determined by the sender and the receiver during the handshake process.

[0132] Specifically, after the sender sends a network connection request to the receiver, the receiver responds to the request and sends a network connection request reply message to the sender. The reply message indicates that the receiver has received the connection request and is ready to proceed to the next handshake process.

[0133] After receiving the network connection request reply message from the receiver, the sender sends a handshake request to the receiver. The handshake request may contain information for authentication, parameter negotiation, or confirmation of readiness between the two parties. In the RoCEv2 protocol, this handshake request may also include specific protocol fields to ensure that both parties can understand and respond to the request, but this is not specifically limited in the present embodiment.

[0134] Subsequently, the receiving end responds to the handshake request of the sending end and sends a handshake request reply message, indicating that the receiving end is ready and can start formal data transmission. Therefore, after the two parties successfully exchange handshake requests and replies, the communication connection between them is officially established. At this time, the two parties will exchange a series of parameters, the most important of which are the queue pair sequence numbers and data packet sequence numbers. Therefore, the sending end will save the queue pair sequence numbers and data packet sequence numbers exchanged from the receiving end as the target queue pair sequence numbers and target data packet sequence numbers required in the subsequent data transmission process. Finally, when constructing the data transmission message, the sending end will include these sequence numbers in the data transmission message so that the receiving end can correctly identify and process these messages. Furthermore, the receiving end will also verify the order and integrity of the data transmission message based on these sequence numbers and place it in the correct receiving queue. Therefore, the sending end and the receiving end in the embodiment of the present disclosure can successfully establish a communication connection under the RoCEv2 protocol and are ready for efficient data transmission. The sending end and the receiving end will exchange the required sequence numbers with each other to ensure that subsequent data transmission can proceed smoothly.

[0135] It should be noted that the sending end and the receiving end in the embodiment of the present disclosure may go through a three-way handshake. Figure 6 , Figure 6 This is a schematic diagram of the data transmission process between the sending end and the receiving end provided by the embodiment of the present disclosure. The information exchange between the sending end and the receiving end may include:

[0136] (1) TCP SYN: The sender sends a TCP SYN packet to the receiver to initiate a TCP connection request;

[0137] (2) SYN ACK: After the receiving end responds to the SYN packet, it sends a SYN ACK packet to the client, indicating that it has received the connection request and agrees to establish the connection;

[0138] (3) ACK: After receiving the SYN ACK, the sender sends an ACK packet to the receiver to complete the TCP three-way handshake;

[0139] (4) PSH: After the TCP connection is established, the sender and receiver exchange parameters through a specific RDMA handshake protocol, including the exchange of sequence numbers such as LID, QPN, PSN, and GID (logical ID, queue pair number, packet sequence number, global ID);

[0140] (5) PSH-done: The sender can also send a PSH-done packet to the receiver;

[0141] (6) FIN and ACK (if applicable): In some cases, the RDMA connection may be closed after the data transfer is completed. In this case, the sender can send a FIN packet to the receiver to request the connection to be closed. The receiver will respond with an ACK packet to confirm the connection closure.

[0142] (7) RC Send First: The sender starts RDMA transmission and sends the first RDMA data packet, which is also the first data transmission message. This data packet marks the beginning of RDMA transmission;

[0143] (8) RC Send Middle (can be multiple times): If the amount of data transmitted by RDMA is large, it will be divided into multiple data packets and sent. These intermediate data packets, that is, the data transmission messages sent in the middle, are marked as RC Send Middle until the last data packet;

[0144] (9) RC Send Last: The last RDMA data packet sent by the sender to the receiver, that is, the last data transmission message. This data packet indicates the end of the RDMA transmission;

[0145] (10) RC ACK: After the receiving end processes any data transmission message, it can send the relevant processing results or response to the sending end.

[0146] It is understandable that, in the process of transmitting data transmission messages multiple times, the PSH in each data transmission message will increase accordingly, for example, gradually increasing from a fixed value (such as 0), and the embodiments of the present disclosure do not impose specific limitations on this.

[0147] It should be noted that, in the embodiment of the present disclosure, the corresponding service level can be configured for the current data transmission task at the sending end, that is, the corresponding service level is configured for different sending ends. When the sending end detects a specific service level, it chooses to use the socket to establish a link and retains the handshake operation to exchange relevant information such as QPN and PSN. In the subsequent RDMA transmission process (such as Figure 6 In the process below the middle dotted line), the IP and UDP fields in the data transmission message are deleted, and the transmission method in the data link layer is used for communication, and a specific type (target type) is used in the Ethernet type to realize the recognition of the data transmission message in the receiving end.

[0148] On the contrary, if the QPN and PSN are not exchanged between the sender and the receiver through handshake, the user needs to specify the Ethernet type (target type), source MAC address and destination MAC address when calling the RDMA transmission function at the sender and the receiver. When the program detects that the user has used the specified Ethernet type, source MAC address and destination MAC address, both parties generate corresponding flow rule tables (first flow rule table and second flow rule table) to record the source MAC address and original type. The destination MAC address is saved in the address book of the target serial number bound to the flow rule table, and the data packet receiving method of the specific Ethernet type (target type) is registered. The subsequent transmission process is the same as Figure 6 The process below the middle dotted line is the same.

[0149] See also Figure 7 , Figure 7 4 is a flow chart of a target type determination process in a transmitting end provided by an embodiment of the present disclosure. In some embodiments, the target type is determined by the following steps, which may include steps S401 to S402:

[0150] Step S401, determining any fixed-value Ethernet type as the target type;

[0151] Step S402, alternatively, select any initial type of Ethernet type, construct an Ethernet type determination request based on the initial type, and send the Ethernet type determination request to the receiving end. When an Ethernet type determination request reply message for the Ethernet type determination request sent by the receiving end is received, the initial type is determined as the target type.

[0152] In the above embodiment, there are multiple ways to select the Ethernet type in the data transmission message, that is, there can be multiple processes for determining the target type. For example, an Ethernet type with an arbitrary fixed value can be determined as the target type. This value can be a value that is not occupied by other protocols in the Ethernet standard to ensure its uniqueness and identifiability. The embodiment of the present disclosure is simple and direct by determining an Ethernet type with an arbitrary fixed value as the target type, and does not require an additional communication process to determine the Ethernet type. It should be noted that at the receiving end, the same Ethernet type with a fixed value is also used as the target type so that the data transmission message sent by the sending end can be identified subsequently.

[0153] Furthermore, embodiments of the present disclosure can also determine any initial Ethernet type as the target type through a method agreed upon between the sender and receiver. Specifically, the negotiation process can be initiated by the sender, which selects an initial type as a candidate, constructs an Ethernet type determination request based on this initial type, and sends it to the receiver. After receiving this determination message, the receiver checks the Ethernet type and decides whether to accept it based on its own configuration or policy. The receiver then sends an Ethernet type determination request reply message to the sender, indicating whether to accept the Ethernet type. After receiving the reply message from the receiver, the sender determines whether to use the initial Ethernet type as the target type based on the reply. This embodiment of the present disclosure, which determines the target type through a method agreed upon between the sender and receiver, is adaptable to different network environments and receiver configurations, ensuring compatibility between the sender and receiver. It should be noted that the receiver also uses the initial Ethernet type as the target type so that it can subsequently identify data transmission messages sent by the sender.

[0154] Figure 8 is a flow chart of a communication method based on a data link layer provided by another embodiment of the present disclosure, which can be applied in a receiving end. Figure 8 The communication method may include but is not limited to steps S501 to S505.

[0155] Step S501, receiving a network connection request sent by a sending end;

[0156] Step S502: Send a network connection request reply message to the sending end in response to the network connection request, and establish a communication connection after shaking hands with the sending end;

[0157] Step S503: obtaining a preset target type and creating a first flow rule table containing the target type;

[0158] Step S504: Receive, via the data link layer, a data transmission message sent by the sender, wherein the data transmission message is constructed by the sender based on the target queue pair sequence number and the target data packet sequence number, and the Ethernet type in the data transmission message is a preset target type, and the target queue pair sequence number and the target data packet sequence number are determined by the sender during the handshake operation;

[0159] Step S505 : Identify the Ethernet type in the data transmission message based on the first flow rule table, and process the data transmission message after the identification is successful.

[0160] Regarding step S501 above, in protocols such as RoCEv2, efficient data transmission requires establishing a stable network connection. In the disclosed embodiments, the sender is responsible for initiating data transmission and initiating the network connection process, while the receiver is responsible for receiving data and responding to the sender's connection request and receiving and processing data after the connection is established.

[0161] A network connection request is a message or signal sent by a sender to a receiver, requesting a direct communication connection with the receiver. For example, a network connection request may include information for authentication, negotiation of connection parameters (such as queue pair sequence numbers), and other necessary information to ensure successful data exchange between the two parties. Furthermore, the network connection request may be a TCP request.

[0162] Regarding the above step S502, after receiving the network connection request, the receiving end will perform a series of checks and verifications to ensure that the network connection request is valid. If the receiving end agrees to establish the connection, it will send a network connection request reply message to the sending end. This reply message may include the receiving end's confirmation information, connection parameters and other information, or it may be a confirmation of the sending end's request.

[0163] A handshake is a two-way communication process used to establish a reliable connection between a sender and a receiver. In the RoCEv2 protocol, the handshake corresponds to the three-way handshake in the TCP / IP protocol and follows a similar principle: both parties exchange a series of messages to confirm each other's identities, connection parameters, and so on. In the disclosed embodiments, during the handshake process, the sender and receiver confirm each other's requests and responses, ensuring that both parties agree on all details of the connection.

[0164] Then, once the connection is established, the sender and receiver need to know how to send and receive data correctly. In the RoCEv2 protocol, queue pairs are used to manage the sending and receiving of data. Among them, the queue pair sequence number (QueuePair Number, QPN) is a unique identifier used to identify the sending and receiving queue pairs in the RoCEv2 protocol. During the data transmission process, each data packet carries a queue pair sequence number so that the receiving end can correctly place it in the corresponding receiving queue. The packet sequence number (Packet Sequence Number, PSN) is used to identify the order of data packets sent by the sender. The receiving end will ensure the order and integrity of the data packets based on the packet sequence number. In the embodiment of the present disclosure, the target queue pair sequence number and the target data packet sequence number are the QPN and PSN used in the subsequent message transmission process after confirmation by the sender and the receiver.

[0165] After the above steps, a reliable communication connection is established between the sender and the receiver in Ethernet, allowing the two parties to exchange data through the data link layer.

[0166] With respect to the above-mentioned step S503, the first flow rule table is created by the receiving end, and is the flow rule table that can be first searched when parsing and processing the message. It is also called a flow table or a classification table, and is used to store information related to the flow rules so that the receiving end can classify and process the received message. Furthermore, the first flow rule table can include multiple entries (rules), each of which is associated with one or more matching conditions, such as Ethernet type, source MAC address, destination MAC address, etc., or is associated with one or more actions, such as forwarding, discarding, modifying fields, etc. The first flow rule table in the embodiment of the present disclosure can store relevant information of the target type, which helps to subsequently identify the received message based on the first flow rule table.

[0167] With respect to step S504 above, the sending end constructs a data transmission message based on the protocol specifications and the parameters negotiated with the receiving end. Since the message is transmitted at the data link layer, it does not need to include network layer and transport layer fields such as IP fields and UDP fields. Furthermore, the data transmission message constructed in the embodiments of the present disclosure may include necessary control information, such as the target queue pair sequence number, the target data packet sequence number, length information, and the actual payload data (i.e., the data to be transmitted).

[0168] Since the data transmission message is transmitted at the data link layer, the data transmission message does not contain an IP field, and further, the data transmission message does not contain a UDP field. In order to facilitate the identification of the data transmission message, the embodiment of the present disclosure can limit the Ethernet type in the data transmission message as the target type.

[0169] The EtherType field, located in the Ethernet frame header, identifies the data type carried in the frame. In the RoCEv2 protocol, since messages are transmitted at the data link layer, a specific EtherType must be assigned to these messages so that the receiving end can correctly identify and process them. Based on this, the transmitting end in the disclosed embodiment determines a preset target type as the EtherType value and includes it in the data transmission message to identify the message as a RoCEv2 message or another specific message type.

[0170] In the RoCEv2 protocol, data transmission messages are transmitted through the data link layer. The data link layer is the second layer in the OSI model and is responsible for transmitting data frames between adjacent network nodes.

[0171] Regarding step S505 above, after constructing the data transmission message, the transmitting end in the disclosed embodiment encapsulates it into a data frame and sends it to the receiving end via the data link layer. When the receiving end receives the data transmission message via the data link layer, it first parses the frame header information. During this process, the receiving end pays attention to the value of the EtherType field in the data transmission message. Then, after parsing the EtherType field, the receiving end matches its value with an entry in the first flow rule table pre-created at the receiving end. If the receiving end finds an entry in the flow rule table that matches the EtherType of the data transmission message, it determines that the message is a valid RoCEv2 message, confirms that the data transmission message has been identified, and prepares for subsequent processing.

[0172] Once the receiving end confirms the validity of the data transmission message, it can proceed normally. For example, the receiving end can extract the payload data from the data transmission message and perform further processing as needed, such as verifying sequence numbers and reassembling fragmented messages. Ultimately, the receiving end successfully processes the data transmission message and passes the data to the upper-layer protocol or application for further use.

[0173] In summary, the embodiment of the present disclosure, through steps S501 to S505, sends a network connection request from the sending end to the receiving end. After the receiving end sends a network connection request reply message to the sending end in response to the network connection request, it establishes a communication connection after shaking hands with the sending end, and then can obtain the target queue pair sequence number and target data packet sequence number required for the transmission process. Then, the sending end can construct a data transmission message based on the target queue pair sequence number and the target data packet sequence number. Since the data transmission message is transmitted at the data link layer, the data transmission message does not contain an IP field, and further, the data transmission message does not contain a UDP field. In order to facilitate the identification of the data transmission message, the sending end also determines that the Ethernet type in the data transmission message is a preset target type. The receiving end pre-creates a first flow rule table containing the target type. When the sending end sends the data transmission message to the receiving end through the data link layer, the receiving end can identify the Ethernet type in the data transmission message based on the first flow rule table, so that the data transmission message can be normally identified even if it does not contain a UDP message. Finally, the receiving end can normally process the data transmission message after the identification is passed. Therefore, the data transmission message in the embodiment of the present disclosure does not contain IP fields and UDP fields, and can be transmitted at the data link layer, thereby reducing the total length of the message field, effectively increasing the proportion of load data, and thus improving bandwidth utilization.

[0174] It should be noted that the RoCEv2 protocol also requires handshake-related operations before RDMA transmission. One of the purposes of the handshake is to exchange queue pair sequence numbers and data packet sequence numbers for use in subsequent message transmission. The disclosed embodiments provide multiple ways to determine queue pair sequence numbers and data packet sequence numbers, wherein the queue pair sequence numbers can be determined based on the source address and the destination address. Therefore, during the handshake process, it is not necessary to exchange the queue pair sequence numbers and data packet sequence numbers. When the data transmission message is constructed, the queue pair sequence numbers and data packet sequence numbers in the message are not empty. Therefore, a preset initial sequence number can be used to identify the queue pair sequence numbers in the message.

[0175] See also Figure 9 , Figure 9 yes Figure 8 In some embodiments, the above step S505 may further include steps S601 to S602:

[0176] Step S601: Identify the Ethernet type in the data transmission message based on the first flow rule table, and obtain the target queue pair sequence number and target data packet sequence number in the data transmission message after the identification is successful;

[0177] Step S602: If the target queue pair sequence number is the same as the preset initial sequence number, the target queue pair sequence number is adjusted based on the source address and the destination address, and the data transmission message is processed based on the target data packet sequence number and the adjusted target queue pair sequence number.

[0178] In the above steps, in the disclosed embodiment, the queue pair sequence number required for subsequent message transmission, i.e., the target queue pair sequence number in the above embodiment, is identified as a preset initial sequence number. The initial sequence number can be a value pre-agreed upon by both the transmitter and receiver, allowing the receiver to determine whether to readjust the target queue pair sequence number after identification. For example, the initial sequence number can be 0.

[0179] The source address is the source MAC address, and the destination address is the destination MAC address. Since the source MAC address and destination MAC address are unique between two devices during message transmission, they can be used to identify communication messages between the two devices. Specifically, the sending end can obtain the source address from the sending end and the destination address from the receiving end. When constructing the message, the data transmission message is constructed based on the target queue sequence number, the target data packet sequence number, the source address, and the destination address, so that the data transmission message contains relevant information about the source address and the destination address.

[0180] After the receiving end receives the data transmission message and determines that the Ethernet type in the data transmission message is the target type, it can obtain the target queue pair sequence number and target data packet sequence number in the data transmission message. The receiving end needs to determine the value of the target queue pair sequence number. If the target queue pair sequence number is the same as the preset initial sequence number, it indicates that the sending end and the receiving end did not exchange the corresponding queue pair sequence number and data packet sequence number during the handshake process. Therefore, the sending end pre-sets the target queue pair sequence number to the preset initial sequence number.

[0181] In an embodiment of the present disclosure, if the sending end and the receiving end do not exchange the corresponding queue pair sequence number and data packet sequence number during the handshake process, the two parties can pre-negotiate a queue pair sequence number to be provided in the subsequent data transmission process. Furthermore, the agreed queue pair sequence number can be a target sequence number, and as for the target data packet sequence number, it can start from a fixed value, so it does not need to be confirmed in advance through a negotiated manner. It is understandable that the target sequence number can be bound to the source address and the destination address. When the receiving end obtains the source address and the destination address, it can determine the unique corresponding target sequence number based on the source address and the destination address, and use the target sequence number as the adjusted target queue pair sequence number.

[0182] It should be noted that the target data packet sequence number can also be pre-configured as an original sequence number, which can be a fixed value, such as 0. During subsequent data transmission, the target data packet sequence number starts from this fixed value by default. The embodiments of the present disclosure do not impose specific restrictions on this.

[0183] For example, if the initial sequence number and the original sequence number are both 0, meaning the sender has pre-set the target queue pair sequence number and the target data packet sequence number to 0, then when the receiver recognizes that the target queue pair sequence number is 0, it can obtain the source MAC address and destination MAC address in the data transmission message. Because the source MAC address and destination MAC address are pre-bound to the target sequence number at the receiver, the receiver can determine the unique corresponding target sequence number based on the source MAC address and destination MAC address, and replace 0 with this target sequence number to become the adjusted target queue pair sequence number. The target data packet sequence number can then start from 0.

[0184] Ultimately, the receiving end can process the data transmission message based on the target data packet sequence number and the adjusted target queue pair sequence number, so that subsequent data packets can be processed in the correct queue order, thereby improving the reliability of data transmission. In the embodiment of the present disclosure, by binding the target sequence number with the source address and the destination address, the target queue pair sequence number can be adjusted when the sending end and the receiving end do not exchange the corresponding queue pair sequence number and data packet sequence number during the handshake process, so that the receiving end can distinguish between data packets from different paths and process them separately, thereby supporting more efficient multi-path transmission.

[0185] See also Figure 10 , Figure 10 yes Figure 9 In some embodiments, the above step S602 may further include steps S701 to S702:

[0186] Step S701: Obtain the source address and destination address in the data transmission message, and obtain the corresponding target sequence number in the first flow rule table based on the source address and the destination address;

[0187] Step S702: Using the target sequence number as the adjusted target queue pair sequence number, and processing the data transmission message based on the target data packet sequence number and the adjusted target queue pair sequence number.

[0188] In the above steps, the target sequence number can be pre-stored in the first flow rule table, and the source address and destination address will serve as indexes for the target sequence number in the first flow rule table. Specifically, after the receiving end obtains the source address and destination address in the data transmission message, it uses the source address and destination address as indexes to search the first flow rule table for the corresponding target sequence number.

[0189] After the receiving end obtains the target sequence number corresponding to the source address and the destination address by indexing the first flow rule table. The target sequence number is used as the adjusted target queue pair sequence number, and the receiving end can process the data transmission message based on the target data packet sequence number and the adjusted target queue pair sequence number, so that subsequent data packets can be processed in the correct queue order, thereby improving the reliability of data transmission. In the embodiment of the present disclosure, by binding the target sequence number to the source address and the destination address, the target queue pair sequence number can be adjusted when the sending end and the receiving end do not exchange the corresponding queue pair sequence number and data packet sequence number during the handshake process, so that the receiving end can distinguish between data packets from different paths and process them separately, thereby supporting more efficient multi-path transmission.

[0190] See also Figure 11 , Figure 11 yes Figure 8In some embodiments, the above step S503 may further include steps S801 to S802:

[0191] Step S801: Obtain the source address of the sending end and the destination address of the receiving end, and assign corresponding target sequence numbers to the source address and the destination address;

[0192] Step S802: Create a first flow rule table containing the target type, and add the target sequence number to the first flow rule table using the source address and the destination address as indexes.

[0193] In the above steps, the embodiment of the present disclosure can pre-add the target sequence number to the first flow rule table. Specifically, before communication begins, the receiving end needs to know the source address of the sending end and its own destination address. Then, to distinguish data streams from different sending ends or different sessions, the receiving end needs to assign a unique target sequence number to each source address and destination address pair. For example, an empty QP can be assigned as the target sequence number to facilitate identification of each data stream during subsequent data transmission.

[0194] Next, the receiver needs to maintain a first-flow rule table. After creating the first-flow rule table, it needs to add the assigned target sequence number to the table, using the source and destination addresses as indexes. This way, when the receiver receives a data transmission message, it can use the source and destination addresses in the message as indexes to look up the corresponding target sequence number in the first-flow rule table.

[0195] In some embodiments, the above step S802 may further include the following steps:

[0196] The source address is bound to the target sequence number, the destination address is stored in the address book of the target sequence number, and the target sequence number is added to the first flow rule table.

[0197] In the above steps, in network communications, each data packet (or message) contains a source address (the sender's address) and a destination address (the receiver's address). In the disclosed embodiment, in order to improve the efficiency and accuracy of data transmission, the receiving end needs to associate the source address with the target sequence number to ensure that each source address has a unique identifier for subsequent data packet processing and flow management. Next, the destination address is stored in the address book of the target sequence number, and the target sequence number is added to the first flow rule table, thereby realizing the storage of the target sequence number.

[0198] See also Figure 12 , Figure 12 yes Figure 8In some embodiments, the above step S502 may further include steps S901 to S902:

[0199] Step S901: Generate a network connection request reply message based on the network connection request, and send the network connection request reply message to the sending end;

[0200] Step S902, in response to the handshake request sent by the sending end in response to the network connection request reply message, a handshake request reply message for the handshake request is sent to the sending end, a communication connection is established after shaking hands with the sending end, and the corresponding queue pair sequence number and data packet sequence number are exchanged with the sending end, so that the sending end uses the queue pair sequence number and data packet sequence number exchanged from the receiving end as the target queue pair sequence number and target data packet sequence number required for the transmission process.

[0201] In the above steps, the queue pair sequence number and the data packet sequence number can be obtained after exchange between the sender and the receiver, that is, in the embodiment of the present disclosure, the required target queue pair sequence number and target data packet sequence number can also be determined by the sender and the receiver during the handshake process.

[0202] Specifically, after the sender sends a network connection request to the receiver, the receiver responds to the request and sends a network connection request reply message to the sender. The reply message indicates that the receiver has received the connection request and is ready to proceed to the next handshake process.

[0203] After receiving the network connection request reply message from the receiver, the sender sends a handshake request to the receiver. The handshake request may contain information for authentication, parameter negotiation, or confirmation of readiness between the two parties. In the RoCEv2 protocol, this handshake request may also include specific protocol fields to ensure that both parties can understand and respond to the request, but this is not specifically limited in the present embodiment.

[0204] Subsequently, the receiving end responds to the handshake request of the sending end and sends a handshake request reply message, indicating that the receiving end is ready and can start formal data transmission. Therefore, after the two parties successfully exchange handshake requests and replies, the communication connection between them is officially established. At this time, the two parties will exchange a series of parameters, the most important of which are the queue pair sequence numbers and data packet sequence numbers. Therefore, the sending end will save the queue pair sequence numbers and data packet sequence numbers exchanged from the receiving end as the target queue pair sequence numbers and target data packet sequence numbers required in the subsequent data transmission process. Finally, when constructing the data transmission message, the sending end will include these sequence numbers in the data transmission message so that the receiving end can correctly identify and process these messages. Furthermore, the receiving end will also verify the order and integrity of the data transmission message based on these sequence numbers and place it in the correct receiving queue. Therefore, the sending end and the receiving end in the embodiment of the present disclosure can successfully establish a communication connection under the RoCEv2 protocol and are ready for efficient data transmission. The sending end and the receiving end will exchange the required sequence numbers with each other to ensure that subsequent data transmission can proceed smoothly.

[0205] See also Figure 13 , Figure 13 1001 to 1002:

[0206] Step S1001, determining any fixed-value Ethernet type as the target type;

[0207] Step S1002, alternatively, receiving an Ethernet type determination request sent by the transmitting end, extracting the initial type from the Ethernet type determination request, and sending an Ethernet type determination request reply message in response to the Ethernet type determination request to the transmitting end, with the initial type being used as the target type;

[0208] The Ethernet type determination request is constructed based on the initial type after the sender selects any initial Ethernet type.

[0209] In the above embodiment, there are multiple ways to select the Ethernet type in the data transmission message, that is, there can be multiple processes for determining the target type. For example, an Ethernet type with an arbitrary fixed value can be determined as the target type. This value can be a value that is not occupied by other protocols in the Ethernet standard to ensure its uniqueness and identifiability. The embodiment of the present disclosure is simple and direct by determining an Ethernet type with an arbitrary fixed value as the target type, and does not require an additional communication process to determine the Ethernet type. It should be noted that at the receiving end, the same Ethernet type with a fixed value is also used as the target type so that the data transmission message sent by the sending end can be identified subsequently.

[0210] Furthermore, embodiments of the present disclosure can also determine any initial Ethernet type as the target type through a method agreed upon between the sender and receiver. Specifically, the negotiation process can be initiated by the sender, which selects an initial type as a candidate, constructs an Ethernet type determination request based on this initial type, and sends it to the receiver. After receiving this determination message, the receiver checks the Ethernet type and decides whether to accept it based on its own configuration or policy. The receiver then sends an Ethernet type determination request reply message to the sender, indicating whether to accept the Ethernet type. After receiving the reply message from the receiver, the sender determines whether to use the initial Ethernet type as the target type based on the reply. This embodiment of the present disclosure, which determines the target type through a method agreed upon between the sender and receiver, is adaptable to different network environments and receiver configurations, ensuring compatibility between the sender and receiver. It should be noted that the receiver also uses the initial Ethernet type as the target type so that it can subsequently identify data transmission messages sent by the sender.

[0211] See also Figure 14 The present disclosure also provides a data link layer-based communication device, which is applied to a transmitting end and can implement the data link layer-based communication method in the above-mentioned application end. The data link layer-based communication device includes:

[0212] The request sending module 1401 is used to send a network connection request to the receiving end;

[0213] The first handshake module 1402 is configured to respond to a network connection request reply message from the receiving end to the network connection request, establish a communication connection after handshaking with the receiving end, and obtain a target queue pair sequence number and a target data packet sequence number required for the transmission process;

[0214] a message construction module 1403 for constructing a data transmission message based on the target queue pair sequence number and the target data packet sequence number, and determining the Ethernet type in the data transmission message as a preset target type, wherein a first flow rule table containing the target type is pre-created in the receiving end;

[0215] The message transmission module 1404 is configured to send a data transmission message to a receiving end through a data link layer, so that the receiving end identifies the Ethernet type in the data transmission message based on the first flow rule table and processes the data transmission message after the identification is successful.

[0216] In summary, a data link layer-based communication device executes a data link layer-based communication method, wherein a network connection request is sent from a sending end to a receiving end. After the receiving end sends a network connection request reply message to the sending end in response to the network connection request, a communication connection is established after a handshake with the sending end. The target queue pair sequence number and the target data packet sequence number required for the transmission process can then be obtained. Next, the sending end can construct a data transmission message based on the target queue pair sequence number and the target data packet sequence number. Since the data transmission message is transmitted at the data link layer, the data transmission message does not contain an IP field, and further, the data transmission message does not contain a UDP field. To facilitate the identification of the data transmission message, the sending end also determines that the Ethernet type in the data transmission message is a preset target type. A first flow rule table containing the target type is pre-created in the receiving end. When the sending end sends a data transmission message to the receiving end through the data link layer, the receiving end can identify the Ethernet type in the data transmission message based on the first flow rule table, thereby allowing the data transmission message to be normally identified even if it does not contain a UDP message. Finally, the receiving end can process the data transmission message normally after the identification is passed. Therefore, the data transmission message in the embodiment of the present disclosure does not contain IP fields and UDP fields, and can be transmitted at the data link layer, thereby reducing the total length of the message field, effectively increasing the proportion of load data, and thus improving bandwidth utilization.

[0217] The specific implementation of the data link layer-based communication device is basically the same as the specific implementation of the data link layer-based communication method applied in the transmitting end, and will not be repeated here. Under the premise of meeting the requirements of the embodiments of the present disclosure, the data link layer-based communication device can also be provided with other functional modules to implement the data link layer-based communication method in the above-mentioned embodiment.

[0218] See also Figure 15 The present disclosure also provides a data link layer-based communication device, which is applied to a receiving end and can implement the data link layer-based communication method in the receiving end. The data link layer-based communication device includes:

[0219] The request receiving module 1501 is used to receive a network connection request sent by a sending end;

[0220] The second handshake module 1502 is configured to send a network connection request reply message to the sending end in response to the network connection request, and establish a communication connection after shaking hands with the sending end;

[0221] The flow rule creation module 1503 is used to obtain a preset target type and create a first flow rule table containing the target type;

[0222] The message receiving module 1504 is configured to receive, via the data link layer, a data transmission message sent by a transmitter, wherein the data transmission message is constructed by the transmitter based on the target queue pair sequence number and the target data packet sequence number, and the Ethernet type in the data transmission message is a preset target type, and the target queue pair sequence number and the target data packet sequence number are determined by the transmitter during a handshake operation;

[0223] The message processing module 1505 is configured to identify the Ethernet type in the data transmission message based on the first flow rule table, and process the data transmission message after the identification is successful.

[0224] In summary, a data link layer-based communication device executes a data link layer-based communication method, wherein a network connection request is sent from a sending end to a receiving end. After the receiving end sends a network connection request reply message to the sending end in response to the network connection request, a communication connection is established after a handshake with the sending end. The target queue pair sequence number and the target data packet sequence number required for the transmission process can then be obtained. Next, the sending end can construct a data transmission message based on the target queue pair sequence number and the target data packet sequence number. Since the data transmission message is transmitted at the data link layer, the data transmission message does not contain an IP field, and further, the data transmission message does not contain a UDP field. To facilitate the identification of the data transmission message, the sending end also determines that the Ethernet type in the data transmission message is a preset target type. A first flow rule table containing the target type is pre-created in the receiving end. When the sending end sends a data transmission message to the receiving end through the data link layer, the receiving end can identify the Ethernet type in the data transmission message based on the first flow rule table, thereby allowing the data transmission message to be normally identified even if it does not contain a UDP message. Finally, the receiving end can process the data transmission message normally after the identification is passed. Therefore, the data transmission message in the embodiment of the present disclosure does not contain IP fields and UDP fields, and can be transmitted at the data link layer, thereby reducing the total length of the message field, effectively increasing the proportion of load data, and thus improving bandwidth utilization.

[0225] The specific implementation of the data link layer-based communication device is basically the same as the specific implementation of the data link layer-based communication method applied in the receiving end, and will not be repeated here. Under the premise of meeting the requirements of the embodiments of the present disclosure, the data link layer-based communication device can also be provided with other functional modules to implement the data link layer-based communication method in the above-mentioned embodiment.

[0226] The present disclosure also provides an electronic device comprising a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned data link layer-based communication method. The electronic device can be any intelligent terminal, such as a tablet computer or an in-vehicle computer.

[0227] See also Figure 15 , Figure 15 The hardware structure of an electronic device according to another embodiment is shown. The electronic device includes:

[0228] The processor 1601 may be implemented as a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is configured to execute relevant programs to implement the technical solutions provided by the embodiments of the present disclosure.

[0229] The memory 1602 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 1602 can store operating devices and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1602 and is called by the processor 1601 to execute the data link layer-based communication method of the embodiments of the present disclosure;

[0230] Input / output interface 1603, used to implement information input and output;

[0231] Communication interface 1604, used to implement communication interaction between this device and other devices, which can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WiFi, Bluetooth, etc.);

[0232] Bus 1605 , which transmits information between various components of the device (e.g., processor 1601 , memory 1602 , input / output interface 1603 , and communication interface 1604 );

[0233] The processor 1601 , the memory 1602 , the input / output interface 1603 and the communication interface 1604 are connected to each other within the device via a bus 1605 .

[0234] An embodiment of the present disclosure further provides a computer-readable storage medium storing a computer program, which implements the above-mentioned data link layer-based communication method when executed by a processor.

[0235] The memory, as a non-transient computer-readable storage medium, can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory may include a high-speed random access memory and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory may optionally include a memory remotely arranged relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0236] The embodiments described in the embodiments of the present disclosure are intended to more clearly illustrate the technical solutions of the embodiments of the present disclosure and do not constitute a limitation on the technical solutions provided by the embodiments of the present disclosure. Those skilled in the art will appreciate that with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of the present disclosure are also applicable to similar technical problems.

[0237] Those skilled in the art will understand that the technical solutions shown in the drawings do not constitute a limitation on the embodiments of the present disclosure, and may include more or fewer steps than shown in the drawings, or a combination of certain steps, or different steps.

[0238] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, i.e., they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of this embodiment.

[0239] Those skilled in the art will appreciate that all or some of the steps, devices, and functional modules / units in the methods disclosed above may be implemented as software, firmware, hardware, or appropriate combinations thereof.

[0240] The terms "first," "second," "initial," "original," "target," and the like (if any) in the specification of the present disclosure and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate so that the embodiments of the present disclosure described herein can be implemented in orders other than those illustrated or described herein. In addition, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusions, e.g., a process, method, apparatus, product, or device comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such process, method, product, or device.

[0241] It should be understood that in the present disclosure, "at least one (item)" refers to one or more, and "plurality" refers to two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0242] In the several embodiments provided in the present disclosure, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the above-mentioned units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0243] The units described above as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0244] In addition, the functional units in the various embodiments of the present disclosure may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0245] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present disclosure is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including multiple instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method of each embodiment of the present disclosure. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store programs.

[0246] The preferred embodiments of the present disclosure are described above with reference to the accompanying drawings, but are not intended to limit the scope of the present disclosure. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and essence of the present disclosure should be within the scope of the present disclosure.

Claims

1. A communication method based on a data link layer, characterized in that: Applied to the transmitting end, the communication method includes: Send a network connection request to the receiving end; In response to a network connection request reply message from the receiving end to the network connection request, establishing a communication connection after shaking hands with the receiving end, and obtaining a target queue pair sequence number and a target data packet sequence number required for a transmission process; Constructing a data transmission message based on the target queue pair sequence number and the target data packet sequence number, and determining an Ethernet type in the data transmission message as a preset target type, wherein a first flow rule table containing the target type is pre-created in the receiving end; The data transmission message is sent to the receiving end through the data link layer, so that the receiving end identifies the Ethernet type in the data transmission message based on the first flow rule table, and processes the data transmission message after the identification is successful.

2. The communication method based on the data link layer according to claim 1, characterized in that: The target queue pair sequence number is a preset initial sequence number; The constructing of a data transmission message based on the target queue pair sequence number and the target data packet sequence number includes: Obtaining a source address in the sending end and a destination address in the receiving end; Constructing a data transmission message based on the target queue pair sequence number, the target data packet sequence number, the source address and the destination address; Among them, the receiving end identifies the Ethernet type in the data transmission message based on the first flow rule table, and obtains the target queue pair sequence number and the target data packet sequence number in the data transmission message after identification; if the target queue pair sequence number is the same as the preset initial sequence number, the target queue pair sequence number is adjusted based on the source address and the destination address, and the data transmission message is processed based on the target data packet sequence number and the adjusted target queue pair sequence number.

3. The communication method based on the data link layer according to claim 1, characterized in that: The step of responding to a network connection request reply message sent by the receiving end to the network connection request, establishing a communication connection after handshaking with the receiving end, and obtaining a target queue pair sequence number and a target data packet sequence number required for the transmission process includes: sending a handshake request to the receiving end in response to a network connection request reply message sent by the receiving end to the network connection request; In response to a handshake request reply message from the receiving end to the handshake request, establishing a communication connection after shaking hands with the receiving end, and exchanging corresponding queue pair sequence numbers and data packet sequence numbers with the receiving end; The queue pair sequence number and the data packet sequence number exchanged from the receiving end are used as the target queue pair sequence number and the target data packet sequence number required for the transmission process.

4. The communication method based on the data link layer according to claim 1, characterized in that: The target type is determined by the following steps, including: Determining an arbitrary fixed-value Ethernet type as the target type; Alternatively, an Ethernet type of any initial type is selected, an Ethernet type determination request is constructed based on the initial type, and the Ethernet type determination request is sent to the receiving end. When an Ethernet type determination request reply message for the Ethernet type determination request sent by the receiving end is received, the initial type is determined to be the target type.

5. A communication method based on a data link layer, characterized in that: Applied to a receiving end, the communication method includes: Receive the network connection request sent by the sender; Sending a network connection request reply message for the network connection request to the sending end, and establishing a communication connection after shaking hands with the sending end; Obtaining a preset target type and creating a first-flow rule table containing the target type; receiving, through a data link layer, a data transmission message sent by the transmitting end, wherein the data transmission message is constructed by the transmitting end based on a target queue pair sequence number and a target data packet sequence number, an Ethernet type in the data transmission message is a preset target type, and the target queue pair sequence number and the target data packet sequence number are determined by the transmitting end during a handshake operation; The Ethernet type in the data transmission message is identified based on the first flow rule table, and the data transmission message is processed after the identification is successful.

6. The communication method based on the data link layer according to claim 5, characterized in that: The identifying the Ethernet type in the data transmission message based on the first flow rule table, and processing the data transmission message after the identification is successful, includes: Identifying the Ethernet type in the data transmission message based on the first flow rule table, and obtaining the target queue pair sequence number and the target data packet sequence number in the data transmission message after the identification is successful; If the target queue pair sequence number is the same as the preset initial sequence number, the target queue pair sequence number is adjusted based on the source address and the destination address, and the data transmission message is processed based on the target data packet sequence number and the adjusted target queue pair sequence number.

7. The data link layer-based communication method according to claim 6, wherein: The adjusting the target queue pair sequence number based on the source address and the destination address, and processing the data transmission message based on the target data packet sequence number and the adjusted target queue pair sequence number, includes: Obtain the source address and the destination address in the data transmission message, and obtain a corresponding target sequence number in the first flow rule table based on the source address and the destination address; The target sequence number is used as the adjusted target queue pair sequence number, and the data transmission message is processed based on the target data packet sequence number and the adjusted target queue pair sequence number.

8. The data link layer-based communication method according to claim 6, wherein: The creating of the first flow rule table containing the target type includes: Obtaining a source address in the sending end and a destination address in the receiving end, and assigning corresponding target sequence numbers to the source address and the destination address; A first flow rule table containing the target type is created, and the target sequence number is added to the first flow rule table using the source address and the destination address as indexes.

9. The data link layer-based communication method according to claim 8, characterized in that: The adding the target sequence number to the first flow rule table by using the source address and the destination address as indexes includes: The source address is bound to the target sequence number, the destination address is stored in the address book of the target sequence number, and the target sequence number is added to the first flow rule table.

10. The data link layer-based communication method according to claim 5, characterized in that: The sending of a network connection request reply message for the network connection request to the sending end, and establishing a communication connection after shaking hands with the sending end, includes: generating a network connection request reply message based on the network connection request, and sending the network connection request reply message to the sending end; In response to the handshake request sent by the sending end for the network connection request reply message, a handshake request reply message for the handshake request is sent to the sending end, a communication connection is established after shaking hands with the sending end, and the corresponding queue pair sequence number and data packet sequence number are exchanged with the sending end, so that the sending end uses the queue pair sequence number and the data packet sequence number obtained from the exchange from the receiving end as the target queue pair sequence number and target data packet sequence number required for the transmission process.

11. The communication method based on the data link layer according to claim 5, characterized in that: The target type is determined by the following steps, including: Determining an arbitrary fixed-value Ethernet type as the target type; Alternatively, receiving an Ethernet type determination request sent by the transmitting end, extracting an initial type from the Ethernet type determination request, and sending an Ethernet type determination request reply message for the Ethernet type determination request to the transmitting end, and then using the initial type as the target type; The Ethernet type determination request is constructed based on any initial Ethernet type selected by the sending end.

12. A communication device based on a data link layer, characterized in that: Applied to a transmitting end, the communication device includes: A request sending module, used for sending a network connection request to a receiving end; a first handshake module, configured to respond to a network connection request reply message from the receiving end to the network connection request, establish a communication connection after shaking hands with the receiving end, and obtain a target queue pair sequence number and a target data packet sequence number required for a transmission process; a message construction module, configured to construct a data transmission message based on the target queue pair sequence number and the target data packet sequence number, and determine an Ethernet type in the data transmission message as a preset target type, wherein a first flow rule table containing the target type is pre-created in the receiving end; The message transmission module is used to send the data transmission message to the receiving end through the data link layer, so that the receiving end identifies the Ethernet type in the data transmission message based on the first flow rule table and processes the data transmission message after the identification is passed.

13. A communication device based on a data link layer, characterized in that: Applied to a receiving end, the communication device includes: A request receiving module, used to receive a network connection request sent by a sending end; A second handshake module is used to send a network connection request reply message for the network connection request to the sending end, and establish a communication connection after shaking hands with the sending end; A flow rule creation module, configured to obtain a preset target type and create a first flow rule table containing the target type; a message receiving module, configured to receive, through a data link layer, a data transmission message sent by the transmitting end, wherein the data transmission message is constructed by the transmitting end based on a target queue pair sequence number and a target data packet sequence number, and the Ethernet type in the data transmission message is the preset target type, and the target queue pair sequence number and the target data packet sequence number are determined by the transmitting end during a handshake operation; The message processing module is used to identify the Ethernet type in the data transmission message based on the first flow rule table, and process the data transmission message after the identification is successful.

14. An electronic device, characterized in that: The electronic device includes a memory and a processor, the memory stores a computer program, and when the processor executes the computer program, it implements the data link layer-based communication method described in any one of claims 1 to 4, or the data link layer-based communication method described in any one of claims 5 to 11.

15. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the data link layer-based communication method according to any one of claims 1 to 4 or the data link layer-based communication method according to any one of claims 5 to 11 is implemented.

Images