Method, device and medium for reliable transmission based on piggybacked acknowledgement in half duplex link

Abstract

This invention discloses a reliable transmission method, device, and medium based on piggyback acknowledgment in a half-duplex link, relating to the field of communication technology. The method includes: in response to receiving a payload, constructing a link-layer frame, the link-layer frame containing a transmission sequence number and a reception acknowledgment number; sending the link-layer frame to the half-duplex physical link and initiating an acknowledgment waiting timer; if a frame returned by the peer is received before the timeout, extracting the reception acknowledgment number carried in the returned frame; if the reception acknowledgment number is equal to the transmission sequence number of the most recently transmitted link-layer frame, then confirming correct reception and advancing the transmission sequence number; if they are not equal, maintaining the transmission sequence number and retransmitting; if no frame is received from the peer after the timeout, maintaining the transmission sequence number and retransmitting. This invention enables reliable transmission of airborne message signals on a half-duplex link.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a reliable transmission method, device and medium based on piggyback acknowledgment in a half-duplex link. Background Technology

[0002] In airborne equipment such as UAVs and parachute controllers, two communication links typically need to be maintained simultaneously: one is a wired full-duplex serial link connected to the flight control computer, and the other is a wireless infrared link to the ground control station. The airborne messaging protocol is designed for a full-duplex serial link, allowing either end to initiate a message at any time. Message frames have built-in checksums, but the link itself does not provide retransmission or acknowledgment mechanisms. However, the wireless infrared link exhibits typical half-duplex characteristics, allowing transmission in only one direction at a time. If both ends initiate transmissions simultaneously, a collision will occur, resulting in data corruption on both sides. Furthermore, the infrared channel is susceptible to interference from distance, attitude, and ambient light, resulting in a significantly higher bit error rate than the wired serial port.

[0003] Currently, there are two main approaches to applying the aforementioned message protocol to infrared links: one is to directly transmit the message protocol byte stream through the infrared serial port without any acknowledgment or retransmission mechanism; in this case, the message is lost immediately upon encountering an error. The other approach is to add an independent explicit acknowledgment frame to each message, with the acknowledgment frame and data frame being transmitted alternately on the same half-duplex link. However, in error-prone environments, both approaches have low command interaction success rates. The independent acknowledgment frame scheme also significantly reduces effective bandwidth utilization due to the doubling of the frame count, and neither approach resolves the conflict issue caused by simultaneous transmission from both ends. Summary of the Invention

[0004] This invention provides a reliable transmission method, device, and medium based on piggyback acknowledgment in a half-duplex link. The technical problem it aims to solve is: how to carry a message protocol designed according to the full-duplex assumption on a half-duplex infrared link and achieve reliable command interaction.

[0005] In a first aspect, the present invention provides a reliable transmission method based on piggyback acknowledgment in a half-duplex link, comprising: In response to receiving a payload, a link layer frame is constructed, which contains a transmission sequence number and a reception acknowledgment number. The transmission sequence number is the sequence number of this frame, and the reception acknowledgment number is the sequence number of the most recently transmitted frame from the peer that has been correctly received by this end. The link layer frame is sent to the half-duplex physical link, and an acknowledgment waiting timer is started; When a frame is received from the peer before the response waiting timer expires, the reception acknowledgment number carried in the frame returned by the peer is extracted from the frame returned by the peer. If the reception acknowledgment number carried in the frame returned by the peer is equal to the transmission sequence number of the link layer frame most recently sent by this end, then it is confirmed that the link layer frame most recently sent by this end has been correctly received, and the transmission sequence number maintained by this end is advanced to the next sequence number value. If the sequence number of the received acknowledgment carried in the frame returned by the peer is not equal to the sequence number of the link layer frame most recently sent by this end, then the sequence number of this end is kept unchanged and the link layer frame most recently sent by this end is retransmitted. If no frame is received from the peer after the response waiting timeout, the local end maintains its transmission sequence number and retransmits the link layer frame most recently transmitted by the local end.

[0006] Optionally, the link layer frame includes a frame header, which includes a first frame header byte and a second frame header byte; constructing the link layer frame includes: Set the first frame header byte to the first preset value; The preset bit field of the second frame header byte is set to a second preset value. The second frame header byte is provided with a first bit field and a second bit field. The first bit field is used to carry the transmission sequence number, and the second bit field is used to carry the reception acknowledgment number. The first frame header byte and the second frame header byte are arranged sequentially to form the frame header.

[0007] Optionally, maintaining the local transmission sequence number unchanged and retransmitting the most recently transmitted link layer frame includes: Get the current retransmission count of the link layer frame most recently sent by this end; If the current retransmission count has not reached the preset retransmission limit, the current retransmission count will be incremented by one, and the link layer frame most recently sent by this end will be retransmitted. If the current retransmission count has reached the preset retransmission limit, the most recently transmitted link layer frame from this end is discarded, the transmission sequence number of the peer end is reset to the preset unknown state initial value, and the transmission process of the next frame begins.

[0008] Optionally, the method further includes: The system receives the raw byte stream from the half-duplex physical link, maintains the frame synchronization state, performs a frame synchronization scan on the raw byte stream, and takes the candidate frames that have passed frame synchronization as the frames to be verified. Perform a length validity check on the frame to be checked, and take the frame to be checked that passes the length validity check as a length valid frame; Perform a check field check on the length of the valid frame, and take the length valid frame that passes the check field check as a valid frame; Extract the transmission sequence number of the legal frame from the legal frame, and obtain the locally maintained peer transmission sequence number; If the sequence number of the valid frame is inconsistent with the sequence number of the peer, the payload data in the valid frame is submitted to the upper layer as new frame data, and the sequence number of the peer is updated to the sequence number of the valid frame. If the sequence number of the valid frame is the same as the sequence number of the peer, the payload data in the valid frame is discarded.

[0009] Optionally, the step of performing frame synchronization scanning on the original byte stream includes: Read the first byte from the current scan position of the original byte stream; If the first byte is not the first preset value, then the scan position is shifted one byte to the right, and the step of reading the first byte from the current scan position of the original byte stream is re-executed; If the first byte is the first preset value, then read the next byte; If the preset bit segment of the next byte is not the second preset value, then the scan position is moved to the byte after the first byte, and the step of reading the first byte from the current scan position of the original byte stream is re-executed; If the preset bit segment of the next byte is the second preset value, then the first byte and the next byte are used as frame header candidates, and the length field is read starting. The length validity check of the frame to be checked includes: Read the value of the length field immediately following the frame header in the frame to be verified; If the value of the length field is greater than the preset maximum payload length, the frame to be verified is determined to be an illegal frame, the frame synchronization state is reset, the scanning position is moved to the byte after the frame header candidate, and the step of reading the first byte from the current scanning position of the original byte stream is re-executed. If the value of the length field is less than or equal to the preset maximum load length, then the load data and verification data are read according to the value of the length field, and the verification data is verified by the verification field.

[0010] Optionally, the step of determining the timeout threshold for the response waiting time includes: Obtain the baud rate of the half-duplex physical link, and calculate the effective byte rate based on the baud rate; Obtain the maximum frame length of the link layer frame, wherein the maximum frame length is equal to the sum of the preset maximum payload length and the frame fixed overhead; Obtain the preset link processing margin; The timeout threshold is calculated by dividing the sum of the maximum frame length and the preset link processing margin by the effective byte rate, and then adding the preset fixed margin.

[0011] Optionally, all service transmission requests write the data to be sent to the transmission queue in a non-blocking manner, and the method further includes: Determine whether the remaining capacity of the sending queue is sufficient to accommodate the data to be sent; If the remaining capacity of the sending queue is insufficient to accommodate the data to be sent, then the data to be sent is discarded. If the remaining capacity of the sending queue is sufficient to accommodate the data to be sent, then the data to be sent is written into the sending queue; In this context, the local end acts as the sole consumer of the sending queue, retrieves data from the sending queue, constructs the link layer frame, and sends it.

[0012] Optionally, one end (local or remote) is designated as the polling master, and the other end as the polling slave. The polling master sends the link layer frame when there is data to send and sends an empty frame when there is no data to send. The polling slave only sends a data frame or an empty frame as a response after receiving a frame sent by the polling master.

[0013] Secondly, the present invention also provides a computer device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0014] Thirdly, the present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the above-described method.

[0015] This invention provides a reliable transmission method, device, and medium based on piggyback acknowledgment in a half-duplex link. By constructing a link-layer frame containing a transmission sequence number and a reception acknowledgment sequence number, the combined transmission of data frames and acknowledgment information is achieved on the half-duplex physical link. Furthermore, the reception acknowledgment sequence number is filled in by the local end based on the sequence number of the most recently transmitted frame from the peer that has been correctly received. This ensures that the returned data frame carries the acknowledgment information while transmitting the payload, eliminating the need for separate link transmission time for the acknowledgment frame and reducing bandwidth loss caused by the alternating transmission of acknowledgment frames and data frames in the half-duplex channel. The sending end determines whether the frame has been correctly received by comparing the reception acknowledgment sequence number in the peer's returned frame with the transmission sequence number of the most recently transmitted frame. If they match, the sending end advances its transmission sequence number to prepare for sending the next frame; if they do not match, the sequence number remains unchanged and retransmission is performed. This achieves automatic recovery of lost or damaged frames while ensuring the orderly transmission of frames. Retransmission is also triggered when no return frame is received after the acknowledgment waiting timeout, further covering scenarios where frames are completely lost due to channel interference. The sequence number deduplication mechanism enables the receiver to distinguish between new frames and retransmitted frames, avoiding duplicate deliveries to the upper layer. Based on these features, when carrying a message protocol designed according to the full-duplex assumption on a half-duplex infrared link, each payload sent from the upper layer is encapsulated as a link-layer frame carrying a transmission sequence number. The acknowledgment status is obtained through the receive acknowledgment sequence number in the frame returned by the peer, allowing the determination of the single-frame transmission result to be completed without the involvement of the upper-layer protocol. The timeout retransmission mechanism automatically resumes transmission when frame loss or corruption is caused by channel interference, so that the upper layer does not need to be aware of the link-layer transmission failure and retry process, presenting reliable transmission services to the upper layer with the same interface as the full-duplex link. Thus, this scheme enables a message protocol designed according to the full-duplex assumption, which was originally only applicable to full-duplex links, to achieve reliable transmission on half-duplex links with high bit error rates, solving the problem of command interaction failure due to packet loss on such links, and enabling command interaction to automatically recover after failure. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a reliable transmission method based on piggyback acknowledgment in a half-duplex link, provided by an embodiment of the present invention; Figure 2 A schematic block diagram of a computer device provided for an embodiment of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0020] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0021] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0022] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [the described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [the described condition or event] is detected," or "in response to detection of [the described condition or event]."

[0023] In airborne equipment such as UAVs and parachute controllers, two communication links typically need to be maintained simultaneously: one is a wired full-duplex serial link connected to the flight control computer, and the other is a wireless infrared link to the ground control station. The infrared link uses the IrDA infrared communication protocol, utilizing infrared light for short-range wireless transmission, exhibiting typical half-duplex characteristics: transmission is allowed in only one direction at a time; simultaneous transmission from both ends will result in collisions and data corruption. However, the airborne message protocol was originally designed for a full-duplex serial link, allowing either end to initiate messages at any time. While message frames have built-in checksums, the link itself does not provide acknowledgment or retransmission mechanisms. Therefore, directly applying this protocol to a half-duplex infrared link will render command interaction unreliable due to the lack of reliable transmission guarantees. For further information, please refer to [link to relevant documentation]. Figure 1This invention provides a reliable transmission method based on piggyback acknowledgment in a half-duplex link. By constructing a link-layer frame containing a transmission sequence number and a reception acknowledgment number, the data frame itself also serves as an acknowledgment frame, achieving implicit acknowledgment and reliable retransmission on the half-duplex physical link. Simultaneously, a response waiting timer mechanism is employed to avoid simultaneous transmission conflicts at both ends and resolve reliable transmission issues in high bit error rate channels. Specifically, the method includes the following steps: S1, in response to receiving a payload, construct a link layer frame, the link layer frame containing a transmission sequence number and a reception acknowledgment number, the transmission sequence number being the sequence number of the current frame, and the reception acknowledgment number being the sequence number of the most recently transmitted frame from the peer that has been correctly received by this end.

[0024] In practice, in response to receiving a payload, a link-layer frame is constructed. The payload generated by the upper-layer message protocol is passed to the link-layer processing module in the form of a byte stream. When the link-layer processing module receives the payload from the upper-layer message protocol, it encapsulates it into a link-layer frame. The payload refers to the byte stream of data to be sent generated by the upper-layer message protocol. In communication scenarios between airborne equipment and ground control stations, the payload can be parameter configuration instructions, status query requests, or firmware upgrade timing negotiation messages, such as command frames of the MAVLink (Micro Aircraft Link) protocol. MAVLink is a lightweight messaging protocol widely used in communication between UAVs and ground stations. Its message frames contain a message ID, payload, and checksum field, and the message length is variable. The payload generated by the upper-layer protocol is passed to the link-layer processing module in the form of a byte stream, and the link layer is responsible for framing and transmission.

[0025] Furthermore, the link layer frame includes a transmission sequence number and a reception acknowledgment number. The transmission sequence number is the sequence number of the current frame, and the reception acknowledgment number is the sequence number of the most recently transmitted frame from the peer that has been correctly received. The transmission sequence number uses a 2-bit cyclic numbering method, using 0, 1, 2, 3 in a cyclical manner. The 2-bit cyclic sequence number is unambiguous under stop-and-wait transmission. Stop-and-wait transmission refers to a transmission method where the sending end must wait for acknowledgment from the peer after sending a frame before sending the next frame. In this method, only one frame is in the transmission and acknowledgment waiting state at any given time. Since the sending end will not send a new frame before receiving an acknowledgment, when the peer receives a retransmitted frame, there are only two possibilities: the sequence number of the frame is the same as the sequence number of the most recently received frame, indicating that the frame is a retransmitted frame; or the sequence number of the frame is the next value after the sequence number of the most recently received frame, indicating that the frame is a new frame. Therefore, the 2-bit cyclic sequence number is sufficient to distinguish the current frame from the previously sent frame, and sequence number confusion will not occur. The sequence number function required for reliable transmission is achieved with an overhead of 2 bits.

[0026] Furthermore, the method for filling in the receive acknowledgment number is as follows: obtain the sequence number of the most recently correctly received frame sent by the peer from the locally maintained peer-end sequence number record, and fill this sequence number into the receive acknowledgment number field. If no frame has been received from the peer, i.e., the peer-end sequence number record is in an initial unknown state, the receive acknowledgment number can be set to a preset unknown state initial value, which is 0xFF in one specific implementation. The link layer frame also includes a frame header, a length field, a payload field, and a check field. The frame header is located at the beginning of the frame and is used for frame synchronization identification and control information extraction at the receiving end. The length field is located after the frame header and is used to indicate the number of bytes in the payload field. The payload is filled into the payload field. The check field is located at the end of the frame and is used by the receiving end for integrity verification. The setting of the receive acknowledgment number field allows each data frame to piggyback feedback on the receiving status to the peer while transmitting the payload, without needing to send an additional frame for acknowledgment information.

[0027] In terms of frame header design, this embodiment adopts a two-byte frame header structure, namely the first frame header byte and the second frame header byte, which are arranged sequentially at the beginning of the frame. When the receiving end performs frame synchronization scanning, it first checks the first frame header byte, and then checks the second frame header byte. Only when both bytes meet the preset conditions is the frame header considered to have been found. The frame header is a field in the link layer frame used for frame synchronization and carrying control information. Its design directly affects the accuracy and efficiency of the receiving end in identifying frame boundaries from the raw byte stream. If the frame header design is too simple, such as using only a single byte as the frame header, the receiving end may misjudge it as the frame header when the payload data in the raw byte stream happens to have the same value as that byte, leading to frame synchronization errors. If a complex frame header design is adopted, although the identification accuracy can be improved, it will increase frame overhead and reduce transmission efficiency. Therefore, this embodiment reduces the probability of missynchronization by combining two bytes, and at the same time carries the transmission sequence number and the reception acknowledgment number in different bit segments of the second frame header byte without adding additional frame overhead.

[0028] In specific implementations, when constructing the frame header, the first frame header byte is set to a first preset value. The first preset value is a fixed byte value pre-agreed upon by both communicating parties, used as the first-level identifier of the frame header. For example, in one specific implementation, the first preset value is 0x55. The binary representation of 0x55 is 01010101. The bits of this byte change alternately, exhibiting good edge-jumping characteristics, which is beneficial for the serial receiver at the receiving end to perform clock synchronization and bit sampling. When the receiving end detects 0x55 in the original byte stream, it indicates that the current byte may be the first byte of the frame header, and the receiving end will read subsequent bytes for further verification.

[0029] Furthermore, the preset bit field of the second frame header byte is set to a second preset value. The second preset value is another fixed value pre-agreed upon by both communicating parties, used as a second-level identifier in the frame header. The preset bit field of the second frame header byte refers to the fixed bit field in the second frame header byte used to carry the frame synchronization identifier. For example, in one specific implementation, the second preset value is 0xA, i.e., binary 1010, and the high 4 bits of the second frame header byte are used as the preset bit field. When the first frame header byte is 0x55 and the high 4 bits of the second frame header byte are 0xA, the first two bytes of the frame header combine to form 0x55Ax, where A represents any combination of the lower 4 bits where the high 4 bits are 0xA. This two-level frame header design gives the frame header a fixed high-bit characteristic, while the lower 4 bits can be used to carry other control information, ensuring both the identifiability of the frame header and utilizing all bits. The probability of the payload containing the same combination as the frame header is 1 / 65536, far lower than the 1 / 256 of a single-byte frame header, significantly reducing the probability of missynchronization.

[0030] In specific implementations, the second frame header byte includes a first bit field and a second bit field. The first bit field carries the transmission sequence number, and the second bit field carries the reception acknowledgment number. The first and second bit fields are the remaining bits in the second frame header byte excluding the preset bit field. For example, in one implementation, bits 3-2 of the second frame header byte are used as the first bit field, and bits 1-0 as the second bit field. Since both the transmission sequence number and the reception acknowledgment number only require 2 bits to represent a cyclic sequence number from 0 to 3, placing them in bits 3-2 and bits 1-0 of the second frame header byte respectively fully utilizes all 8 bits of the second frame header byte. Furthermore, the high 4 bits of the second frame header byte are fixed at 0xA for frame synchronization identification, and the low 4 bits (bits 3-2) carry the transmission sequence number, while bits 1-0 carry the reception acknowledgment number. This bit allocation method does not increase the additional frame length, maintaining the compactness of the frame structure.

[0031] Furthermore, after the frame header is constructed, the length field, payload field, and check field follow to form a complete link layer frame.

[0032] This embodiment employs a frame header structure composed of a first frame header byte and a second frame header byte, giving the frame header a stronger unique characteristic. The dual conditional judgment of the first and second preset values ​​reduces the probability of the receiver misidentifying accidentally occurring identical byte combinations in the payload data as frame headers, thus improving the reliability of frame synchronization. Simultaneously, by carrying the transmission sequence number and the reception acknowledgment sequence number in different bit segments of the second frame header byte, sequence information is carried without increasing the frame length, enabling the link layer frame to maintain a compact structure while possessing the ability to piggyback acknowledgments. The frame header structure of this invention does not rely on specific escape characters or length encoding methods, eliminating the need for byte escaping processing of the payload data and avoiding the processing overhead and effective bandwidth loss caused by escaping operations.

[0033] S2, send the link layer frame to the half-duplex physical link and start the response waiting timer.

[0034] In practice, once the link layer frame is constructed, it is sent to the half-duplex physical link, and an acknowledgment waiting timer is started. A half-duplex physical link is a physical communication medium that allows data transmission in only one direction at a time, such as the infrared serial port link in this embodiment. During transmission, the byte stream of the link layer frame is written to the physical link via a serial port or infrared encoder. The moment of transmission completion is the start time of the acknowledgment waiting timer; the two are strictly aligned to ensure that the timeout period accurately covers the entire time elapsed from the completion of frame transmission to receiving the response from the other end. The acknowledgment waiting timer maintains a timeout period, with its count value incrementing from zero. When the count value reaches a preset timeout threshold, a timeout event is triggered.

[0035] S3, when a frame is received from the peer before the response waiting timer expires, the reception acknowledgment number carried in the frame is extracted from the frame returned by the peer.

[0036] In practice, if a frame is received from the peer before the acknowledgment waiting timer expires, the acknowledgment number carried in that frame is extracted. The frame returned by the peer refers to the frame sent back after receiving the previously sent link-layer frame. This frame has the same format as the sent link-layer frame, including the acknowledgment number filled in by the peer. This acknowledgment number reflects the sequence number of the most recently sent frame that the peer has correctly received: after receiving the sent frame, the peer extracts the sequence number of that frame and fills it into the acknowledgment number field of the returned frame, thus feeding back the reception status. The acknowledgment number is parsed from the received frame and compared with the sequence number of the most recently sent frame.

[0037] S4. If the reception acknowledgment number carried in the frame returned by the peer is equal to the transmission sequence number of the link layer frame most recently sent by this end, then it is confirmed that the link layer frame most recently sent by this end has been correctly received, and the transmission sequence number maintained by this end is advanced to the next sequence number value.

[0038] In practice, when the received acknowledgment number equals the sent sequence number of the most recently sent frame, it indicates that the other end has correctly received the sent frame, and the other end has fed back this reception status through the received acknowledgment number field in its return frame. At this point, the acknowledgment of the frame is complete, the transmission process of the frame ends, and no retransmission is needed. Further, the sent sequence number is advanced to the next sequence number value for use in the transmission of subsequent new frames. Since the sent sequence number uses a 2-digit cyclic numbering method, the advancement method is to add 1 to the current sequence number value and then take the modulo 4, i.e., 0→1→2→3→0. After the sequence number is advanced, the recorded current sent sequence number becomes the new value, and this new value will be used as the sent sequence number when sending new frames.

[0039] S5, if the reception acknowledgment number carried in the frame returned by the peer is not equal to the transmission sequence number of the link layer frame most recently sent by this end, then the transmission sequence number of this end remains unchanged and the link layer frame most recently sent by this end is retransmitted.

[0040] In practice, when the received acknowledgment number is not equal to the transmission sequence number of the most recently transmitted frame, it indicates that the acknowledgment information piggybacked in the frame returned by the other end is not an acknowledgment for the most recently transmitted frame. Possible reasons include: the other end has not yet received the frame; the frame received by the other end was deemed corrupted and discarded during verification; or the frame returned by the other end is an earlier response but arrived late. In this case, the transmission sequence number cannot be advanced because the most recently transmitted frame has not yet been acknowledged, and advancing the sequence number would result in the frame being permanently lost. It is necessary to maintain the current sequence number and retransmit the frame. The retransmitted frame must be identical in content to the first transmitted frame, including the same transmission sequence number and the same payload.

[0041] S6. If no frame is received from the other end after the response waiting timeout, the local end maintains the same transmission sequence number and retransmits the link layer frame most recently transmitted by the local end.

[0042] In practice, if no frame is received from the peer after the acknowledgment waiting timer expires, the sequence number remains unchanged and the most recently transmitted link layer frame is retransmitted. Acknowledgment waiting timer expires when the count reaches a preset timeout threshold, but no return frame is received from the peer. This indicates that the most recently transmitted frame may have been lost on the half-duplex physical link, including when the frame was corrupted by noise during transmission, when the peer did not receive it correctly, or when the peer received the frame but the return frame was lost during transmission. In either case, acknowledgment of the frame cannot be obtained, and the frame needs to be retransmitted. During retransmission, the sequence number remains unchanged to ensure that the peer can identify the frame as a retransmitted frame rather than a new frame. When the peer receives the retransmitted frame, it compares the sequence number with the locally recorded sequence number of the peer. If they are the same, it is determined to be a duplicate frame and will not be repeatedly delivered to the upper layer.

[0043] This embodiment constructs a link-layer frame containing both a transmission sequence number and a reception acknowledgment number, allowing the data frame itself to function as an acknowledgment frame, eliminating the need to send a separate acknowledgment frame for each data frame. On a half-duplex link, the transmission of a separate acknowledgment frame would occupy the same one-way transmission time as the data frame. In the simple stop-and-wait acknowledgment scheme, an acknowledgment frame needs to be sent for each data frame, doubling the number of frames and resulting in low effective bandwidth utilization. This embodiment utilizes the return data frame to piggyback the reception acknowledgment number, ensuring that the transmission of acknowledgment information does not consume additional link bandwidth, approximately doubling the effective bandwidth utilization compared to the simple stop-and-wait scheme. The 2-bit cyclic transmission sequence number achieves reliable sequence number management with minimal storage overhead; both the sending and receiving ends only need to maintain two 2-bit sequence number variables to distinguish between new and retransmitted frames. The acknowledgment waiting timer mechanism enables the sending end to promptly detect frame loss and trigger retransmission, significantly improving the success rate of command interaction in a half-duplex high bit error rate channel environment. The sending sequence number and receiving acknowledgment number are carried in the link layer frame, do not depend on the support of upper layer message protocols, have good protocol independence, and can be used to carry a variety of full-duplex message protocols.

[0044] In some preferred embodiments, maintaining the local end's transmission sequence number unchanged and retransmitting the most recently transmitted link layer frame includes: obtaining the current retransmission count of the most recently transmitted link layer frame; if the current retransmission count has not reached a preset retransmission upper limit, incrementing the current retransmission count by one count and retransmitting the most recently transmitted link layer frame; if the current retransmission count has reached the preset retransmission upper limit, discarding the most recently transmitted link layer frame, resetting the peer's transmission sequence number to a preset unknown initial value, and proceeding to the transmission process of the next frame.

[0045] In practical implementation, in half-duplex infrared links, the bit error rate is significantly higher than that of wired serial ports due to the channel's susceptibility to interference from distance, attitude, and ambient light, resulting in a higher probability of single transmission failure. If the number of retransmissions is not limited, the sending end may fall into infinite retransmissions when the link remains unavailable, consuming system resources and blocking the transmission of subsequent frames. Furthermore, if the retransmission is abandoned directly after reaching the upper limit without any state recovery, it may lead to a mismatch in sequence numbers between the sending and receiving ends, making subsequent frames unrecognizable. Therefore, this embodiment sets a preset retransmission upper limit. When the retransmission count reaches the limit, the current frame is abandoned, and the sequence number transmitted by the receiving end is reset to a preset unknown initial value, achieving limited control over the retransmission process and automatic recovery from sequence number mismatch.

[0046] In specific implementation, in the step of maintaining the sequence number and retransmitting the most recently transmitted link layer frame, the current retransmission count of the most recently transmitted link layer frame is first obtained. The current retransmission count refers to the number of times the frame has been retransmitted since its first transmission, and is a non-negative integer counting from zero. Each link layer frame is initialized to a retransmission count of 0 upon its first transmission. Further, each time the frame is retransmitted due to timeout without acknowledgment, the retransmission count is incremented by 1. Before each retransmission attempt, the current retransmission count of the frame is first obtained and compared with a preset retransmission upper limit. The storage location of the current retransmission count can be associated with the frame's sequence number or frame identifier to distinguish the retransmission counts of different frames.

[0047] Furthermore, if the current retransmission count has not reached the preset retransmission limit, the current retransmission count is incremented by one, and the most recently transmitted link layer frame is retransmitted. The preset retransmission limit is a pre-set maximum allowed retransmission count, used to limit the total number of retransmission attempts for a single frame. For example, the preset retransmission limit is 3 times. If the current retransmission count is less than the preset retransmission limit, it means that the frame still has a chance to be retransmitted, and further attempts are allowed. After incrementing the retransmission count by 1, the same link layer frame is sent to the half-duplex physical link again, and the acknowledgment waiting timer is restarted. The sequence number remains unchanged during retransmission because the frame has not yet been acknowledged by the peer, and the sequence number cannot be advanced. If the sequence number is changed during retransmission, the peer will not be able to associate the retransmitted frame with the first transmitted frame, which may result in the same data being repeatedly delivered to the upper layer. The retransmitted frame is completely identical in content to the first transmitted frame, including the same sequence number, the same acknowledgment number, and the same payload data.

[0048] Furthermore, if the current retransmission count has reached the preset retransmission limit, the most recently transmitted link layer frame is abandoned, the peer's sequence number is reset to a preset unknown state initial value, and the transmission process for the next frame begins. When the current retransmission count has reached the preset retransmission limit, it means that the frame has undergone the maximum allowed number of retransmission attempts, but none have been acknowledged. At this point, the frame is no longer retransmitted, but abandoned. Abandonment means that the frame will no longer be sent, and its corresponding payload will no longer be attempted to be transmitted; the failure to transmit the payload will be handled by the upper-layer message protocol. At the same time, the peer's sequence number is reset to a preset unknown state initial value. The preset unknown state initial value is a special value that does not correspond to any valid sequence number; in one specific implementation, it is 0xFF. Since the valid sequence numbers are 0, 1, 2, and 3, 0xFF is not within the range of valid sequence numbers, and both the receiving and sending ends can recognize this value as a special state value. Once the peer's sequence number is reset to its initial unknown value, the sequence number of any subsequently received frame will be treated as the sequence number of the new frame, thus forcibly realigning the peer's sequence numbers. Mismatch self-healing is completed automatically within one fragment time limit, requiring no manual intervention. Finally, the process begins with sending the next frame, retrieving the next frame from the sending queue and transmitting it.

[0049] This embodiment sets a preset retransmission limit to ensure the retransmission process is completed within a limited number of attempts, avoiding infinite retransmissions and system resource exhaustion when the link is continuously unavailable. In one specific implementation, the preset retransmission limit is set to 3 times, coupled with a timeout threshold of approximately 26 milliseconds. The maximum retransmission time for a single frame does not exceed approximately 104 milliseconds, maintaining the system's real-time responsiveness while ensuring reliability. When the retransmission count reaches the limit, the current frame is discarded and the peer's sequence number is reset to a preset unknown initial value, allowing the sequence number state to automatically recover synchronization and preventing the entire link from being blocked due to continuous single-frame failures. After the peer's sequence number is reset to the preset unknown initial value, subsequent received frames, regardless of their sequence number, are received as new frames, achieving forced sequence number alignment. During retransmission, the sequence number remains unchanged, ensuring that the peer can identify the retransmitted frame as an old frame and discard its payload data, avoiding duplicate data delivery to the upper layer.

[0050] In some preferred embodiments, the method further includes: receiving a raw byte stream from the half-duplex physical link, maintaining a frame synchronization state, performing a frame synchronization scan on the raw byte stream, and using candidate frames that pass frame synchronization as frames to be verified; performing a length validity check on the frames to be verified, and using the frames that pass the length validity check as length-valid frames; performing a check field check on the length-valid frames, and using the length-valid frames that pass the check field check as valid frames; extracting the transmission sequence number of the valid frames from the valid frames, and obtaining the locally maintained peer transmission sequence number; if the transmission sequence number of the valid frames is inconsistent with the peer transmission sequence number, then submitting the payload data in the valid frames as new frame data to the upper layer, and updating the peer transmission sequence number to the transmission sequence number of the valid frames; if the transmission sequence number of the valid frames is consistent with the peer transmission sequence number, then discarding the payload data in the valid frames.

[0051] In practical implementation, when acting as the receiver, it needs to receive the raw byte stream sent by the peer from the half-duplex physical link, identify legitimate frames, extract the payload, and perform sequence number deduplication. The receiver processing flow is a crucial component of reliable transmission methods, and its performance directly affects the success rate of link-layer frame reception and the accuracy of valid data extraction. Therefore, this embodiment constructs a complete receiver processing link through four stages: frame synchronization scanning, length validity verification, checksum field verification, and sequence number deduplication. This ensures accurate extraction of the payload from the interfered raw byte stream and avoids duplicate deliveries. The specific implementation method is as follows: The receiver receives the raw byte stream from the half-duplex physical link, maintains the frame synchronization state, and performs a frame synchronization scan on the raw byte stream, using candidate frames that have passed frame synchronization as frames to be verified. Further, the raw byte stream is a continuous sequence of bytes received by the physical layer, obtained by converting optical signals into electrical signals using an infrared receiver and then sampling them via a serial port. The raw byte stream may contain complete link layer frames, incomplete frame fragments, and interference data introduced by channel noise. Further, the frame synchronization state is intermediate state information maintained by the receiver during the frame synchronization scan, used to record the current scan progress. Its initial value is STATE_SYNC, indicating that the first byte of the frame header is being searched. For example, the specific values ​​of the frame synchronization state are: STATE_SYNC indicates that the first frame header byte is being searched, and STATE_FOUND_FIRST indicates that the first frame header byte has been found and the second frame header byte is being searched. The frame synchronization state is continuously updated during reception; whenever a byte is detected, the state transition direction is determined based on the byte's value and the current state. The purpose of the frame synchronization scan is to locate the starting position of the frame header in the raw byte stream and identify candidate frames. A candidate frame refers to frame data that starts from the beginning of the frame header, contains a length field, but has not yet undergone length validity verification and check field verification.

[0052] Further, the frame to be verified undergoes a length validity check. Frames that pass the length validity check are considered length-valid frames. The length validity check refers to checking whether the length field of the frame to be verified is within a reasonable range. The length field, located after the frame header, occupies one byte and indicates the number of bytes in the payload field. If the value of the length field exceeds the preset maximum payload length, it indicates that the candidate frame is not a valid link layer frame, possibly due to a byte combination in the original byte stream that is identical to the frame header being mistakenly identified as the frame header. For example, the preset maximum payload length is 255 bytes, consistent with the 1-byte value range of the length field. Values ​​in the length field between 0 and 255 are valid. When the length field value is 0, it indicates that the frame is an empty frame, carrying no payload, but it is still a valid frame and requires further processing.

[0053] Further, the length of the valid frame is checked using a check field, and the valid frame that passes the check field check is considered a valid frame. Check field check refers to performing check calculations on all fields in the frame except the check field, and comparing the calculation result with the check field value at the end of the frame. For example, the check field uses CRC-8 checksum, with a polynomial of 0x07 and an initial value of 0xFF. CRC-8 is a cyclic redundancy check algorithm. Its basic principle is to treat the data to be checked as a polynomial, divide this polynomial by a preset generator polynomial, and the remainder is the check value. The specific calculation process is as follows: the CRC register is initialized to 0xFF, then each byte of SOF_L, LEN, and PAYLOAD is XORed with the CRC register sequentially. Subsequently, eight shift and conditional XOR operations are performed on each bit, and the final 8-bit value is the check result. CRC-8 can detect single-bit errors and most multi-bit errors generated during data transmission. If the calculated check value is the same as the check field value at the end of the frame, it indicates that the frame has not been corrupted during transmission and is a valid frame. If the checksums are different, it means that a bit error occurred during transmission and the frame needs to be discarded.

[0054] Further, the sequence number of the valid frame is extracted from the valid frame to obtain the locally maintained peer sequence number. The sequence number of the valid frame is located in the sequence number field of the frame header, specifically bits 3-2 of the second frame header byte. Parsing this field yields the sequence number assigned to the frame by the peer, which can be 0, 1, 2, or 3. The locally maintained peer sequence number is a record of the sequence number of the peer's most recent transmitted frame, with an initial value of 0xFF (a preset unknown state). The record of the peer sequence number is used for subsequent new / old frame determination: if the sequence number of the current frame is different from the recorded value, it indicates a new frame; if they are the same, it indicates a retransmitted old frame.

[0055] Furthermore, if the sequence number of the valid frame is inconsistent with the sequence number sent by the peer, the payload data in the valid frame is submitted to the upper layer as new frame data, and the sequence number sent by the peer is updated to the sequence number of the valid frame. When the sequence number is inconsistent with the sequence number sent by the peer, it indicates that the frame is a new frame sent by the peer and has not yet been received. At this time, the payload data of the frame is submitted to the upper-layer message protocol for processing, and the upper-layer protocol further parses and verifies the payload data. The sequence number sent by the peer is updated to the sequence number of the current frame for deduplication of subsequent frames. The updated sequence number sent by the peer will be used as the judgment benchmark for subsequent received frames. Only when the sequence number of a subsequent frame is different from the updated value will it be regarded as a new frame again.

[0056] Furthermore, if the sequence number of the valid frame matches the sequence number sent by the peer, the payload data in the valid frame is discarded. When the sequence number matches the peer's sequence number, it indicates that the frame is an old frame retransmitted by the peer, and the payload data of this frame has already been received and delivered to the upper layer. In this case, the payload data is not retransmitted and is directly discarded to avoid the upper layer receiving duplicate data. However, the receive acknowledgment number in this frame still needs to be processed because the retransmitted frame may carry new acknowledgment information, which is meaningful for the acknowledgment advancement of the sending end. Therefore, even if the payload data is discarded, the extraction and comparison of the receive acknowledgment number are still performed.

[0057] This embodiment employs a three-level verification mechanism—frame synchronization scanning, length validity verification, and verification field verification—to accurately identify legitimate frames from the raw byte stream, effectively filtering out invalid data introduced by channel noise and synchronization errors. The first level, frame synchronization scanning, identifies candidate frames using frame header features; the second level, length validity verification, quickly eliminates illegal length values; and the third level, verification field verification, ensures data integrity. This progressive three-level verification achieves accurate frame identification without excessive computational overhead. Accurate differentiation between new and retransmitted frames is achieved by comparing the transmitted sequence number with the peer's transmitted sequence number, avoiding duplicate data delivery to the upper layer. Payload data delivery to the upper layer and peer sequence number updates are synchronized, ensuring consistency between sequence number status and data delivery status. Even if the peer's transmitted sequence number is in an unknown state (0xFF) for some reason, the first frame is accepted regardless of its sequence number, ensuring rapid synchronization after device reset.

[0058] This method does not employ byte escaping. Instead, it relies on a triple mechanism to prevent the "0x55 0x0A" combination in the payload from being misinterpreted as a frame header: ① If the length field exceeds the preset maximum payload length (e.g., 255 bytes), the state machine immediately resets and rescans; ② If a pseudo-frame fails the CRC-8 check, the entire frame is discarded, and the system rescans byte by byte from the next frame, naturally resynchronizing; ③ Damaged genuine frames are recovered by the sender through timeout retransmission. The worst-case scenario of missynchronization is simply the discarding of one frame, which is then replaced by retransmission, without affecting the parsing and reception of subsequent frames.

[0059] In some preferred embodiments, frame synchronization scanning of the original byte stream includes: reading a first byte from the current scanning position of the original byte stream; if the first byte is not the first preset value, shifting the scanning position one byte to the right and re-executing the step of reading the first byte from the current scanning position of the original byte stream; if the first byte is the first preset value, reading the next byte; if the preset bit field of the next byte is not the second preset value, shifting the scanning position to the byte after the first byte and re-executing the step of reading the first byte from the current scanning position of the original byte stream; if the preset bit field of the next byte is the second preset value, using the first byte and the next byte as frame header candidates and starting to read the length field.

[0060] Frame synchronization scanning is a crucial step for the receiver to locate the frame header from the raw byte stream. In a half-duplex infrared link, the raw byte stream is a continuous sequence of bytes, and the receiver does not know where the frame begins. Frame synchronization scanning locates the frame boundaries by detecting frame header features byte by byte. Without frame synchronization scanning, the receiver cannot determine from which byte to begin parsing the frame structure, and the reception of the entire link layer frame will be impossible.

[0061] In practice, the first byte is read from the current scan position of the original byte stream. The current scan position refers to the offset of the currently being checked byte in the original byte stream, which is initially 0. As the scan progresses, the current scan position moves forward continuously, one byte or more at a time.

[0062] If the first byte is not equal to the first preset value, it means that the current byte cannot be the first byte of the frame header, because the first byte of the frame header must be equal to the first preset value. At this time, the scan position is shifted one byte to the right, and the next byte is read and judged again. This loop continues until a byte equal to the first preset value is found.

[0063] Furthermore, if the first byte equals the first preset value, it indicates that the current byte may be the first byte of the frame header. However, the same value may also appear in the payload data. Therefore, the frame header cannot be confirmed solely based on this; the next byte immediately following it must be read for a second level of verification. If the preset bit field of the next byte is not equal to the second preset value, it indicates that the combination of these two bytes is not a valid frame header. In this case, the scan position is moved to the byte after the first byte (not the byte after the second byte), and the scan is restarted. The reason is that although the first byte matches, the second byte does not, and the frame header cannot start from the first byte; while the byte after the first byte may be the first byte of a valid frame header, skipping the second byte directly may result in missing that valid frame header.

[0064] Furthermore, if the preset bit segment of the next byte equals the second preset value, then the current two consecutive bytes satisfy all the conditions of the frame header, and both are used as frame header candidates. The reading of the following length field then begins, entering the frame content parsing stage. This frame header candidate will be used in subsequent length validity checks: if the length check fails, frame synchronization scanning must restart from the byte following the frame header candidate.

[0065] This embodiment accurately identifies the frame header position from the original byte stream through byte-by-byte scanning and dual-condition judgment. When the first byte does not match, the scan continues by moving one byte forward, achieving efficient linear search. When the first byte matches but the second byte does not, the scan position is moved to the byte after the first byte instead of the byte after the second byte, avoiding missing legitimate frame headers starting from the byte after the first byte and ensuring the integrity of frame header detection. Dual-condition judgment significantly reduces the probability of misidentifying occasional identical byte combinations in the payload as frame headers, from 1 / 256 for a single byte to approximately 1 / 65536.

[0066] In some preferred embodiments, length validity verification of the frame to be verified includes: reading the value of the length field immediately following the frame header in the frame to be verified; if the value of the length field is greater than a preset maximum payload length, the frame to be verified is determined to be an illegal frame, the frame synchronization state is reset, the scan position is moved to the byte after the candidate frame header, and the step of reading the first byte from the current scan position of the original byte stream is re-executed; if the value of the length field is less than or equal to the preset maximum payload length, the payload data and verification data are read according to the value of the length field, and the verification data is verified by the verification field.

[0067] In practice, after finding a candidate frame header during frame synchronization scanning, the receiver needs to further verify whether the candidate frame is a valid frame. The length field, which follows the frame header in the frame structure, occupies one byte and its value indicates the number of bytes in the payload field. The value of the length field must be within a reasonable range; otherwise, it indicates that the candidate frame header is a spurious frame. Length validity verification plays a fast filtering role between frame synchronization scanning and verification field verification. It can eliminate invalid candidate frames without performing computationally expensive verification field verification, improving the receiver's processing efficiency. The specific implementation method is as follows: Read the value of the length field immediately following the frame header in the frame to be checked. The length field is located after the frame header and occupies 1 byte. The frame header consists of a first frame header byte and a second frame header byte, totaling 2 bytes. Therefore, the length field is located 2 bytes off the beginning of the frame header in the original byte stream. The value of the length field ranges from 0 to 255, indicating the number of bytes in the frame payload field. When the length field value is 0, it indicates that the frame is an empty frame and does not carry any payload. Empty frames are used in the polling mechanism to maintain link rhythm; they do not carry a payload but still require a complete frame header and check field.

[0068] Furthermore, if the value of the length field is greater than the preset maximum payload length, the frame to be verified is determined to be an illegal frame. The frame synchronization state is reset, the scan position is moved to the byte after the candidate frame header, and the step of reading the first byte from the current scan position of the original byte stream is re-executed. The preset maximum payload length refers to the maximum number of payload bytes that a single link-layer frame can carry. For example, in one specific implementation, the preset maximum payload length is 255 bytes, consistent with the maximum value of the length field, meaning that the link-layer frame can carry payloads from 0 to 255 bytes. Further, when the value of the length field is greater than the preset maximum payload length, it indicates that the candidate frame header is not a valid link-layer frame. This situation usually occurs when the same byte combination as the frame header accidentally appears in the original byte stream, but the subsequent content is not a valid frame. In this case, the frame synchronization state is reset, that is, the frame synchronization state is restored from the current state to the initial state STATE_SYNC, indicating that all state information related to the current candidate frame header is discarded. At the same time, the scan position is moved to the byte after the candidate frame header, that is, the frame synchronization scan restarts from the byte after the end position of the candidate frame header. The frame header candidate consists of two bytes, with the next byte indicating the position of the byte immediately following the second byte of the candidate. For example, if the frame header candidate occupies positions i and i+1 in the original byte stream, then the next byte of the candidate will be at offset i+2. This is because if the current frame header candidate has been determined to be invalid, the actual frame header cannot begin at the current candidate's position, but it may begin at the position after the current candidate ends. Therefore, rescanning from the byte following the candidate will not miss any possible valid frame headers.

[0069] Further, if the value of the length field is less than or equal to the preset maximum payload length, the payload data and check data are read according to the value of the length field, and the check data is checked using a check field. When the value of the length field is within the valid range, the payload data is read according to the number of bytes indicated by the length field, and the check field data at the end of the frame is read. The payload data is located after the length field, and its length is the number of bytes specified by the value of the length field. The check field is located after the payload data and occupies 1 byte. Subsequently, check calculations are performed on the relevant fields in the frame header, the length field, and the payload data, and the calculation results are compared with the read check field value. Further, if the check passes, the frame is a valid frame, and the transmission sequence number and payload data are extracted. If the check fails, the frame may have had a bit error during transmission and needs to be discarded.

[0070] This embodiment uses length field validity verification to quickly identify and eliminate illegal candidate frames with minimal computational resources. The length field value judgment involves only a one-byte comparison operation, requiring no complex mathematical calculations, thus resulting in high processing efficiency. Furthermore, when the length field value exceeds a reasonable range, the frame can be determined as illegal without subsequent verification field calculations, saving unnecessary CRC calculation overhead. The frame synchronization state is reset, and the scan position is moved to the byte after the candidate frame header, allowing the receiving end to restart frame synchronization from the erroneous position, avoiding parsing errors in all subsequent frames due to a false frame header. The preset maximum payload length can be flexibly configured according to the physical layer frame structure and upper-layer message protocol requirements; in one specific implementation, it is 255 bytes.

[0071] In some preferred embodiments, the step of determining the timeout threshold for the response waiting time includes: obtaining the baud rate of the half-duplex physical link and calculating the effective byte rate based on the baud rate; obtaining the maximum frame length of the link layer frame, wherein the maximum frame length is equal to the sum of a preset maximum payload length and a frame fixed overhead; obtaining a preset link processing margin; and calculating the timeout threshold by dividing the sum of the maximum frame length and the preset link processing margin by the effective byte rate and adding the preset fixed margin.

[0072] In practice, the timeout threshold is the time base for the sending end to determine whether frame transmission has timed out, and its unit is milliseconds. In a half-duplex link, the setting of the timeout threshold needs to comprehensively consider factors such as physical layer transmission rate, frame length, and processing latency. If the timeout threshold is set too low, unnecessary retransmissions may be triggered before the frame reaches the other end or before the other end returns a response, wasting link bandwidth and increasing transmission latency. If the timeout threshold is set too high, frames may not be detected for a long time after being lost, reducing the real-time response of the system and affecting the timeliness of command interaction. Therefore, this embodiment calculates the timeout threshold based on baud rate, maximum frame length, and link processing margin to achieve precise tuning of the timeout threshold, matching it with the actual transmission capacity of the physical link. The specific implementation method is as follows: The baud rate of the half-duplex physical link is obtained, and the effective byte rate is calculated based on the baud rate. The baud rate is the number of symbols transmitted per second at the physical layer, measured in bits per second. In serial communication, each symbol corresponds to one bit. For asynchronous serial communication, each byte transmission requires additional start and stop bits. Taking the typical 8N1 format as an example, 8N1 means that each byte contains 8 data bits, no parity bit, and 1 stop bit, plus 1 start bit, for a total of 10 bits. The effective byte rate is equal to the baud rate divided by the number of bits per byte, measured in bytes per second. In one specific implementation, when the baud rate is 115200 bits per second, each byte corresponds to 10 bits, and the effective byte rate is 115200 divided by 10, equal to 11520 bytes per second. The effective byte rate reflects the actual rate at which the physical layer transmits effective data bytes after removing the overhead of start and stop bits.

[0073] Further, the maximum frame length of the link layer frame is obtained, whereby the maximum frame length is equal to the sum of the preset maximum payload length and the frame fixed overhead. Frame fixed overhead refers to the number of bytes occupied by all fields in the link layer frame except the payload field, including the first frame header byte, the second frame header byte, the length field, and the checksum field. In one specific implementation, the frame fixed overhead is 4 bytes, specifically 1 byte for the first frame header byte, 1 byte for the second frame header byte, 1 byte for the length field, and 1 byte for the checksum field. When the preset maximum payload length is 255 bytes, the maximum frame length is 255 plus 4, which equals 259 bytes.

[0074] Furthermore, a preset link processing margin is obtained. The preset link processing margin is an additional time allowance set to cover the framing time at the sending end, the parsing time at the receiving end, and the forwarding delay of intermediate devices. It is measured in bytes and represents the processing delay as equivalent to an additional byte transmission time. For example, in one specific implementation, the preset link processing margin is 8 bytes, used to cover the software processing time for the sending end to construct the frame, the time for the receiving end to parse the frame header, and the propagation delay of the frame on the physical medium. Incorporating the preset link processing margin into the timeout calculation ensures that the timeout threshold covers not only the frame transmission time but also the software processing time at both the sending and receiving ends.

[0075] Further, the timeout threshold is calculated by dividing the sum of the maximum frame length and the preset link processing margin by the effective byte rate, and then adding a preset fixed margin. The formula for calculating the timeout threshold T_timeout is: T_timeout = (maximum frame length + preset link processing margin) × 1000 / effective byte rate + preset fixed margin. In this formula, the maximum frame length represents the maximum number of bytes in a single frame, the preset link processing margin represents the number of bytes equivalent to the software processing delay at both ends, and the sum of the two represents the total equivalent number of bytes from the start of the frame to the point where the other end has completed processing and begun returning a response frame. Multiplying by 1000 converts the unit from seconds to milliseconds. Dividing by the effective byte rate yields the equivalent transmission time, in milliseconds. The preset fixed margin is used to cover other unquantifiable delay factors such as physical layer propagation delay and other processing delays at the other end, in milliseconds.

[0076] Furthermore, in one specific implementation, the effective byte rate is 11520 bytes per second, the maximum frame length is 259 bytes, the preset link processing margin is 8 bytes, and the preset fixed margin is 3 milliseconds. Substituting into the formula: T_timeout = (259 + 8) × 1000 / 11520 + 3 = 267000 / 11520 + 3 ≈ 23.18 + 3 ≈ 26.18 milliseconds, approximately equal to 26 milliseconds. This timeout threshold indicates that the maximum allowed time from the start of frame transmission to the receipt of the return frame from the other end is approximately 26 milliseconds. If a frame is not received from the other end after 26 milliseconds, it is determined to be a timeout, and retransmission is triggered.

[0077] This embodiment calculates the timeout threshold precisely based on baud rate, maximum frame length, and link processing margin, ensuring that the timeout threshold matches the actual transmission capacity of the physical link. The precise timeout threshold avoids premature retransmissions due to an excessively small threshold and response delays due to an excessively large threshold, thus optimizing retransmission efficiency. Furthermore, the calculation of the effective byte rate considers the start and stop bit overhead of asynchronous serial communication, reflecting the actual data transmission rate. The introduction of preset link processing margin and preset fixed margin covers the software processing delays and physical propagation delays at both the sending and receiving ends, improving the applicability of the timeout threshold in practical systems. The timeout threshold can be flexibly adjusted according to different baud rates and frame lengths, exhibiting good configurability. For example, in one specific implementation, a timeout threshold of approximately 26 milliseconds, combined with a maximum retransmission limit of 3 times, can maintain the real-time performance of command interaction while ensuring reliable transmission.

[0078] In some preferred embodiments, all service transmission requests write the data to be transmitted into the transmission queue in a non-blocking manner. The method further includes: determining whether the remaining capacity of the transmission queue is sufficient to accommodate the data to be transmitted; if the remaining capacity of the transmission queue is insufficient to accommodate the data to be transmitted, discarding the data to be transmitted; if the remaining capacity of the transmission queue is sufficient to accommodate the data to be transmitted, writing the data to be transmitted into the transmission queue; wherein, the local end acts as the sole consumer of the transmission queue, retrieves data from the transmission queue, constructs the link layer frame, and transmits it.

[0079] In practical implementation, under multi-task concurrency scenarios, multiple business tasks may simultaneously generate requests to send data to the half-duplex physical link. For example, in airborne equipment, flight control tasks may need to send flight status data to the ground station, firmware upgrade tasks may need to send firmware fragment data, and logging tasks may need to send log data. If multiple tasks directly operate the physical link simultaneously, it will lead to disordered transmission timing, violating the constraint that the half-duplex physical layer can only transmit in one direction at a time. At the same time, if a task is blocked and waiting when the link is busy, it may cause a decrease in the real-time performance of the entire system, affecting the execution of critical tasks. To address this, this embodiment achieves unified scheduling of concurrent multi-task transmission through a non-blocking transmission queue and a single consumer mode.

[0080] First, all business sending requests write the data to be sent to the sending queue in a non-blocking manner. The sending queue is a first-in, first-out (FIFO) data buffer used to temporarily store data to be sent. Its capacity is a pre-defined number of bytes, which is 8192 bytes in one specific implementation, enough to buffer approximately 30 message frames. Non-blocking means that the write operation will not wait because the queue is full, but will immediately return the write result. When the calling task performs an enqueue operation, if the queue has enough space, the data is written to the queue and a success status is returned; if the queue is full, the data is discarded and a failure status is returned, and the calling task will not block or wait. This non-blocking design allows calling tasks to complete the submission of sending requests in a very short time, without being suspended due to link congestion or queue overflow, thus protecting the system's real-time performance. When multiple business tasks concurrently call the sending interface, each task submits the data to be sent to the sending queue, which naturally serializes the data. Multiple tasks do not need to coordinate with each other or care about the current state of the physical link; they only need to submit the data to the queue.

[0081] Further, it is determined whether the remaining capacity of the sending queue is sufficient to accommodate the data to be sent. Remaining capacity refers to the amount of unoccupied storage space in the sending queue, which is equal to the total queue capacity minus the currently occupied space. Before writing the data to be sent into the queue, it is first checked whether the remaining capacity of the queue is sufficient to store the data. The data to be sent includes a payload and its associated control information, such as data length and priority identifier.

[0082] Furthermore, if the remaining capacity of the sending queue is insufficient to accommodate the data to be sent, the data is discarded. When the queue is full or the remaining capacity is insufficient to accommodate new data, the data to be sent is directly discarded, and a write failure status is returned. The discard operation does not block the calling task; the calling task can continue to execute other operations or retry later. This queue-full discard strategy protects the real-time performance of the system and avoids blocking of the calling task due to queue congestion. In resource-constrained embedded systems, queue capacity is limited, and queue-full discard is a necessary means to ensure system real-time performance. If the calling task is allowed to block and wait when the queue is full, critical tasks may be suspended for a long time, affecting the deterministic response of the system.

[0083] Furthermore, if the remaining capacity of the sending queue is sufficient to accommodate the data to be sent, the data to be sent is written into the sending queue. When there is enough space in the queue, the data to be sent is written sequentially to the tail of the queue. After the write operation is completed, the data waits to be retrieved and sent. The queue adopts a first-in, first-out (FIFO) principle; data written first will be retrieved first, ensuring fairness in service sending requests. The write operation is a memory copy operation, which is fast and does not affect the current sending status of the physical link.

[0084] Furthermore, as the sole consumer of the sending queue, the link control task retrieves data from the sending queue and constructs the link layer frame for transmission. "Sole consumer" means that only the link control task is responsible for retrieving data from the sending queue and performing the actual physical layer transmission operation. No other service task may directly operate the half-duplex physical link; they can only indirectly submit transmission requests by writing to the sending queue. The link control task performs the following operations in a loop: checks if the sending queue is empty; if not empty, it retrieves a data block from the head of the queue, constructs a link layer frame according to the method described in the above embodiment, and sends it to the half-duplex physical link, then waits for acknowledgment or timeout for the frame. Only when the transmission process of the current frame is complete, including successful acknowledgment or exhaustion of retransmissions, does the link control task retrieve the next data block from the queue for transmission. This serialization ensures that data transmission occurs in only one direction on the physical link at any given time, satisfying the direction switching constraints of the half-duplex physical layer.

[0085] This embodiment serializes concurrent multi-task sending requests using a non-blocking send queue, enabling multiple service tasks to securely share the same half-duplex physical link without the need for additional mutex locks or semaphore synchronization. The queue has a capacity of 8192 bytes, capable of buffering approximately 30 message frames, effectively absorbing short bursts of sending requests. A queue-full discard strategy protects the system's real-time performance, preventing task blocking due to queue congestion. The single-consumer mode ensures that the physical link's sending operation is exclusively executed by a single task, guaranteeing controllable direction switching timing for the half-duplex physical link and preventing direction conflicts caused by multiple tasks operating the physical link simultaneously. The send queue capacity can be flexibly configured based on system memory resources and caching requirements.

[0086] In some preferred embodiments, the present invention provides a reliable transmission method based on piggyback acknowledgment in a half-duplex link, which further designates one end of the local end and the peer end as a polling master end and the other end as a polling slave end; wherein the polling master end sends the link layer frame when there is data to send and sends an empty frame when there is no data to send; the polling slave end only sends a data frame or an empty frame as an acknowledgment after receiving the frame sent by the polling master end.

[0087] In practical implementation, in a half-duplex link, both ends may need to send data at any time. If both ends send data simultaneously at what they deem appropriate times, a conflict will inevitably occur, resulting in data corruption on both sides. While traditional conflict detection and backoff retry mechanisms are feasible in half-duplex links, they increase transmission latency and implementation complexity. Therefore, this embodiment designates one end as the polling master and the other end as the polling slave. The master controls the transmission rhythm of the entire link, avoiding conflicts caused by simultaneous transmission from both ends. Simultaneously, empty frame polling allows the slave end to have a chance to send data even when there is none available.

[0088] One end is designated as the polling master, and the other as the polling slave. The polling master is responsible for controlling the transmission rhythm of the link, while the polling slave is the passive responder. For example, in a communication scenario between airborne equipment and a ground operations station, the airborne equipment can be designated as the polling master, and the ground operations station as the polling slave; alternatively, the roles can be reversed based on actual application requirements. The roles of the polling master and polling slave are determined when the link is established and remain unchanged during communication. Role assignment can be achieved through configuration parameters, such as reading a configuration file during system initialization or receiving role assignment instructions from a host computer.

[0089] Furthermore, the polling master sends the link layer frame when there is data to send, and sends an empty frame when there is no data to send. The polling master checks whether it has data to send within each polling cycle. A polling cycle refers to the complete interaction process from when the polling master sends a frame to when it receives a response from the peer and prepares to send the next frame. If there is data to send, the polling master constructs and sends a data frame according to the method described in the above embodiment, and then waits for a response from the peer. If there is no data to send, the polling master sends an empty frame. An empty frame is a link layer frame with a length field of 0, containing only a frame header, length field, and checksum field, and does not carry a payload. The minimum length of an empty frame is 4 bytes: 1 byte for the first frame header, 1 byte for the second frame header, 1 byte for the length field, and 1 byte for the checksum field. The purpose of the empty frame is to maintain the polling rhythm of the link while giving the polling slave an opportunity to send data. The empty frame also contains a sequence number and a receipt acknowledgment number, so it can both maintain the polling rhythm and piggyback acknowledgment information. Sending empty frames instead of remaining silent when there is no data allows the polling slave to have a chance to send once in each polling cycle, avoiding the slave's data sending request being delayed indefinitely.

[0090] Furthermore, the polling slave only sends a data frame or an empty frame as an acknowledgment after receiving a frame from the polling master. The polling slave does not actively initiate transmissions but passively waits for frames from the polling master. When the polling slave receives a frame from the polling master, it checks if it has data to send. If it does, the polling slave sends the data as an acknowledgment frame to the polling master. The format of the acknowledgment frame is the same as a normal data frame, containing a transmission sequence number and a reception acknowledgment number, where the reception acknowledgment number is used to confirm the received frame to the polling master. If there is no data to send, the polling slave sends an empty frame as an acknowledgment. After sending its acknowledgment, the polling slave re-enters the waiting state, waiting for the next round of frames from the polling master. Under this mechanism, the direction switching of the half-duplex link is naturally guaranteed by the protocol timing during each transmission and acknowledgment alternation: after the master sends, the link direction is from the master to the slave; during the master's waiting period, the link is idle; when the slave responds, the link direction is from the slave to the master; after the slave responds, the link becomes idle again, and the master begins the next round of transmission. The timing of direction switching is determined by the order of frame transmission and acknowledgment, without the need for additional direction switching control signals.

[0091] This embodiment designates a polling master and a polling slave, allowing the transmission timing of the half-duplex link to be entirely controlled by the polling master. The polling master actively initiates frame transmission in each round of interaction, while the polling slave only responds after receiving a frame, avoiding conflicts caused by simultaneous transmissions from both ends and resolving the data corruption problem. The introduction of empty frames allows the polling master to maintain its polling rhythm even when no data is being transmitted, giving the polling slave an opportunity to send data and ensuring a balanced transmission opportunity between the two ends. Since the polling slave does not actively transmit, there is no possibility of simultaneous physical layer conflicts between transmission requests from both ends. This polling arbitration mechanism does not rely on physical layer conflict detection capabilities and is suitable for half-duplex physical links without conflict detection functions, such as infrared links. During each transmission and response alternation, the direction switching of the half-duplex link is naturally guaranteed by the protocol timing, eliminating the need for additional direction switching control signals and reducing the complexity of physical layer control. The empty frames carry both transmission sequence numbers and reception acknowledgment numbers, allowing them to maintain the polling rhythm while also carrying acknowledgment information, without wasting transmission opportunities.

[0092] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0093] Please see Figure 2 , Figure 2 This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 500 can be a terminal or a server, wherein the server can be a standalone server or a server cluster composed of multiple servers.

[0094] The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a system bus 501. The memory may include a non-volatile storage medium 503 and internal memory 504.

[0095] The non-volatile storage medium 503 may store an operating system 5031 and a computer program 5032. When the computer program 5032 is executed, it enables the processor 502 to perform a reliable transmission method based on piggyback acknowledgment in a half-duplex link.

[0096] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0097] The internal memory 504 provides an environment for the execution of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a reliable transmission method based on piggyback acknowledgment in a half-duplex link.

[0098] The network interface 505 is used for network communication with other devices. Those skilled in the art will understand that the above structure is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 500 to which the present application is applied. A specific computer device 500 may include more or fewer components than shown in the figures, or combine certain components, or have different component arrangements.

[0099] The processor 502 is used to run a computer program 5032 stored in a memory to implement the steps of a reliable transmission method based on piggyback acknowledgment in a half-duplex link provided in any of the above method embodiments.

[0100] It should be understood that in the embodiments of this application, the processor 502 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0101] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program may be stored in a storage medium, which is a computer-readable storage medium. The computer program is executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0102] Therefore, the present invention also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program. When executed by a processor, the computer program causes the processor to perform the steps of a reliable transmission method based on piggyback acknowledgment in a half-duplex link provided in any of the above method embodiments.

[0103] The storage medium is a physical, non-transient storage medium, such as a USB flash drive, external hard drive, read-only memory (ROM), magnetic disk, or optical disk, or any other physical storage medium capable of storing program code. The computer-readable storage medium can be non-volatile or volatile.

[0104] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0105] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0106] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0107] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0108] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0109] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, this invention is also intended to include these modifications and variations as long as they fall within the scope of the claims of this invention and their equivalents.

[0110] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A reliable transmission method based on piggyback acknowledgment in a half-duplex link, characterized in that, include: In response to receiving a payload, a link layer frame is constructed, which includes a transmission sequence number and a reception acknowledgment number. The transmission sequence number is the sequence number of this frame, and the reception acknowledgment number is the sequence number of the most recently transmitted frame from the peer that has been correctly received by this end. The link layer frame is sent to the half-duplex physical link, and an acknowledgment waiting timer is started; When a frame is received from the peer before the response waiting timer expires, the reception acknowledgment number carried in the frame is extracted from the frame returned by the peer. If the reception acknowledgment number carried in the frame returned by the peer is equal to the transmission sequence number of the link layer frame most recently sent by this end, then it is confirmed that the link layer frame most recently sent by this end has been correctly received, and the transmission sequence number maintained by this end is advanced to the next sequence number value. If the sequence number of the received acknowledgment carried in the frame returned by the peer is not equal to the sequence number of the link layer frame most recently sent by this end, then the sequence number of this end is kept unchanged and the link layer frame most recently sent by this end is retransmitted. If no frame is received from the peer after the response waiting timeout, the local end maintains its transmission sequence number and retransmits the link layer frame most recently transmitted by the local end.

2. The reliable transmission method based on piggyback acknowledgment in a half-duplex link according to claim 1, characterized in that, The link layer frame includes a frame header, which includes a first frame header byte and a second frame header byte. The construction of the link layer frame includes: Set the first frame header byte to the first preset value; The preset bit field of the second frame header byte is set to a second preset value. The second frame header byte is provided with a first bit field and a second bit field. The first bit field is used to carry the transmission sequence number, and the second bit field is used to carry the reception acknowledgment number. The first frame header byte and the second frame header byte are arranged sequentially to form the frame header.

3. The reliable transmission method based on piggyback acknowledgment in a half-duplex link according to claim 1, characterized in that, Maintaining the local transmission sequence number unchanged and retransmitting the most recently transmitted link layer frame includes: Get the current retransmission count of the link layer frame most recently sent by this end; If the current retransmission count has not reached the preset retransmission limit, the current retransmission count will be incremented by one, and the link layer frame most recently sent by this end will be retransmitted. If the current retransmission count has reached the preset retransmission limit, the most recently transmitted link layer frame from this end is discarded, the transmission sequence number of the peer end is reset to the preset unknown state initial value, and the transmission process of the next frame begins.

4. The reliable transmission method based on piggyback acknowledgment in a half-duplex link according to claim 2, characterized in that, The method further includes: The system receives the raw byte stream from the half-duplex physical link, maintains the frame synchronization state, performs a frame synchronization scan on the raw byte stream, and takes the candidate frames that have passed frame synchronization as the frames to be verified. Perform a length validity check on the frame to be checked, and take the frame to be checked that passes the length validity check as a length valid frame; Perform a check field check on the length of the valid frame, and take the length valid frame that passes the check field check as a valid frame; Extract the transmission sequence number of the legal frame from the legal frame, and obtain the locally maintained peer transmission sequence number; If the sequence number of the valid frame is inconsistent with the sequence number of the peer, the payload data in the valid frame is submitted to the upper layer as new frame data, and the sequence number of the peer is updated to the sequence number of the valid frame. If the sequence number of the valid frame is the same as the sequence number of the peer, the payload data in the valid frame is discarded.

5. The reliable transmission method based on piggyback acknowledgment in a half-duplex link according to claim 4, characterized in that, The frame synchronization scan of the original byte stream includes: Read the first byte from the current scan position of the original byte stream; If the first byte is not the first preset value, then the scan position is shifted one byte to the right, and the step of reading the first byte from the current scan position of the original byte stream is re-executed; If the first byte is the first preset value, then read the next byte; If the preset bit segment of the next byte is not the second preset value, then the scan position is moved to the byte after the first byte, and the step of reading the first byte from the current scan position of the original byte stream is re-executed; If the preset bit segment of the next byte is the second preset value, then the first byte and the next byte are used as frame header candidates, and the length field is read starting. The length validity check of the frame to be checked includes: Read the value of the length field immediately following the frame header in the frame to be verified; If the value of the length field is greater than the preset maximum payload length, the frame to be verified is determined to be an illegal frame, the frame synchronization state is reset, the scanning position is moved to the byte after the frame header candidate, and the step of reading the first byte from the current scanning position of the original byte stream is re-executed. If the value of the length field is less than or equal to the preset maximum load length, then the load data and verification data are read according to the value of the length field, and the verification data is verified by the verification field.

6. The reliable transmission method based on piggyback acknowledgment in a half-duplex link according to claim 5, characterized in that, The steps for determining the timeout threshold for the response waiting time include: Obtain the baud rate of the half-duplex physical link, and calculate the effective byte rate based on the baud rate; Obtain the maximum frame length of the link layer frame, wherein the maximum frame length is equal to the sum of the preset maximum payload length and the frame fixed overhead; Obtain the preset link processing margin; The timeout threshold is calculated by dividing the sum of the maximum frame length and the preset link processing margin by the effective byte rate, and then adding the preset fixed margin.

7. The reliable transmission method based on piggyback acknowledgment in a half-duplex link according to claim 1, characterized in that, All service sending requests are written to the sending queue in a non-blocking manner. The method further includes: Determine whether the remaining capacity of the sending queue is sufficient to accommodate the data to be sent; If the remaining capacity of the sending queue is insufficient to accommodate the data to be sent, then the data to be sent is discarded. If the remaining capacity of the sending queue is sufficient to accommodate the data to be sent, then the data to be sent is written into the sending queue; In this context, the local end acts as the sole consumer of the sending queue, retrieves data from the sending queue, constructs the link layer frame, and sends it.

8. The reliable transmission method based on piggyback acknowledgment in a half-duplex link according to claim 1, characterized in that, One end (local or remote) is designated as the polling master, and the other end is designated as the polling slave. The polling master sends the link layer frame when there is data to send and sends an empty frame when there is no data to send. The polling slave only sends a data frame or an empty frame as a response after receiving a frame sent by the polling master.

9. A computer device, characterized in that, The computer device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, can implement the method as described in any one of claims 1-8.

Images