Method, computer readable medium and electronic device for data transmission based on IP layer

Abstract

The application discloses a method for IP layer-based data transmission, a computer readable medium and an electronic device. When applied to a sending end, the method comprises the following steps: sending a service message to a receiving end; an extended header of the service message carries a sequence number; determining whether the receiving end successfully receives the service message according to a message type fed back by the receiving end; if the receiving end fails to receive the service message, finding a target service message corresponding to a missing sequence number according to the missing sequence number, and taking the target service message as a retransmission message; the missing sequence number is a sequence number of a missing service message; transmitting the retransmission message to the receiving end; each IP message is identified by the sequence number, so that the receiving end can perform packet loss detection without deep analysis, and the performance pressure of the device can be reduced; and the sending end selectively retransmits the packet loss according to the receiving result fed back by the receiving end, so that the number of retransmission data packets in the network can be reduced, and the wide-area data transmission efficiency can be improved.

Description

Technical Field

[0001] This invention belongs to the technical field of data transmission, and more particularly relates to methods, computer-readable media, and electronic devices for data transmission based on the IP layer. Background Technology

[0002] Currently, Remote Direct Memory Access (RDMA) over Converged Ethernet Version 2 (RoCEv2) combined with wide-area lossless technology is widely researched and piloted. RoCEv2 uses User Datagram Protocol (UDP) as its transport layer protocol. Since UDP itself does not provide reliability guarantees, RoCEv2 relies on retransmission mechanisms to recover lost packets in packet loss scenarios. However, in related technologies, RoCEv2 typically employs a go-back-N retransmission mechanism. This mechanism leads to a large number of retransmitted packets in the network during packet loss, severely impacting network throughput. Alternatively, some technologies add a specific layer after the UDP layer in the RoCEv2 message. This specific layer sets the data sequence number, requiring resolution to that layer, which places high demands on device performance.

[0003] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0004] The purpose of this invention is to provide a method, computer-readable medium, and electronic device for data transmission based on the IP layer, in order to solve the problems in related technologies that require deep parsing and multiple backtracking and retransmission steps.

[0005] According to one aspect of the embodiments of this application, a method for data transmission based on the IP layer is provided, applied at a sending end, the method comprising:

[0006] Send a service message to the receiving end; the extended header of the service message carries a sequence number;

[0007] Based on the message type returned by the receiving end, determine whether the receiving end has successfully received the service message;

[0008] If the receiving end fails to receive a service message, it will look up the corresponding target service message based on the lost sequence number and use the target service message as a retransmission message; the lost sequence number is the sequence number of the lost service message.

[0009] The retransmission message is transmitted to the receiving end.

[0010] In some embodiments, determining whether the receiving end has successfully received the service message based on the message type fed back by the receiving end includes: when receiving an acknowledgment response message fed back by the receiving end, if the first retransmission control value and the acknowledgment sequence number are parsed from the extended header of the acknowledgment response message, it is determined that the service message corresponding to the acknowledgment sequence number is transmitted normally; the first retransmission control value is used to represent that the service message does not need to be retransmitted, and the acknowledgment sequence number is an identification number generated by the receiving end based on the sequence number.

[0011] In some embodiments, determining whether the receiver has successfully received the service message based on the message type fed back by the receiver includes: when a retransmission request message is received from the receiver, if the second retransmission control value and the lost sequence number are parsed from the extended header of the retransmission request message, then it is determined that the service message corresponding to the lost sequence number has failed to be transmitted; the second retransmission control value is used to indicate that the service message needs to be retransmitted.

[0012] In some embodiments, the method further includes: obtaining a first segment identifier of the sending end and a third segment identifier of the receiving end; the first segment identifier and the third segment identifier are segment identifiers applied to the service message; setting the source address field of the service message to the first segment identifier, and setting the destination address field of the service message to the third segment identifier.

[0013] According to one aspect of the embodiments of this application, a method for data transmission based on the IP layer is provided, applied at a receiving end, the method comprising:

[0014] Receive service messages sent by the sending end; the extended header of the service message carries a sequence number;

[0015] Based on the sequence number parsed from the service message, determine the first retransmission control value and the acknowledgment sequence number of the acknowledgment response message; the first retransmission control value is used to indicate that the service message does not need to be retransmitted, and the acknowledgment sequence number is an identification number generated by the receiving end based on the sequence number;

[0016] An acknowledgment message is generated based on the first retransmission control value and the acknowledgment sequence number, and then sent to the sending end.

[0017] Based on whether the sequence numbers meet the continuity requirement, determine whether to send a retransmission request message to the sender.

[0018] In some embodiments, determining whether to send a retransmission request message to the sender based on whether the sequence number conforms to continuity includes: when the sequence number does not conform to continuity, determining a second retransmission control value and a lost sequence number for the retransmission request message; the second retransmission control value is used to represent that the service message needs to be retransmitted, and the lost sequence number is the sequence number of the lost service message; generating a retransmission request message based on the lost sequence number and the second retransmission control value; and sending the retransmission request message to the sender.

[0019] In some embodiments, generating a retransmission request message based on the lost sequence number and the second retransmission control value includes: setting the sequence number field of the extension header of the retransmission request message to the lost sequence number; and setting the retransmission control bit of the extension header of the retransmission request message to the second retransmission control value.

[0020] In some embodiments, the method further includes: obtaining a second segment identifier of the sending end and a fourth segment identifier of the receiving end; the second segment identifier and the fourth segment identifier are segment identifiers applied to acknowledgment messages and retransmission request messages; when generating an acknowledgment message, setting the source address field of the acknowledgment message to the fourth segment identifier and setting the destination address field of the acknowledgment message to the second segment identifier; when generating a retransmission request message, setting the source address field of the retransmission request message to the fourth segment identifier and setting the destination address field of the retransmission request message to the second segment identifier.

[0021] According to one aspect of the embodiments of this application, a computer medium is provided having a computer program stored thereon, which, when executed by a processor, implements the IP layer-based data transmission method provided in any embodiment of this application.

[0022] According to one aspect of the embodiments of this application, an electronic device is provided, including: a processor; a memory for storing executable instructions of the processor; the processor executes the executable instructions to enable the electronic device to implement the IP layer-based data transmission method provided in any embodiment of this application.

[0023] In the technical solution of this application, the sending end sends a service message to the receiving end, and the extended header of the service message carries a sequence number. The receiving end can obtain the sequence number by parsing the IP layer of the service message, and can use the sequence number to distinguish between different service messages. If the receiving end successfully receives the service message, it generates an acknowledgment reply message, which carries a first retransmission control value and an acknowledgment sequence number. The acknowledgment field in the acknowledgment reply message is set to the acknowledgment sequence number to distinguish it from the sequence number in the service message. The sending end can obtain the first retransmission control value and the acknowledgment sequence number by parsing the acknowledgment reply message to the IP layer, thereby confirming that the receiving end has successfully received the service message. If the receiving end fails to receive a service packet, it generates a retransmission request packet and sends it back to the sending end. The sending end parses the retransmission request packet down to the IP layer to obtain the second retransmission control value and the lost sequence number. Then, it determines the retransmission packet based on the lost sequence number. Finally, it transmits the retransmission packet to the receiving end. In this way, the receiving end can identify the service packets that the sending end failed to transmit by using the sequence number and then send the corresponding retransmission request packet, instead of starting the retransmission from the failed service packets. This reduces network congestion during data retransmission, improves network transmission efficiency, and the packet parsing only needs to reach a shallow layer instead of a deep layer, which reduces the requirements on equipment performance and the time spent on packet loss detection.

[0024] It should be understood in this application that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this application. Attached Figure Description

[0025] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0026] Figure 1 A schematic diagram of the RoCEv2 message format in related technologies is shown.

[0027] Figure 2 The illustration shows a flowchart of a data transmission method based on the IP layer applied to the sending end, according to an embodiment of this application.

[0028] Figure 3 The illustration shows a schematic diagram of service message transmission provided in an embodiment of this application.

[0029] Figure 4 The illustration shows a schematic diagram of an IPv6 packet header provided in one embodiment of this application.

[0030] Figure 5 The illustration shows a schematic diagram of a service message provided in an embodiment of this application.

[0031] Figure 6 The illustration shows a schematic diagram of an acknowledgment response message provided in an embodiment of this application.

[0032] Figure 7 The illustration shows a schematic diagram of a retransmission request message provided in an embodiment of this application.

[0033] Figure 8 The illustration shows a schematic diagram of a service message provided in an embodiment of this application.

[0034] Figure 9 The illustration shows a schematic flowchart of a data transmission method based on the IP layer applied to a receiving end according to an embodiment of this application.

[0035] Figure 10 The illustration shows a schematic diagram of an acknowledgment response message provided in an embodiment of this application.

[0036] Figure 11 The illustration shows a schematic diagram of a retransmission request message provided in an embodiment of this application.

[0037] Figure 12 The diagram illustrates the structure of an electronic device according to an embodiment of this application.

[0038] Figure 13 A schematic block diagram of a computer system architecture for implementing an electronic device according to embodiments of the present application is shown. Detailed Implementation

[0039] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0040] Furthermore, the features, structures, or characteristics described in this application can be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0041] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0042] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0043] The following describes the relevant technologies of this application in order to better understand the technical solution of this application.

[0044] like Figure 1 The diagram illustrates the existing RoCEv2 message format, where the layers from shallow to deep are the Ethernet layer, IP / IPv6 layer, UDP layer, IBTH layer, and Payload layer. This existing RoCEv2 message uses UDP as the transport layer protocol. UDP is a connectionless transport layer protocol and lacks packet loss detection, retransmission, and congestion control, thus limiting its data transmission reliability. Therefore, related technologies add an IBTH layer, identifying messages using a PSN (Personal Sequence Number). The receiving end needs to parse down to the IBTH layer to perform packet loss detection, but the deeper the parsing layer, the higher the requirements for the parsing device. In wide-area, long-distance data transmission scenarios prone to packet loss, performing packet loss detection every time would be very time-consuming, failing to meet the requirements of high-speed data transmission. Therefore, this approach is more suitable for lossless networks with no packet loss. In wide-area, long-distance data transmission scenarios, the ability to quickly detect and retransmit packet loss is crucial. Figure 2 As shown, this application provides a data transmission method based on the IP layer. The method is applied to the sending end and includes steps S110 to S140. The specific process is as follows.

[0045] S110. Send a service message to the receiving end; the extended header of the service message carries a sequence number.

[0046] Specifically, in this application, the sending end refers to the end responsible for sending service messages, and the receiving end refers to the end responsible for receiving service messages. This does not mean that the sending end only sends messages and does not receive them, nor does it mean that the receiving end only receives messages and does not send them; there is a data interaction process between the sending and receiving ends. In the data transmission process of this application, a service message can be simply understood as a message that the sending end does not retransmit to the receiving end, and the service message is transmitted within the service channel. For example... Figure 3 As shown, the unfilled boxes on the left represent service messages 0, 1, 2, 3, and 4 to be sent by the sender. Service message 4 was received incorrectly, meaning the subsequent retransmission message 4 (the box filled with a diagonal line) is not a service message. It should be understood that the service message 4 and the retransmission message 4 have different names for the purpose of differentiation, but the specific message structure and content of the retransmission message 4 can be the same as the service message 4. The header of the service message differs from the header of the signaling channel message; the specific differences will be explained later and will not be elaborated here. Figure 4 The diagram shows a general format for IP packets. The header section begins with the version number and extends to the extended header field. Adding data after the sequence number field creates an IP packet carrying that data. The section from the version number to the destination address is the basic header, while the section from the next header to the extended header field is the extended header. The sequence number corresponding to the service message can be set in the extended header field, hence it can also be called the sequence number field. The variable number of bits in the sequence number field means that the user can set it according to their needs. For example, the user can set the header extension length to 160 bits, with the next header occupying 8 bits, the header extension length field occupying 8 bits, the extended header data field occupying 16 bits, and the sequence number field occupying 128 bits. Or, as shown below... Figure 5 The header shown has a user-defined reserved field (i.e., an extended header data field) that occupies 16 bits, and a sequence number field that has a 32-bit sequence number. Therefore, the total extended length of the header is 64 bits, which is recorded using the 8-bit extended length field.

[0047] S120. Based on the message type returned by the receiving end, determine whether the receiving end has successfully received the service message.

[0048] Specifically, in some embodiments, S120 includes: when receiving an acknowledgment message from the receiving end, if the first retransmission control value and acknowledgment sequence number are obtained from the extended header of the acknowledgment message, then it is determined that the service message corresponding to the acknowledgment sequence number is transmitted normally. Specifically, the acknowledgment message is a message sent by the receiving end to the sending end after successfully receiving a service message. The acknowledgment message and the service message do not belong to the same channel; the acknowledgment message belongs to the signaling channel. As mentioned earlier, if the service channel also carries the transmission of the acknowledgment message, it can easily lead to channel congestion and reduced data transmission efficiency. Transmitting the acknowledgment message in the signaling channel can improve the channel congestion problem and increase data transmission efficiency. Figure 3 The direction indicated by the long dashed line is the transmission direction of the acknowledgment message. The receiving end can include parsable information in the acknowledgment message to notify the sending end that a certain service message has been successfully received. For example... Figure 6 As shown, the receiver sets the Reserve field of the acknowledgment message to occupy 15 bits, and the retransmission control bit to occupy 1 bit. When the retransmission control bit is the first retransmission control value, it means that the service message corresponding to the acknowledgment message does not need to be retransmitted; that is, the first retransmission control value is used to represent that the service message does not need to be retransmitted. When the retransmission control bit is the second retransmission control value, it means that the service message corresponding to the acknowledgment message needs to be retransmitted; that is, the second retransmission control value is used to represent that the service message needs to be retransmitted. For example, if the first retransmission control value is 0 and the second retransmission control value is 1, when the sender parses the retransmission control bit of a message as 0, it determines that the service message corresponding to the acknowledgment message is transmitted normally; when the sender parses the retransmission control bit of a message as 1, it determines that the service message corresponding to the acknowledgment message is transmitted abnormally. The service message corresponding to the acknowledgment message can be determined by parsing the acknowledgment field of the acknowledgment message. Specifically, when the receiving end successfully receives a service message, it can parse the corresponding sequence number. The receiving end can then generate an acknowledgment sequence number based on this sequence number. It should be understood that the sending end knows in advance the pattern of how the receiving end generates the acknowledgment sequence number. After the sending end parses the acknowledgment response message to the IP layer to obtain the acknowledgment sequence number, it can reconstruct the corresponding sequence number and thus know the service message corresponding to the acknowledgment response message.

[0049] In another embodiment, the confirmation sequence number is the sequence number of the next service message following the received service message. For example... Figure 3As shown, in the acknowledgment message 0 corresponding to service message 0, the receiving end sets the acknowledgment field to the sequence number of service message 1. The sending end knows beforehand that the acknowledgment field in the acknowledgment message is the sequence number of the next service message. Therefore, when the sending end parses the retransmission control bit of a message as the first retransmission control bit, it can determine that the message is an acknowledgment message; and when it parses the acknowledgment field as the sequence number of service message 1, the sending end can determine that the acknowledgment message indicates that the receiving end has successfully received service message 0. Thus, the sending end can determine the successful reception of the service message by using the specific values ​​of the retransmission control bit and the acknowledgment field in the acknowledgment message.

[0050] In some embodiments, S120 further includes: when a retransmission request message is received from the receiver, if the second retransmission control value and the lost sequence number are obtained by parsing the extended header of the retransmission request message, then it is determined that the service message corresponding to the lost sequence number has failed to be transmitted.

[0051] Specifically, such as Figure 7 The header structure of the retransmission request message shown is as follows: Figure 6 The header structure of the acknowledgment message shown is similar, but the retransmission control bits of the retransmission request message are changed to the second retransmission control value, and the acknowledgment field of the acknowledgment message is also modified to the lost message sequence number. The lost message sequence number refers to the sequence number corresponding to the service message with reception errors, such as... Figure 3 As shown, the receiving end detects an abnormal reception of service packet 4 and then generates a retransmission request packet NACK4. The sending end receives the retransmission request packet NACK4 and parses the second retransmission control value and the lost sequence number from its extended header, thus determining that the service packet corresponding to the lost sequence number has failed to be transmitted. Furthermore, the retransmission request packet and the service packet do not belong to the same channel, while the retransmission request packet and the acknowledgment reply packet can belong to the same channel. This is because neither the retransmission request packet nor the acknowledgment reply packet needs to carry a large amount of data information; therefore, sharing a signaling channel can still meet the requirements of high-speed data transmission. In another embodiment, a separate channel can be set up for the retransmission request packet to ensure that the transmission and reception of various packets do not interfere with each other, further improving the efficiency of data transmission.

[0052] S130. If the receiving end fails to receive the service message, it will find the corresponding target service message according to the lost sequence number and use the target service message as a retransmission message.

[0053] Specifically, the target service message refers to the service message whose sequence number matches the lost sequence number. After sending a service message, the sending end can cache the service message in a preset location and associate the service message with the sequence number. Therefore, if the receiving end fails to receive the service message, since the lost sequence number is actually the sequence number of the failed service message, the corresponding target service message can be directly found in the preset location based on the lost sequence number, and a retransmission message can be obtained. Conversely, if the receiving end successfully receives the service message, the service message whose sequence number matches the acknowledgment sequence number can be deleted from the preset location, freeing up the storage space in the preset location.

[0054] S140. Transmit the retransmission message to the receiving end.

[0055] Specifically, such as Figure 3 As shown, after receiving the retransmission request message NACK4, the sending end parses it and generates retransmission message 4 (the box filled with slashes). This retransmission message 4 is then sent back to the receiving end. Although retransmission messages and service messages are transmitted on the same channel, the probability of data packet loss is still low; that is, the service message channel can simultaneously handle both data retransmission and service message transmission.

[0056] In the technical solution of this application, a service message is sent to the receiving end; the extended header of the service message carries a sequence number; based on the message type returned by the receiving end, it is determined whether the receiving end has successfully received the service message; if the receiving end fails to receive the service message, the corresponding target service message is found according to the lost sequence number, and the target service message is used as a retransmission message; the lost sequence number is the sequence number of the lost service message; the retransmission message is transmitted to the receiving end; thus, the extended header of the service message carries a sequence number, which can identify each IP packet. The receiving end can perform packet loss detection without relying on deep layers such as TCP, IBTH, or application layer, which can reduce the performance pressure on the device. Moreover, after receiving the retransmission request message, the sending end retransmits the corresponding data instead of retransmitting all packets after the transmission error message, which can reduce the number of retransmitted data packets in the network and improve the energy efficiency of wide area data transmission.

[0057] In some embodiments, the method further includes: obtaining a first segment identifier of the sending end and a third segment identifier of the receiving end; the first segment identifier and the third segment identifier are segment identifiers applied to the service message; setting the source address field of the service message to the first segment identifier, and setting the destination address field of the service message to the third segment identifier.

[0058] Specifically, the first and second segment identifiers are two address identifiers for the sending end. By adding these address identifiers to the message, other ends can identify whether the message was sent or received by the sending end. The third and fourth segment identifiers are two address identifiers for the receiving end. By adding these address identifiers to the message, other ends can identify whether the message was received or sent by the receiving end. Specifically, each message header sets a source address and a destination address, where the source address represents the address identifier of the message's origin, and the destination address represents the address identifier of the message's destination. Furthermore, the service messages and retransmission messages sent by the sending end use different address identifiers, thus establishing two information channels: one for service messages and one for signaling messages (retransmission messages belong to signaling messages). This allows for reserving a separate information channel for service messages, reducing interference from retransmission signaling. Figure 5 The business message header shown has a source address set to the first segment identifier published by the sender and a destination address set to the third segment identifier published by the receiver. The message type, as well as the sending and receiving addresses, can be determined through the specific segment identifiers in the source and destination addresses. For example, if the first segment identifier of sender A is 2001:DB8:A::11 and the third segment identifier of receiver B is 2001:DB8:B::21, then... Figure 8 The service message 4 shown is Figure 3 The service message 4 sent by the transmitting end (the box without fill on the left) has a source address of 2001:DB8:A::11, a destination address of 2001:DB8:B::21, and a sequence number of 4. The retransmission message 4 is... Figure 3 The retransmission message 4 sent by the sending end (the box filled with diagonal lines on the left) has the same message structure as the service message 4. Its source address is 2001:DB8:A::11, its destination address is 2001:DB8:B::21, and its sequence number field is the lost sequence number 4, which can be the same as the sequence number 4.

[0059] like Figure 9 As shown, this application provides a method for data transmission based on the IP layer. When applied to the receiving end, this method may include steps S210 to S240, and the specific process is as follows.

[0060] S210, Receive service messages sent by the sending end; the extended header of the service message carries a sequence number.

[0061] Specifically, as mentioned earlier, the extended header of the service message sent by the sending end carries a sequence number, which is used to identify each service message. After receiving the service message, the receiving end can follow subsequent steps to acknowledge and respond to each service message, or determine whether any messages have been lost.

[0062] S220. When the sequence number is obtained from parsing the received service message, determine the first retransmission control value and the acknowledgment sequence number of the acknowledgment response message.

[0063] Specifically, an acknowledgment message is the receiver's feedback confirming successful reception of a service message, thus informing the sender that the service message has been successfully received. The first retransmission control value indicates that the service message does not require retransmission, and the acknowledgment sequence number is an identification number generated by the receiver based on the sequence number. For example... Figure 6 As shown, the receiving end sets a retransmission control bit and an acknowledgment field in the extended header, setting the retransmission control bit to the first retransmission control value and the acknowledgment field to the acknowledgment sequence number. Specifically, the acknowledgment sequence number can be obtained by performing a specified operation on the sequence number and a specified value. For example, if the sequence number is 'a', the specified value is 'b', and the specified operation is addition, then the acknowledgment sequence number c = a + b. It should be understood that the sending end knows in advance the pattern of how the receiving end generates the acknowledgment sequence number. Therefore, after parsing the acknowledgment response message to the IP layer to obtain the acknowledgment sequence number, the sending end can reconstruct the corresponding sequence number, thereby identifying the service message corresponding to the acknowledgment response message.

[0064] In another embodiment, the confirmation sequence number is the sequence number of the next service message following the received service message. For example... Figure 3 As shown, in the acknowledgment message 0 corresponding to service message 0, the receiving end sets the acknowledgment field to the sequence number of service message 1. The sending end knows beforehand that the acknowledgment field in the acknowledgment message is the sequence number of the next service message. Therefore, when the sending end parses the retransmission control bit of a message as the first retransmission control bit, it can determine that the message is an acknowledgment message; and when it parses the acknowledgment field as the sequence number of service message 1, the sending end can determine that the acknowledgment message indicates that the receiving end has successfully received service message 0. Thus, the sending end can determine the successful reception of the service message by using the specific values ​​of the retransmission control bit and the acknowledgment field in the acknowledgment message.

[0065] S230. Generate an acknowledgment message based on the first retransmission control value and the acknowledgment sequence number, and send the acknowledgment message to the sending end.

[0066] Specifically, the retransmission control bit in the acknowledgment message is set to the first retransmission control value, and the acknowledgment field is set to the acknowledgment sequence number. This allows the information of the service message corresponding to the acknowledgment sequence number that does not require retransmission to be carried in the acknowledgment message. For example... Figure 10 As shown, the first retransmission control value can be 0, and the acknowledgment field can be sequence number 3. Assuming the preset acknowledgment field is the sequence number of the next service message after the successfully received service message, then this acknowledgment response message is feedback to the sender notifying them that service message 2 has been successfully received. The acknowledgment response message and the service message do not belong to the same channel; the acknowledgment response message belongs to the signaling channel.

[0067] S240. Determine whether to send a retransmission request message to the sending end based on whether the sequence number meets the continuity requirement.

[0068] Specifically, a sequence number continuity pattern is pre-defined for the sending end and sent to the receiving end. This pattern allows the receiving end to confirm successful reception of each service message after parsing it. If the parsed sequence numbers do not conform to the continuity pattern, it indicates a failed reception of a service message, prompting the sending end to send a retransmission request message. After identifying the failed service message, the value of the retransmission control bit in the retransmission request message is determined. This second retransmission control value indicates that the service message needs to be retransmitted. Upon receiving this retransmission request message, the sending end can determine the reception anomaly of the service message corresponding to the lost sequence number based on the second retransmission control value.

[0069] In the technical solution of this application, when the sequence number is obtained from the parsing of the received service message, the first retransmission control value and the acknowledgment sequence number of the acknowledgment response message corresponding to the service message are determined; an acknowledgment response message is generated based on the first retransmission control value and the acknowledgment sequence number; if the parsed sequence number does not meet the preset conditions, the second retransmission control value is determined, and the lost sequence number is determined based on the sequence number; a retransmission request message is determined based on the lost sequence number and the second retransmission control value; and the retransmission request message is sent to the sending end. In this way, the receiving end can obtain the sequence number by parsing down to the IP layer of the service message, and determine the lost data based on the change pattern of the sequence number. The receiving end can perform packet loss detection without relying on deep layers such as TCP, IBTH, or application layer, which can reduce the performance pressure on the device. Moreover, specifying the data to be retransmitted to the sending end does not require the sending end to go back n steps to retransmit, which can reduce the number of retransmitted data packets in the network and improve the energy efficiency of wide area data transmission.

[0070] In some embodiments, a retransmission request message is sent to the sending end based on whether the sequence number meets the continuity requirement, including S2410 to S2430, and the specific process is as follows.

[0071] S2410. When the sequence number does not conform to continuity, determine the second retransmission control value and the lost sequence number of the retransmission request message.

[0072] Specifically, the second retransmission control value indicates that a service message needs to be retransmitted. The lost sequence number is the sequence number of the lost service message. This lost sequence number can be the same as the sequence number of the service message that failed to be received, or it can be obtained by performing a specified operation on the corresponding sequence number. This specified operation method is also pre-stored at the sending end.

[0073] S2420. Generate a retransmission request message based on the lost sequence number and the second retransmission control value.

[0074] Specifically, the sequence number field of the retransmission request message's extension header is set to the lost sequence number; the retransmission control bit of the retransmission request message's extension header is set to the second retransmission control value. Assuming the retransmission control bit occupies 1 bit, the second retransmission control value is 1, and the lost sequence number is sequence number 4, then we can obtain the following... Figure 11 The header of the retransmission request message shown.

[0075] S2430, Send a retransmission request message to the sender.

[0076] Specifically, such as Figure 3 As shown, the receiving end sends a retransmission request message NACK4 to the sending end. Since the retransmission request message and the service message do not belong to the same channel, both the retransmission request message and the acknowledgment message can be transmitted through the signaling channel. This ensures that the service messages sent by the sending end and the signaling messages sent by the receiving end do not interfere with each other, further improving data transmission efficiency.

[0077] In some embodiments, the serial number meets a preset condition, and the preset condition is that the difference between adjacent serial numbers is a specified value; determining the lost serial number based on the serial number includes: sorting the serial numbers according to the receiving time to obtain a serial number queue; calculating the difference between each group of adjacent serial numbers in the serial number queue; selecting groups whose difference between adjacent serial numbers is not a specified value as candidate groups; and determining the lost serial number based on the difference between the candidate groups.

[0078] For example, the preset condition is that the difference between adjacent sequence numbers is 1, and the starting value of the sequence number is 0. Under normal circumstances, the sequence numbers parsed by the receiving end are 0, 1, ..., n, where n represents the sequence number of the nth service message sent by the sending end. If the sending end sends service messages 0 to 6, the receiving end sorts the parsed sequence numbers according to the reception time of the service messages to obtain the sequence number queues 0, 1, 2, 3, 5, and 6. The difference between adjacent sequence numbers 3 and 5 is 2, and the difference between other adjacent sequence numbers meets the specified value of 1. The candidate group is determined to be (3,5). The difference of this candidate group is 2, which means that a service message 4 was not received. Finally, the lost sequence number is determined to be 4.

[0079] In some embodiments, the method further includes: obtaining a second segment identifier of the sending end and a fourth segment identifier of the receiving end; the second segment identifier and the fourth segment identifier are segment identifiers applied to acknowledgment messages and retransmission request messages; when generating an acknowledgment message, setting the source address field of the acknowledgment message to the fourth segment identifier and setting the destination address field of the acknowledgment message to the second segment identifier; when generating a retransmission request message, setting the source address field of the retransmission request message to the fourth segment identifier and setting the destination address field of the retransmission request message to the second segment identifier.

[0080] Specifically, the second segment identifier is the address identifier published by the sending end. By adding this address identifier to the message, other ends can identify whether the message was sent or received by the sending end. The fourth segment identifier is the address identifier published by the receiving end. By adding this address identifier to the message, other ends can identify whether the message was received or sent by the receiving end. Specifically, a source address and a destination address are set in each message header, where the source address represents the address identifier of the message's origin, and the destination address represents the address identifier of the message's destination. Assuming the second segment identifier of sending end A is 2001:DB8:A::12, and the fourth segment identifier of receiving end B is 2001:DB8:B::22, as follows... Figure 10 The image shows the header of the acknowledgment message 2 sent by the receiving end. The source address of the acknowledgment message 2 is 2001:DB8:B::22, the destination address is 2001:DB8:A::12, the retransmission control bit is the first retransmission control value 0, and the sequence number field is the sequence number 3 of the next service message 3 after service message 2. Figure 11 This is the header of the retransmission request message 4 sent by the receiving end. The source address of the retransmission request message 4 is 2001:DB8:B::22, the destination address is 2001:DB8:A::12, the retransmission control bit is the second retransmission control value 1, and the sequence number field is the lost sequence number 4.

[0081] The following describes the electronic device of this application, such as... Figure 12 As shown, this application provides an electronic device 1200, which includes a processor 1210 and a memory 1220. The memory 1220 is used to store executable instructions of the processor. The processor 1210 executes the executable instructions to enable the electronic device to implement the IP layer-based data transmission method provided in any embodiment of this application.

[0082] Specifically, the IP-layer-based data transmission method provided in this application is stored in the memory 1220 of the electronic device. The processor 1210 executes the IP-layer-based data transmission method to send service packets from the sending end to the receiving end. The extended header of the service packet carries a sequence number. The receiving end parses the IP layer of the service packet to obtain the sequence number, which can be used to distinguish between different service packets. If the receiving end successfully receives the service packet, it generates an acknowledgment message, which carries a first retransmission control value and an acknowledgment sequence number. The acknowledgment field in the acknowledgment message is set to the acknowledgment sequence number to distinguish it from the sequence number in the service packet. The sending end parses the acknowledgment message to the IP layer to obtain the first retransmission control value and the acknowledgment sequence number, thus confirming that the receiving end has successfully received the service packet. If the receiving end fails to receive a service packet, it generates a retransmission request packet and sends it back to the sending end. The sending end parses the retransmission request packet down to the IP layer to obtain the second retransmission control value and the lost sequence number. Then, it determines the retransmission packet based on the lost sequence number. Finally, it transmits the retransmission packet to the receiving end. In this way, the receiving end can identify the service packets that the sending end failed to transmit by using the sequence number and then send the corresponding retransmission request packet, instead of starting the retransmission from the failed service packets. This reduces network congestion during data retransmission, improves network transmission efficiency, and the packet parsing only needs to reach a shallow layer instead of a deep layer, which reduces the requirements on equipment performance and the time spent on packet loss detection.

[0083] It should be understood that the specific implementation details of the electronic device in this application have been explained in detail in the corresponding method embodiments, and will not be repeated here.

[0084] Figure 13 A schematic block diagram of a computer system architecture for implementing an electronic device according to embodiments of the present application is shown.

[0085] It should be noted that, Figure 13 The computer system 1300 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0086] like Figure 13As shown, the computer system 1300 includes a processor 1301, which can be a CPU (Central Processing Unit) or an MCU (Microcontroller Unit). The processor 1301 can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1302 or programs loaded from storage section 1308 into random access memory (RAM). The random access memory 1303 also stores various programs and data required for system operation. The processor 1301, ROM 1302, and RAM 1303 are interconnected via a bus 1304. An input / output interface 1305 (I / O interface) is also connected to the bus 1304.

[0087] The following components are connected to the input / output interface 1305: an input section 1306 including a keyboard, mouse, etc.; an output section 1307 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1308 including a hard disk, etc.; and a communication section 1309 including a network interface card such as a local area network card, modem, etc. The communication section 1309 performs communication processing via a network such as the Internet. A drive 1310 is also connected to the input / output interface 1305 as needed. Removable media 1311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on the drive 1310 as needed so that computer programs read from them can be installed into the storage section 1308 as needed.

[0088] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1309, and / or installed from removable medium 1311. When the computer program is executed by processor 1301, it performs various functions defined in the system of this application.

[0089] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0090] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0091] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0092] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the embodiments according to this application.

[0093] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0094] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for data transmission based on the IP layer, characterized in that, Applied to the sending end, the method includes: Obtain the first segment identifier of the sending end and the third segment identifier of the receiving end; Set the source address field of the service message to the first segment identifier, and set the destination address field of the service message to the third segment identifier; Send a service message to the receiving end; the extended header of the service message carries a sequence number; Based on the message type returned by the receiving end, it is determined whether the receiving end has successfully received the service message. The message type includes acknowledgment message and retransmission request message. The service message and the retransmission request message do not belong to the same channel. The acknowledgment message and the retransmission request message belong to the same channel. The source address field of the service message and the retransmission request message is set to the fourth segment identifier of the receiving end. The destination address field of the service message and the retransmission request message is set to the second segment identifier of the sending end. If the receiving end fails to receive the service message, it searches for the corresponding target service message based on the lost sequence number and uses the target service message as a retransmission message. The source address field of the retransmission message is set to the first segment identifier, and the destination address field of the retransmission message is set to the third segment identifier. The lost sequence number is the sequence number of the lost service message. The retransmission message is transmitted to the receiving end.

2. The data transmission method based on the IP layer as described in claim 1, characterized in that, The step of determining whether the receiving end has successfully received the service message based on the message type returned by the receiving end includes: When an acknowledgment message is received from the receiving end, if the first retransmission control value and the acknowledgment sequence number are obtained by parsing the extended header of the acknowledgment message, it is determined that the service message corresponding to the acknowledgment sequence number is transmitted normally; the first retransmission control value is used to indicate that the service message does not need to be retransmitted, and the acknowledgment sequence number is an identification number generated by the receiving end based on the sequence number.

3. The data transmission method based on the IP layer as described in claim 1, characterized in that, The step of determining whether the receiving end has successfully received the service message based on the message type returned by the receiving end includes: When a retransmission request message is received from the receiving end, if the second retransmission control value and the lost sequence number are obtained by parsing the extended header of the retransmission request message, it is determined that the service message corresponding to the lost sequence number has failed to be transmitted; the second retransmission control value is used to indicate that the service message needs to be retransmitted.

4. A data transmission method based on the IP layer, characterized in that, Applied to the receiving end, the method includes: Obtain the second segment identifier of the sending end and the fourth segment identifier of the receiving end; the second segment identifier and the fourth segment identifier are segment identifiers applied to acknowledgment response messages and retransmission request messages; The receiver receives a service message sent by the sending end; the extended header of the service message carries a sequence number, the source address field of the service message is set to the first segment identifier of the sending end, and the destination address field of the service message is set to the third segment identifier of the receiving end. Based on the sequence number parsed from the service message, a first retransmission control value and an acknowledgment sequence number are determined for the acknowledgment response message; the first retransmission control value is used to indicate that the service message does not need to be retransmitted, and the acknowledgment sequence number is an identification number generated by the receiving end based on the sequence number; An acknowledgment response message is generated based on the first retransmission control value and the acknowledgment sequence number, and the acknowledgment response message is sent to the sending end; When generating the acknowledgment message, the source address field of the acknowledgment message is set to the fourth segment identifier, and the destination address field of the acknowledgment message is set to the second segment identifier; Based on whether the sequence number meets the continuity requirement, determine whether to send a retransmission request message to the sending end; When generating the retransmission request message, the source address field of the retransmission request message is set to the fourth segment identifier, and the destination address field of the retransmission request message is set to the second segment identifier. The service message and the retransmission request message do not belong to the same channel, while the acknowledgment message and the retransmission request message belong to the same channel.

5. The data transmission method based on the IP layer as described in claim 4, characterized in that, The step of determining whether to send a retransmission request message to the sending end based on whether the sequence number meets the continuity requirement includes: When the sequence number does not meet the continuity requirement, the second retransmission control value and the lost sequence number of the retransmission request message are determined; the second retransmission control value is used to indicate that the service message needs to be retransmitted, and the lost sequence number is the sequence number of the lost service message; The retransmission request message is generated based on the lost sequence number and the second retransmission control value; The retransmission request message is sent to the sending end.

6. The data transmission method based on the IP layer as described in claim 5, characterized in that, The step of generating the retransmission request message based on the lost sequence number and the second retransmission control value includes: Set the sequence number field of the extended header of the retransmission request message to the lost sequence number; Set the retransmission control bit in the extended header of the retransmission request message to the second retransmission control value.

7. A computer-readable medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the IP layer-based data transmission method as described in any one of claims 1 to 6.

8. An electronic device, characterized in that, include: processor; Memory for storing the executable instructions of the processor; The processor executes the executable instructions to enable the electronic device to implement the IP layer-based data transmission method as described in any one of claims 1 to 6 above.

Images