Data transmission method based on IP layer, computer readable medium and electronic equipment

Abstract

The invention discloses a data transmission method based on an IP layer, a computer readable medium and electronic equipment. When the method is applied to a sending end, the method comprises the following steps: sending a service message to a receiving end; the extension header of the service message carries a serial number; determining whether the receiving end successfully receives the service message according to the message type fed back by the receiving end; if the receiving end fails to receive the service message, searching a corresponding target service message according to the lost serial number, and taking the target service message as a retransmission message; the lost serial number is the serial number of the lost service message; transmitting the retransmission message to a receiving end; each IP message is identified through the serial number, so that a receiving end can carry out packet loss detection without analyzing to a deep layer, and the performance pressure of equipment can be reduced; and the sending end selectively retransmits the lost packets according to the receiving result fed back by the receiving end, so that the number of retransmitted data packets in the network can be reduced, and the wide-area data transmission energy efficiency is improved.

Description

Technical Field

[0001] The present invention belongs to the technical field of data transmission, and in particular, relates to a method, a computer-readable medium and an electronic device for data transmission based on an IP layer. Background Art

[0002] At present, the remote direct memory access (RDMA) + wide area lossless technology based on the Ethernet remote direct memory access protocol (RDMA over Converged Ethernet version 2, RoCEv2) has been widely studied and piloted. RoCEv2 uses the User Datagram Protocol (UDP) as the transport layer protocol, and UDP itself does not provide reliability guarantee. Therefore, in the packet loss scenario, RoCEv2 needs to rely on the retransmission mechanism to recover the lost data packets. However, in related technologies, RoCEv2 usually adopts a go-back-N retransmission mechanism. This retransmission mechanism will cause a large number of retransmission packets in the network when packets are lost, thereby seriously affecting the network throughput performance. Or in related technologies, a specific layer is added after the UDP layer of the RoCEv2 message. The data sequence number is set in the specific layer, and it needs to be parsed to the specific layer, which has high performance requirements for the device.

[0003] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of the present application, and therefore may include information that does not constitute the prior art known to ordinary technicians in the field. Summary of the invention

[0004] The purpose of the present invention is to provide a method, a computer-readable medium and an electronic device for data transmission based on the IP layer, so as to solve the problem in the related technology that it is necessary to parse to a deep layer and fall back and retransmit multiple steps.

[0005] According to one aspect of an embodiment of the present application, a method for data transmission based on an IP layer is provided, which is applied to a sending end, and the method includes:

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

[0007] Determine whether the receiving end has successfully received the service message based on the message type fed back by the receiving end;

[0008] If the receiving end fails to receive the service message, it searches for the corresponding target service message according to the lost sequence number and uses the target service message as the retransmission message; the lost sequence number is the sequence number of the lost service message;

[0009] Transmit the retransmission message to the receiving end.

[0010] In some embodiments, based on the message type fed back by the receiving end, determining whether the receiving end has successfully received the service message includes: when receiving a confirmation response message fed back by the receiving end, if a first retransmission control value and a confirmation sequence number are obtained by parsing the extended header of the confirmation response message, then determining that the service message corresponding to the confirmation 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 confirmation sequence number is an identification number generated by the receiving end based on the sequence number.

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

[0012] In some embodiments, the method also 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 business message; setting the source address field of the business message to the first segment identifier, and setting the destination address field of the business message to the third segment identifier.

[0013] According to one aspect of an embodiment of the present application, a method for data transmission based on an IP layer is provided, which is applied to a receiving end, and the method includes:

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

[0015] Determine the first retransmission control value and confirmation sequence number of the confirmation response message according to the sequence number parsed from the service message; the first retransmission control value is used to represent that the service message does not need to be retransmitted, and the confirmation sequence number is an identification number generated by the receiving end according to the sequence number;

[0016] Generate a confirmation response message according to the first retransmission control value and the confirmation sequence number, and send the confirmation response message to the sending end;

[0017] Whether to send a retransmission request message to the sender is determined based on whether the sequence number meets the continuity requirement.

[0018] In some embodiments, whether to send a retransmission request message to the sending end is determined based on whether the sequence number meets the continuity, including: when the sequence number does not meet the continuity, determining the second retransmission control value and the lost sequence number of 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; based on the lost sequence number and the second retransmission control value, generating a retransmission request message; and sending the retransmission request message to the sending end.

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

[0020] In some embodiments, the method also 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 confirmation response messages and retransmission request messages; when generating a confirmation response message, the source address field of the confirmation response message is set to the fourth segment identifier, and the destination address field of the confirmation response message is set to the second segment identifier; when generating a 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.

[0021] According to one aspect of an embodiment of the present application, a computer medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the method for data transmission based on the IP layer provided in any embodiment of the present application is implemented.

[0022] According to one aspect of an embodiment of the present 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 method for data transmission based on the IP layer provided in any embodiment of the present application.

[0023] In the technical solution of the present application, the sending end sends a service message to the receiving end, and the extension 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 distinguish each service message by using the sequence number; if the receiving end successfully receives the service message, a confirmation response message is generated, and the confirmation response message carries a first retransmission control value and a confirmation sequence number, wherein the confirmation field in the confirmation response message is set to the confirmation sequence number to be distinguished from the sequence number in the service message. The sending end can obtain the first retransmission control value and the confirmation sequence number by parsing the confirmation response message to the IP layer, so as to determine that the receiving end has successfully received the service message. If the receiving end fails to receive the service message, a retransmission request message is generated and fed back to the sending end; the sending end parses the retransmission request message to the IP layer to obtain the second retransmission control value and the lost sequence number, and then determines the retransmission message according to the lost sequence number; finally, the retransmission message is transmitted to the receiving end; in this way, the service message that the sending end fails to transmit can be identified by the receiving end through the sequence number, and then a retransmission request message is sent accordingly, instead of retransmitting the service message that fails to transmit, which can reduce network congestion when retransmitting data and improve network transmission efficiency. Moreover, the message only needs to be parsed to the shallow layer instead of the deep layer, which can reduce the requirements for equipment performance and reduce the time spent on packet loss detection.

[0024] It should be understood that the above general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The drawings herein are incorporated into the specification and constitute a part of the specification, illustrate embodiments consistent with the present application, and together with the specification are used to explain the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application, and for ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0026] Figure 1 A schematic diagram schematically shows a RoCEv2 message format in the related art.

[0027] Figure 2 The flowchart of the IP layer-based data transmission method applied to the sending end provided in one embodiment of the present application is schematically shown.

[0028] Figure 3 A schematic diagram of service message transmission provided in an embodiment of the present application is schematically shown.

[0029] Figure 4 A schematic diagram of an IPv6 message header provided in an embodiment of the present application is schematically shown.

[0030] Figure 5 A schematic diagram of a service message provided in an embodiment of the present application is schematically shown.

[0031] Figure 6 A schematic diagram of a confirmation response message provided in an embodiment of the present application is schematically shown.

[0032] Figure 7 A schematic diagram of a retransmission request message provided in an embodiment of the present application is schematically shown.

[0033] Figure 8 A schematic diagram of a service message provided in an embodiment of the present application is schematically shown.

[0034] Fig. 9 The flowchart of the IP layer-based data transmission method applied to the receiving end provided by one embodiment of the present application is schematically shown.

[0035] Fig.10 A schematic diagram of a confirmation response message provided in an embodiment of the present application is schematically shown.

[0036] Fig.11 A schematic diagram of a retransmission request message provided in an embodiment of the present application is schematically shown.

[0037] Fig.12 The structural block diagram of an electronic device provided by an embodiment of the present application is schematically shown.

[0038] Fig.13 The structure block diagram of a computer system for implementing an electronic device according to an embodiment of the present application is schematically shown. DETAILED DESCRIPTION

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

[0040] In addition, the features, structures or characteristics described in the present application may be combined in one or more embodiments in any suitable manner. In the following description, many specific details are provided to provide a full understanding of the embodiments of the present application. However, those skilled in the art will appreciate that the technical scheme of the present application can be put into practice without one or more of the specific details, or other methods, components, devices, steps, etc. may be adopted. In other cases, known methods, devices, realizations or operations are not shown or described in detail to avoid blurring the various aspects of the present 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 may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0042] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0043] The following is an introduction to the relevant technologies of this application to help you better understand the technical solutions of this application.

[0044] like Figure 1 The figure shows a schematic diagram of the existing RoCEv2 message format, where from shallow to deep layers are the Ethernet layer, IP / IPv6 layer, UDP layer, IBTH layer and Payload layer. The existing RoCEv2 message uses UDP as the transport layer protocol. It is known that UDP itself is a connectionless transport layer protocol, which does not have the design of packet loss detection, retransmission and traffic congestion control, so it has limitations in terms of data transmission reliability. Therefore, the related technology adds an IBTH layer, and identifies the message with the message sequence number PSN at the IBTH layer. The receiving end needs to parse to the IBTH layer to perform packet loss detection, but the deeper the analysis, the higher the requirements for the parsing device. In scenarios such as wide-area and long-distance data transmission where packet loss is prone to occur, if packet loss detection is required every time, the time spent on packet loss detection will be very large and cannot meet the requirements of high-speed data transmission. Therefore, this solution is more suitable for a completely lossless network with no packet loss. In wide-area and long-distance data transmission scenarios, the ability to quickly detect packet loss and retransmit packet loss is an important indicator. Therefore, if Figure 2 As shown, the present application provides a method for data transmission based on the IP layer, which is applied to the sending end and includes S110 to S140. The specific process is as follows.

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

[0046] Specifically, the sending end in this application refers to the end responsible for sending business messages, and the receiving end refers to the end responsible for receiving business messages. It does not mean that the sending end only sends messages but does not receive messages, nor does it mean that the receiving end only receives messages but does not send messages. There is a data interaction process between the sending end and the receiving end. In the data transmission process of this application, business messages can be simply understood as messages that the sending end does not retransmit to the receiving end, and business messages are transmitted in the business channel. Figure 3 As shown, the unfilled boxes on the left represent the business messages 0, 1, 2, 3 and 4 to be sent by the sender, among which the reception of business message 4 is abnormal, that is, the subsequent retransmitted message 4 (the box filled with slashes) is not a business message. It should be understood that the names of business message 4 and retransmitted message 4 are different in order to distinguish the messages, but the specific message structure and specific message content of retransmitted message 4 can be the same as business message 4. The header of the business message is different from the header of the signaling channel message. The specific difference will be explained later and will not be expanded here. Figure 4 The figure shows a common format of IP packets. The header part is from the version number to the extended header field. By adding data information after the sequence number field, an IP packet carrying data information can be formed. The part from the version number to the destination address belongs to the basic header, and the part from the next header to the extended header field belongs to the extended header part. The serial number corresponding to the service message can be set in the extended header field, so the extended header field can also be called the serial number field. The variable number of bits in the sequence number field means that the user can set it according to the needs. For example, the user sets the header extension length to 160 bits, of which the next header occupies 8 bits, the header extension length field occupies 8 bits, the extended header data field is set to occupy 16 bits, and the sequence number field occupies 128 bits. Or as Figure 5 In the header shown, the user sets the reserved field (i.e., the extended header data field) to occupy 16 bits, and the sequence number of the sequence number field is 32 bits, so the extended length of the total header is 64 bits, which is recorded by the 8 bits of the extended length field.

[0047] S120: Determine whether the receiving end has successfully received the service message according to the message type fed back by the receiving end.

[0048] Specifically, in some embodiments, S120 includes: when receiving a confirmation response message fed back by the receiving end, if the first retransmission control value and the confirmation sequence number are parsed from the extended header of the confirmation response message, it is determined that the service message corresponding to the confirmation sequence number is transmitted normally. Specifically, the confirmation response message is a message fed back to the sending end after the receiving end successfully receives the service message. The confirmation response message and the service message do not belong to the same channel. The confirmation response message belongs to the signaling channel. As mentioned above, if the service channel also carries the transmission of the confirmation response message, it is easy to cause channel congestion and reduce the data transmission efficiency. Transmitting the confirmation response message in the signaling channel can improve the channel congestion problem and improve the data transmission efficiency. Figure 3 The direction indicated by the long dashed line is the transmission direction of the confirmation response message. The receiving end can set information that the sending end can parse in the confirmation response message to notify the sending end that a certain service message has been successfully received. Figure 6 As shown, the receiving end sets the reserved (Reserve) field of the confirmation response message to occupy 15 bits, and the retransmission control bit occupies 1 bit. When the retransmission control bit is the first retransmission control value, it means that the business message corresponding to the confirmation response message does not need to be retransmitted, that is, the first retransmission control value is used to represent that the business message does not need to be retransmitted; when the retransmission control bit is the second retransmission control value, the business message corresponding to the confirmation response message needs to be retransmitted, that is, the second retransmission control value is used to represent that the business message needs to be retransmitted. For example, the first retransmission control value is 0, and the second retransmission control value is 1. When the sending end parses the retransmission control bit of a message as 0, it is determined that the business message corresponding to the confirmation response message is transmitted normally. When the sending end parses the retransmission control bit of a message as 1, it is determined that the business message corresponding to the confirmation response message is abnormally transmitted. The business message corresponding to the confirmation response message can be determined by parsing the confirmation field of the confirmation response message. Specifically, when the receiving end successfully receives a service message, it can parse the corresponding sequence number, and then the receiving end can generate a confirmation sequence number based on the sequence number. It should be understood that the sending end knows in advance the rule for the receiving end to generate the confirmation sequence number. After the sending end parses the confirmation response message to the IP layer to obtain the confirmation sequence number, it can restore the corresponding sequence number, thereby knowing the service message corresponding to the confirmation response message.

[0049] In another embodiment, the confirmation sequence number is the sequence number of the next service message of the received service message. Figure 3As shown, the receiving end sets the confirmation field to the sequence number of service message 1 in the confirmation response message 0 corresponding to the service message 0, and the sending end knows in advance that the confirmation field in the confirmation response message is the sequence number of the next service message. Then, 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 a confirmation response message; and when the confirmation field is parsed as the sequence number of service message 1, the sending end can determine that the confirmation response message indicates that the receiving end has successfully received service message 0. In this way, the sending end can use the specific values ​​of the retransmission control bit and the confirmation field to identify the service message that has been successfully received as fed back by the confirmation response message.

[0050] In some embodiments, S120 further includes: when a retransmission request message fed back by the receiving end is received, if a second retransmission control value and a 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.

[0051] Specifically, Figure 7 The header structure of the retransmission request message shown in Figure 6 The header structure of the confirmation response message is similar, but the retransmission control bit of the retransmission request message is the second retransmission control value, and the confirmation field of the confirmation response message is also modified to the lost message sequence number. The lost message sequence number refers to the sequence number corresponding to the abnormal service message received, such as Figure 3 As shown, the receiving end detects that the service message 4 is received abnormally, and then generates a retransmission request message NACK4. The sending end receives the retransmission request message NACK4, and parses the second retransmission control value and the lost sequence number from its extended header, so it can be determined that the service message corresponding to the lost sequence number has failed to be transmitted. In addition, the retransmission request message and the service message do not belong to the same channel, while the retransmission request message and the confirmation reply message can belong to the same channel, because the retransmission request message and the confirmation reply message do not need to carry a large amount of data information, so the two share a signaling channel, which can also meet the requirements of high-speed data transmission. In another embodiment, a separate channel can also be set for the retransmission request message so that the sending and receiving of various messages do not affect each other, further improving the efficiency of data transmission.

[0052] S130: If the receiving end fails to receive the service message, the corresponding target service message is searched according to the lost sequence number, and the target service message is used as a retransmission message.

[0053] Specifically, the target service message refers to a service message whose sequence number is consistent with the lost sequence number. After sending the service message, the sending end can cache the service message in a preset position and associate the service message with the sequence number. Then, when it is determined that the receiving end fails to receive the service message, because the lost sequence number is actually the sequence number of the service message that failed to be transmitted, the corresponding target service message can be directly found in the preset position according to the lost sequence number to obtain the retransmitted message. After determining that the receiving end successfully receives the service message, the service message whose sequence number is consistent with the confirmed sequence number in the preset position can be deleted to release the storage space of the preset position.

[0054] S140: Transmit the retransmitted message to the receiving end.

[0055] Specifically, Figure 3 As shown, after receiving the retransmission request message NACK4, the sending end parses it and generates a retransmission message 4 (a box filled with slashes). The retransmission message 4 is sent to the receiving end again. Although the retransmission message and the service message are transmitted on the same channel, the probability of data packet loss is still low, that is, the service message channel can carry the tasks of data retransmission and service message transmission at the same time.

[0056] In the technical solution of the present application, a service message is sent to a receiving end; an extended header of the service message carries a sequence number; based on the message type fed back 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 searched for 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; in this way, the extended header of the service message carries a sequence number, which can identify each IP message, and 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 of the device, and the sending end retransmits the corresponding data after receiving the retransmission request message, instead of retransmitting all messages after the message with transmission abnormality, 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 also 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 business message; setting the source address field of the business message to the first segment identifier, and setting the destination address field of the business message to the third segment identifier.

[0058] Specifically, the first segment identifier and the second segment identifier are two address identifiers of the sending end. By adding the address identifiers in the message, other ends can recognize that the message is sent by the sending end or received by the sending end. The third segment identifier and the fourth segment identifier are two address identifiers of the receiving end. By adding the address identifiers in the message, other ends can recognize that the message is received by the receiving end or sent by the receiving end. Specifically, the source address and the destination address are set in each message header, wherein the source address represents the address identifier of the source end of the message, and the destination address represents the address identifier of the destination end of the message; further, the service message and the retransmission message sent by the sending end use different address identifiers, that is, two information channels of service message and signaling message (retransmission message belongs to signaling message) are constructed, and a separate information channel can be reserved for the service message to reduce the interference of retransmission signaling on the service message. Figure 5 The service message header shown in the figure has the source address set to the first segment identifier issued by the sender, and the destination address set to the third segment identifier issued by the receiver. The message type can be determined by the specific segment identifiers in the source address and the destination address, as well as the sender address and the receiver address of the message. For example, the first segment identifier of the sender A is 2001:DB8:A::11, and the third segment identifier of the 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 sender (the unfilled box on the left) has a source address of 2001:DB8:A::11, a destination address of 2001:DB8:B::21, and a sequence number field of 4. The retransmission message 4 is Figure 3 The retransmitted message 4 (the box filled with diagonal lines on the left) sent by the sender, wherein the message structure of the retransmitted message 4 is the same as the structure of the business message 4, its source address is 2001:DB8:A::11, the destination address is 2001:DB8:B::21, and the sequence number field is the lost sequence number 4, which can be the same as the sequence number 4.

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

[0060] S210. Receive a service message sent by a transmitting end; an extension header of the service message carries a sequence number.

[0061] Specifically, as mentioned above, the extended header of the service message sent by the sender carries a sequence number, which is used to identify each service message. After receiving the service message, the receiver can confirm and respond to each service message according to subsequent steps, and can also determine whether there is a lost message.

[0062] S220. When a sequence number is obtained by parsing the received service message, a first retransmission control value and a confirmation sequence number of the confirmation response message are determined.

[0063] Specifically, the confirmation response message is the feedback from the receiving end on the successful reception of a certain service message, so that the sending end can determine that the service message has been successfully received. The first retransmission control value is used to indicate that the service message does not need to be retransmitted, and the confirmation sequence number refers to the identification sequence number generated by the receiving end according to the sequence number. Figure 6 As shown, the receiving end sets the retransmission control bit and the confirmation field in the extended header, sets the retransmission control bit to the first retransmission control value, and sets the confirmation field to the confirmation sequence number. Specifically, the confirmation sequence number can be obtained by performing a specified operation on the sequence number and the specified value, such as the sequence number is a, the specified value is b, and the specified operation is addition, that is, the confirmation sequence number c = a + b; it should be understood that the sending end knows in advance the rule of generating the confirmation sequence number by the receiving end, so after the sending end parses the confirmation response message to the IP layer to obtain the confirmation sequence number, it can restore the corresponding sequence number, so that the service message corresponding to the confirmation response message can be known.

[0064] In another embodiment, the confirmation sequence number is the sequence number of the next service message of the received service message. Figure 3 As shown, the receiving end sets the confirmation field to the sequence number of service message 1 in the confirmation response message 0 corresponding to the service message 0, and the sending end knows in advance that the confirmation field in the confirmation response message is the sequence number of the next service message. Then, 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 a confirmation response message; and when the confirmation field is parsed as the sequence number of service message 1, the sending end can determine that the confirmation response message indicates that the receiving end has successfully received service message 0. In this way, the sending end can use the specific values ​​of the retransmission control bit and the confirmation field to identify the service message that has been successfully received as fed back by the confirmation response message.

[0065] S230: Generate a confirmation response message according to the first retransmission control value and the confirmation sequence number, and send the confirmation response message to the sending end.

[0066] Specifically, the retransmission control bit in the confirmation response message is set to the first retransmission control value, and the confirmation field is set to the confirmation sequence number, so that the information that the service message corresponding to the confirmation sequence number does not need to be retransmitted is carried in the confirmation response message. Fig.10 As shown, the first retransmission control value may be 0, and the confirmation field may be the sequence number 3. Assuming that the preset confirmation field is the sequence number of the next service message of the successfully received service message, the confirmation response message is a feedback notifying the sender of the successful reception of service message 2. The confirmation response message and the service message do not belong to the same channel, and the confirmation response message belongs to the signaling channel.

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

[0068] Specifically, a continuity rule of the sequence number is set for the sending end in advance, and the continuity rule is sent to the receiving end, so that after parsing the service message, the receiving end can confirm whether each service message is successfully received according to the continuity rule. If the parsed sequence number does not meet the continuity, it means that there is a service message that failed to be received, so it is determined to send a retransmission request message to the sending end. After determining the service message that failed to be received, the value of the retransmission control bit in the retransmission request message can also be determined. This value is the second retransmission control value, which is used to represent that the service message needs to be retransmitted. In this way, when the sending end receives the retransmission request message, it can determine the abnormal reception of the service message corresponding to the lost sequence number according to the second retransmission control value.

[0069] In the technical solution of the present application, when a sequence number is obtained by parsing a received business message, a first retransmission control value and a confirmation sequence number of a confirmation response message corresponding to the business message are determined; a confirmation response message is generated according to the first retransmission control value and the confirmation sequence number; if the parsed sequence number does not meet the preset conditions, a second retransmission control value is determined, and a lost sequence number is determined according to the sequence number; a retransmission request message is determined according to 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 the IP layer of the business message, and determine the packet loss data according to the change rule 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 of the device, and specify the data requested for retransmission to the sending end, without the need for the sending end to go back n steps for retransmission, 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, whether to send a retransmission request message to the sending end is determined according to whether the sequence number meets the continuity, including S2410 to S2430, and the specific process is as follows.

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

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

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

[0074] Specifically, the sequence number field of the extended header of the retransmission request message is set to the lost sequence number; the retransmission control bit of the extended header of the retransmission request message is set to the second retransmission control value. Assuming that 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 get the following: Fig.11 The header of the retransmission request message is shown.

[0075] S2430. Send a retransmission request message to the sending end.

[0076] Specifically, Figure 3 As shown, the receiving end sends the retransmission request message NACK4 to the sending end. The retransmission request message and the service message do not belong to the same channel. Both the retransmission request message and the confirmation message can be transmitted through the signaling channel, so that the service message sent by the sending end and the signaling message sent by the receiving end do not affect each other, further improving the efficiency of data transmission.

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

[0078] Exemplarily, the preset condition is that the difference between adjacent sequence numbers is 1, and the starting value of the sequence number is 0. Then, 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 sequence number queues 0, 1, 2, 3, 5 and 6, where the difference between adjacent sequence numbers 3 and 5 is 2, and the difference between other adjacent sequence numbers meets the specified value 1, and the candidate group is determined to be (3,5). The difference of this candidate group is 2, that is, a service message 4 failed to be accepted, and the lost sequence number is finally determined to be 4.

[0079] In some embodiments, the method also 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 confirmation response messages and retransmission request messages; when generating a confirmation response message, the source address field of the confirmation response message is set to the fourth segment identifier, and the destination address field of the confirmation response message is set to the second segment identifier; when generating a 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.

[0080] Specifically, the second segment identifier is the address identifier published by the sender. By adding the address identifier in the message, other terminals can recognize that the message is sent by the sender or received by the sender. The fourth segment identifier is the address identifier published by the receiver. By adding the address identifier in the message, other terminals can recognize that the message is received by the receiver or sent by the receiver. Specifically, the source address and destination address are set in each message header, where the source address represents the address identifier of the source end of the message, and the destination address represents the address identifier of the destination end of the message. Assume that the second segment identifier of the sender A is 2001:DB8:A::12, and the fourth segment identifier of the receiver B is 2001:DB8:B::22. Fig.10 The figure shows the header of confirmation response message 2 sent by the receiving end, wherein the source address of confirmation response 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 of service message 2. Fig.11 It is the header of the retransmission request message 4 sent by the receiving end, wherein 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 electronic equipment of this application is introduced below, such as Fig.12 As shown, the present 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 by any embodiment of the present application.

[0082] Specifically, the data transmission method based on the IP layer provided by the present application is stored in the memory 1220 of the electronic device, and the data transmission method based on the IP layer is executed by the processor 1210, so that the sending end sends a service message to the receiving end, and the extension 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 the sequence number can be used to distinguish each service message; if the receiving end successfully receives the service message, a confirmation response message is generated, and the confirmation response message carries a first retransmission control value and a confirmation sequence number, wherein the confirmation field in the confirmation response message is set to the confirmation sequence number, which can be distinguished from the sequence number in the service message. The sending end can obtain the first retransmission control value and the confirmation sequence number by parsing the confirmation response message to the IP layer, so that it can be determined that the receiving end has successfully received the service message. If the receiving end fails to receive the service message, a retransmission request message is generated and fed back to the sending end; the sending end parses the retransmission request message to the IP layer to obtain the second retransmission control value and the lost sequence number, and then determines the retransmission message according to the lost sequence number; finally, the retransmission message is transmitted to the receiving end; in this way, the service message that the sending end fails to transmit can be identified by the receiving end through the sequence number, and then a retransmission request message is sent accordingly, instead of retransmitting the service message that fails to transmit, which can reduce network congestion when retransmitting data and improve network transmission efficiency. Moreover, the message only needs to be parsed to the shallow layer instead of the deep layer, which can reduce the requirements for equipment performance and reduce the time spent on packet loss detection.

[0083] It should be known that the specific implementation content of the electronic device in the present application has been explained in detail in the corresponding method embodiment and will not be repeated here.

[0084] Fig.13 The structure block diagram of a computer system for implementing an electronic device according to an embodiment of the present application is schematically shown.

[0085] It should be noted that Fig.13 The computer system 1300 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0086] like Fig.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 according to the program stored in the read-only memory 1302 (Read-Only Memory, ROM) or the program loaded from the storage part 1308 to the random access memory 1303 (Random Access Memory, RAM). In the random access memory 1303, various programs and data required for system operation are also stored. The processor 1301, the read-only memory 1302 and the random access memory 1303 are connected to each other through a bus 1304. The input / output interface 1305 (Input / Output interface, i.e., 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, a mouse, etc.; an output section 1307 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1308 including a hard disk, etc.; and a communication section 1309 including a network interface card such as a LAN card, a 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. A removable medium 1311, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1310 as needed so that a computer program read therefrom is installed into the storage section 1308 as needed.

[0088] In particular, according to an embodiment of the present application, the process described in each method flow chart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer readable medium, and the computer program contains a program code for executing the method shown in the flow chart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 1309, and / or installed from the removable medium 1311. When the computer program is executed by the processor 1301, various functions defined in the system of the present application are executed.

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

[0090] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the above-mentioned module, program segment or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0091] It should be noted that, although several modules or units of the equipment for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiments of the present application, the features and functions of two or more modules or units described above can be embodied in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into being embodied by multiple modules or units.

[0092] Through the description of the above implementation methods, it is easy for those skilled in the art to understand that the example implementation methods described here can be implemented by software, or by software combined with necessary hardware. Therefore, the technical solution according to the implementation method of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, including several instructions to enable a computing device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the implementation method according to the present application.

[0093] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary technical means in the art that are not disclosed in the present application.

[0094] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A method for data transmission based on IP layer, characterized in that: Applied to the sending end, the method includes: Sending a service message to a receiving end; the extended header of the service message carries a sequence number; Determining whether the receiving end successfully receives the service message according to the message type fed back by the receiving end; If the receiving end fails to receive the service message, searching for the corresponding target service message according to the lost sequence number, and using the target service message 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.

2. The method for data transmission based on the IP layer according to claim 1, characterized in that: The determining, according to the message type fed back by the receiving end, whether the receiving end successfully receives the service message includes: When a confirmation response message is received from the receiving end, if the first retransmission control value and the confirmation sequence number are parsed from the extended header of the confirmation response message, it is determined that the service message corresponding to the confirmation 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 confirmation sequence number is an identification number generated by the receiving end based on the sequence number.

3. The method for data transmission based on IP layer as claimed in claim 1, characterized in that: The determining, according to the message type fed back by the receiving end, whether the receiving end successfully receives the service message includes: When a retransmission request message fed back by the receiving end is received, if a second retransmission control value and a 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 represent that the service message needs to be retransmitted.

4. The method for data transmission based on IP layer as claimed in claim 1, characterized in that: The method further comprises: Acquire 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; The source address field of the service message is set to the first segment identifier, and the destination address field of the service message is set to the third segment identifier.

5. A method for data transmission based on IP layer, characterized in that: Applied to the receiving end, the method includes: Receive a service message sent by a sending end; the extension header of the service message carries a sequence number; Determine, according to the sequence number parsed from the service message, a first retransmission control value and a confirmation sequence number of the confirmation response message; the first retransmission control value is used to represent that the service message does not need to be retransmitted, and the confirmation sequence number is an identification number generated by the receiving end according to the sequence number; generate a confirmation response message according to the first retransmission control value and the confirmation sequence number, and send the confirmation response message to the sending end; Whether to send a retransmission request message to the sending end is determined according to whether the sequence number meets the continuity.

6. The method for data transmission based on the IP layer as claimed in claim 5, characterized in that: The determining whether to send a retransmission request message to the transmitting end according to whether the sequence number meets the continuity includes: When the sequence number does not meet the continuity, determine the second retransmission control value and the lost sequence number of 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 the retransmission request message according to the lost sequence number and the second retransmission control value; The retransmission request message is sent to the sending end.

7. The method for data transmission based on IP layer as claimed in claim 6, characterized in that: The generating the retransmission request message according to the lost sequence number and the second retransmission control value includes: Setting the sequence number field of the extended header of the retransmission request message to the lost sequence number; The retransmission control bit of the extended header of the retransmission request message is set to the second retransmission control value.

8. The method for data transmission based on IP layer as claimed in claim 5, characterized in that: The method further comprises: Acquire 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 the confirmation response message and the retransmission request message; When generating the confirmation response message, setting the source address field of the confirmation response message to the fourth segment identifier, and setting the destination address field of the confirmation response message to the second segment identifier; 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.

9. A computer readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method for data transmission based on the IP layer as described in any one of claims 1 to 8 is implemented.

10. An electronic device, characterized in that: include: processor; A memory, configured to store executable instructions of the processor; The processor executes the executable instructions to enable the electronic device to implement the method for data transmission based on the IP layer as described in any one of claims 1 to 8.

Images