SOCKET communication receiving method for variable-length data packets

Abstract

The invention discloses a SOCKET communication receiving method for variable-length data packets, which relates to the technical field of computer network data transmission, and comprises the following steps of: establishing a user-defined communication protocol containing a length field, a number field and a CRC-32 checksum field, and matching with a dynamic management mechanism of a double linked list segmented buffer area of a receiving end, so that the data packets with different lengths can be received. According to the method and the device provided by the invention, the efficient receiving of the variable-length data packet is realized, a receiving end predicts the buffer extension amount through a sliding window historical array, and the problems of memory waste, data loss, packet sticking, disorder and the like caused by a traditional fixed buffer are solved by combining incremental CRC-32 verification and segmentation-level accurate retransmission, so that the memory utilization rate and the data transmission integrity are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of computer network data transmission, in particular to a SOCKET communication receiving method for variable-length data packets. Background Art

[0002] SOCKET is a commonly used network communication interface used to realize data transmission between the host computer and the slave computer.

[0003] In practical applications, the length of data packets is often not fixed. For example, in scenarios such as sensor data acquisition and file transfer, the size of data will vary depending on the actual situation. Traditional socket communication receiving methods use a fixed buffer to receive data when processing variable-length data packets. When the data packet length exceeds the buffer size, data loss will occur; when the data packet length is short, it will cause a waste of buffer resources. Some methods simply piece together complete data packets by receiving data multiple times. This method lacks an effective data boundary identification and management mechanism, and is prone to problems such as data misalignment, stuck packets, and half-packets. It cannot guarantee the integrity and accuracy of received data, seriously affecting communication quality and system stability. Therefore, there is an urgent need for an efficient and reliable SOCKET communication receiving method for variable-length data packets. Summary of the Invention

[0004] In view of the shortcomings of the prior art, the present invention provides a SOCKET communication receiving method for variable-length data packets, which solves the problems of data loss, sticky packets, half packets and buffer waste when receiving variable-length data packets.

[0005] To achieve the above objectives, the present invention is implemented through the following technical solutions: A SOCKET communication receiving method for variable-length data packets, comprising: S1. Establish a custom communication protocol between the transmitting end and the receiving end, wherein the protocol includes a data packet header and a data payload, wherein the data packet header specifically includes a length field, a number field, and a CRC-32 checksum field; S2, the sending end encapsulates the data according to the protocol, fills the length field, assigns a number, calculates the CRC-32 checksum and sends it through the socket; S3. The receiving end creates a bidirectional linked list segment buffer, initializes the first node, temporary segment pointer, sliding window history array, and CRC-32 checksum calculator, establishes a socket connection, and binds the segment buffer. S4. Obtain received data and write it into a segment buffer. Synchronously calculate the CRC-32 checksum byte by byte. When the cumulative received data reaches the packet header length, parse the length field to obtain the number of payload bytes. Dynamically predict the extension amount based on the historical packet length and expand the buffer. S5, based on the total data length of the segment linked list and the packet header parsing to obtain the payload start offset, construct a descriptor containing the segment node pointer and the node offset; S6. If the verification passes, it is delivered to the upper layer. If it fails, the offset of the error segment is located and accurate retransmission is requested. The above steps are repeated until the connection is closed.

[0006] As a further improvement of the present invention, the content of the first node initialization is: allocate the first segment node memory, the default size is set to 1024 bytes; initialize the node attributes, data_ptr points to the allocated memory address, the valid data length length is set to 0, and the next pointer points to null; set the first node as the current working node; The content of the temporary segment pointer temp_ptr is as follows: defining a temp_ptr pointer structure, including the starting segment node segment_ptr pointing to the unparsed remaining data, the byte offset offset in the starting node, and the remaining data length remaining_len; initially, segment_ptr is set to NULL, offset is set to 0, and remaining_len is set to 0; The content of the sliding window history array initialization is: create an unsigned integer array history_len

[10] with a length of 10, initialize the array elements to 0, set the current write index window_index to 0, and the number of recorded packets window_count to 0; The contents of the CRC-32 checksum calculator initialization are: defining a CRC-32 checksum variable current_crc, setting the initial value to 0xFFFFFFFF, and loading a CRC-32 polynomial table.

[0007] As a further improvement of the present invention, the specific steps of data receiving and writing are: Write the data_ptr pointer position of the current segment node and start appending from the current valid length, where data_ptr is the physical starting address of the node data; After each write, the node length value is updated and the remaining space is calculated according to the formula: remaining = node capacity - length; If remaining==0, create a new segment node, link it to the end of the linked list through the next pointer, and set it as the new current node; Every time 1 byte of data is received, the incremental CRC-32 function is called to calculate the checksum current_crc at that time. The CRC-32 function is based on the predefined CRC-32 polynomial and the initial value, and quickly calculates by table lookup method and saves current_crc in real time.

[0008] As a further improvement of the present invention, the specific steps of dynamically predicting the extension amount based on the historical data packet length are: Parse the packet header length field L; Check whether the sliding window history array history_len records the lengths of the first 10 packets; Calculate the average historical length avg_L. If history_count < 10, only the recorded data is used for calculation; The predicted expansion amount is calculated according to the formula predict_len = max(L,avg_L×1.5). The final predicted_len needs to be rounded up to a multiple of 1024 bytes.

[0009] As a further improvement of the present invention, the total data length of the current segment linked list is calculated according to the formula current_total=sum(length of each node). If current_total<L, the data is expanded and received according to the following rules: If the predicted extension amount predict_len does not reach the current total length, add a new segment node according to predict_len; Call the SOCKET receive function and write the data into the segment linked list until current_total ≥ L, where sum() is the summation function.

[0010] As a further improvement of the present invention, the specific steps of locating the load area are: According to the packet header parsing result, calculate the starting offset of the load in the linked list load_offset; Traverse the linked list. When current_total ≥ load_offset, find the node curr_node where the load starts. Calculate the local offset within the node according to the formula local_offset = load_offset - current_total. The load end position is obtained as load_offset+L, forming the load area [data_ptr+local_offset,data_ptr+local_offset+L].

[0011] As a further improvement of the present invention, the descriptor specifically includes a load starting node, an offset within the starting node, a total length of the load, and a load ending node.

[0012] As a further improvement of the present invention, the descriptor is passed to the application layer, and the application layer directly reads data through pointer offset according to the descriptor. If it needs to be passed to other modules, the descriptor can also be directly passed.

[0013] As a further improvement of the present invention, the specific steps of data verification and accurate retransmission are: The sender calculates the CRC-32 checksum for each segment node and appends it to the header; After receiving the segment, the receiver immediately calculates the CRC-32 checksum of the data part and compares it with the checksum carried in the segment header. If they do not match, the segment is marked as an error. Periodically send NAK packets to the sender to report the error segment number; After receiving the NAK, the sender extracts the corresponding segment from the cache and resends it with the same segment number and checksum. After receiving the retransmitted segment, the receiver verifies the CRC-32 checksum. If the check passes, the receiver replaces the original erroneous segment with the new segment and updates the data pointer in the segment list.

[0014] As a further improvement of the present invention, after all segments are received, it is necessary to calculate the overall CRC-32 checksum of the integrated complete data and compare the overall checksum with the global checksum pre-provided by the sending end.

[0015] The present invention provides a SOCKET communication receiving method for variable-length data packets, which has the following beneficial effects compared with the prior art: (1) The present invention solves the problems of memory waste and data loss caused by the fixed size of traditional continuous buffers through a bidirectional linked list segmented buffer and a zero-copy expansion mechanism, realizes on-demand memory allocation, and improves memory utilization; (2) The present invention uses a sliding window history array to dynamically predict the buffer expansion amount, calculates the optimal expansion value based on the length pattern of historical data packets, and reduces the number of memory allocations and system call overhead; (3) The present invention adopts a hierarchical mechanism that combines segment-level CRC-32 check and global check to detect and locate transmission errors in real time, accurately retransmit through the NAK mechanism, reduce network traffic waste, and ensure data integrity. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 It is a flow chart of the steps of the present invention. DETAILED DESCRIPTION

[0017] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0018] like Figure 1 The present invention provides a SOCKET communication receiving method for variable-length data packets, comprising: Establishing a custom communication protocol between the sending end and the receiving end, the protocol includes a data packet header and a data payload, wherein the data packet header specifically includes a length field, a number field, and a CRC-32 checksum field; The length field is used to accurately identify the number of bytes in the data payload to solve the boundary parsing problem of variable-length data packets; Because traditional methods often use fixed buffers, they cannot adapt to large data packets that exceed the buffer, resulting in data loss. On the other hand, relying on a specified maximum length can waste memory for small data packets, such as 36 bytes of data occupying a 1024-byte buffer. By setting the length field in the header, the receiving end can dynamically adjust the buffer according to the length field, allocate memory on demand, and improve memory utilization. For example, for 10240 bytes of data, only 10240 bytes + the header space are allocated. The number field assigns a unique serial number to the data packet, solving the problem of disordered data packets during network transmission and supporting the receiving end to reassemble the data in sequence; During network transmission, routing jitter may cause data packets to arrive out of order. Traditional solutions without a numbering mechanism make it impossible for the receiver to restore the data order. Furthermore, in high-frequency data collection scenarios, such as molecular beam equipment reporting 100 times per second, out-of-order data can cause real-time data timing errors, affecting device control accuracy. By setting a number field in the header, the receiver can reorder out-of-order data packets according to the number, ensuring that upper-layer applications obtain data with correct timing, such as processing sensor sampling data in chronological order; It also supports breakpoint resuming and other functions. For example, when a certain numbered data packet is lost, you can explicitly request to retransmit the numbered packet. The CRC-32 checksum field can verify the data payload and detect data errors caused by electromagnetic interference, network jitter, etc. during transmission; If traditional solutions lack a verification mechanism, erroneous data entering upper-layer applications can cause device control anomalies. For example, molecular beam epitaxy equipment can misread gas pressure values, leading to incorrect thin film growth parameters. By setting a CRC-32 checksum field in the header, data errors can be detected in real time, such as when a byte is flipped during transmission, preventing erroneous data from being processed and ensuring system stability. It can also be combined with a subsequent precise retransmission mechanism to retransmit only the erroneous data segment, reducing network traffic waste. The CRC-32 checksum field uses an incremental checksum algorithm, which supports calculation while receiving at the receiving end; The incremental verification algorithm is mainly used to terminate invalid reception in advance and adapt the dynamic buffer mechanism: If data errors occur during transmission, the receiving end will detect the checksum anomaly when it receives the error byte and immediately terminate the reception, avoiding receiving the remaining invalid bytes and significantly saving network traffic. The receiving end uses a segmented buffer to parse while receiving. The incremental calculation matches the segmented receiving process. Each byte received is checked, without waiting for the entire data packet to be received. The error detection delay is advanced from "after the reception is completed" to "during the reception process", thereby reducing the delay.

[0019] The sender encapsulates data according to the following process: Calculate the actual length L of the payload and fill the length field; Assign unique numbers according to the order of sending, such as increasing counts; Use the incremental CRC-32 algorithm to calculate the checksum in byte stream order, such as from byte 1 to byte L; Send the encapsulated data packet through SOCKET.

[0020] The receiving end creates a doubly linked list segment buffer, initializes the first node, temporary segment pointer, sliding window history array, and CRC-32 checksum calculator, establishes a socket connection, and binds the segment buffer. The specific steps to initialize the first node are: Allocate the first segment node memory, the default size is set to 1024 bytes; Initialize the node attributes, data_ptr points to the allocated memory address, the valid data length is set to 0, the next pointer points to null, and there is no subsequent node; Set the first node as the current working node to receive initial data; The doubly linked list structure supports zero data copy during dynamic expansion (i.e., adding new nodes only requires pointer links, without copying existing data). This solves the high copy overhead of traditional continuous buffer expansion. For example, expanding by 10240 bytes requires copying 10240 bytes, while expanding a linked list only requires pointer operations. The default size of 1024 bytes balances the efficiency of initial reception with memory usage: 1024 bytes is sufficient to accommodate multiple small data receptions. For example, there is still space left after the initial 12-byte packet header is received, avoiding frequent expansion caused by an overly small buffer. For example, when the host computer is initialized, the first node Node1 (1024 bytes) is created, data_ptr points to the memory address 0x1000, length = 0, and when the 12-byte packet header sent by the compound pump is received, it is directly written into Node1, and the length is updated to 12. The remaining space of 1012 bytes can continue to receive data; The specific steps to initialize the temporary segment pointer temp_ptr are: Define the temp_ptr pointer structure, including: segment_ptr, points to the starting segment node of the remaining unparsed data; offset, the byte offset in the starting node; remaining_len, remaining data length; Initially, segment_ptr is set to NULL, offset is set to 0, and remaining_len is set to 0; When there is incompletely parsed remaining data in the receive buffer, such as multiple data packets stuck together in a packet sticking scenario, temp_ptr records the data location, eliminating the need to copy the remaining data to a temporary array, thus avoiding the memory copy overhead of the remaining byte-level data. If the payload tail and header of multiple data packets overlap, temp_ptr can ensure the correct data order; For example, if the receiver has processed the 10240-byte payload of packet 1 and there are 2048 bytes remaining in the buffer (the header of packet 2), temp_ptr points to offset 10240 of the first node, and remaining_len is set to 2048. The next time new data is received, the 2048 bytes pointed to by temp_ptr are first spliced, and then the new data is received to avoid losing the header of packet 2. The specific steps to initialize the sliding window history array are: Create an unsigned integer array history_len

[10] of length 10 to store the lengths of the first 10 data packets; Initialize the array element to 0, set the current write index window_index to 0, and the number of recorded packets window_count to 0; By learning packet length patterns from historical data, we can avoid the multiple allocation overhead caused by fixed expansion in traditional solutions. In industrial scenarios, data packet lengths may be periodic (e.g., data volume is stable when equipment is operating normally). The historical array can dynamically adjust prediction parameters to make the expansion more in line with actual needs and reduce memory fragmentation. The specific steps to initialize the CRC-32 checksum calculator are: Define the CRC-32 checksum variable current_crc and set its initial value to 0xFFFFFFFF; Load the CRC-32 polynomial table for incremental calculation; The receiving end must use the same CRC-32 calculation rules as the sending end, such as initial value, polynomial, and inversion flag, to ensure consistent verification results. Initializing the checksum calculator provides the algorithm basis for the subsequent "check-while-receiving" process, avoiding the time waste caused by initialization after receiving is completed; For example, when receiving a compound pump data packet, each time a byte is received, current_crc = crc32_update(current_crc, byte) is called until the remaining byte payload is received. Finally, current_crc is compared with the packet header checksum field to verify data integrity; The specific steps to establish a SOCKET connection and bind a segment buffer are: Call SOCKET API to create a socket; Bind the local address and port and listen for connection requests; Associate the segment buffer list pointer with the SOCKET receiving function, such as a custom receiving callback function, and specify the data to be written into the segment node; Traditional SOCKET receive functions write data into continuous memory by default, requiring secondary development to adapt to the segmented structure. By customizing the receive logic, data can be written directly into the segmented nodes, avoiding the time waste caused by copying data after receiving. The SOCKET receiving callback function can determine the remaining space of the current node in real time, automatically create a new node and append it, and realize the seamless connection between data reception and segment management; For example, after the host computer obtains the compound pump connection through accept, it calls the custom segmented_recv function. This function detects that the remaining space of the first node is 1012 bytes. After receiving 1012 bytes, it creates a new Node2 and continues to receive the remaining data to ensure that the remaining byte load is completely stored in the segmented linked list.

[0021] Receive data through the socket and write it into the segment buffer, and calculate the CRC-32 checksum byte by byte synchronously; Write the data_ptr pointer position of the current segment node and start appending from the current valid length, where data_ptr is the physical starting address of the node data; After each write, update the node length value and calculate the remaining space: remaining = node capacity - length; If remaining==0, create a new segment node, link it to the end of the linked list through the next pointer, and set it as the new current node; When expanding a traditional continuous buffer, all data must be copied (O(n) complexity), while a segmented linked list only needs to create new nodes and link them (O(1) complexity); When data increases suddenly, segment nodes can be added on demand to avoid data loss caused by fixed buffer overflow; For example, the first node Node1 (1024 bytes) has received a 12-byte packet header, length = 12, and the remaining space is 1012 bytes. When receiving new data, it is written to the data_ptr+12 position of Node1. If it continues to receive 1012 bytes, remaining = 0, and a new Node2 (1024 bytes) is created. Node1.next = Node2, and the current node is switched to Node2. Every time a byte of data is received, the incremental CRC-32 function is called to calculate the checksum current_crc at that time. This function uses a table lookup method to quickly calculate based on the predefined CRC-32 polynomial and initial value, and saves current_crc in real time for subsequent comparison with the packet header checksum field; When the cumulative received data reaches the packet header length, the length field is parsed to obtain the number of payload bytes, and the extension amount is dynamically predicted based on the historical data packet length and the buffer is expanded; Accumulate the sum of the lengths of all segment nodes and determine whether it is greater than or equal to the header length. If so, parse the header from the first node: Read the big-endian length field and convert it to decimal L; Read the number field; Read the checksum field; The packet header is the only basis for parsing the data payload. It must be received completely before determining the amount of data L to be received later. This avoids memory waste or data loss caused by blind reception. Devices of different architectures have different byte orders. Big-endian (high-order bit first) ensures consistent parsing of the length field to avoid L value deviation caused by byte order errors. For example, after the segment linked list has received 12 bytes cumulatively, the parsed length field is 0x00002800 (10240 bytes), the packet number is 0x00000001, and the packet header checksum is 0x1A2B3C4D. The receiver clearly needs to receive a 10240-byte payload. Check whether the sliding window history array history_len records the lengths of the first 10 packets; Calculate the average historical length avg_L. If history_count < 10, only the recorded data is used for calculation; The predicted expansion is predict_len=max(L,avg_L×1.5), where predict_len needs to be rounded up to a multiple of 1024 bytes. The traditional solution has a fixed expansion of 1024 bytes, and receiving 10240 bytes requires 10 expansions; dynamic prediction can expand to predict_len in one go, effectively reducing the number of memory allocations and lowering system call overhead; For example, if the average length of the first 10 packets recorded in the history array is 8192 bytes and the current L = 10240, then predict_len = max(10240,8192×1.5) = 12288, which can be divided into 12×1024, and 12 segment nodes are allocated at one time to ensure that 10240 bytes of payload can be accommodated; Continue to receive data until the payload length requirement is met, and verify the data integrity in real time; Calculate the total data length of the current segment linked list: current_total = the sum of the lengths of each node; If current_total < L, expand and receive according to the following rules: If the predicted extension amount predict_len does not reach the current total length, add a new segment node according to predict_len; Call the SOCKET receive function and write the data into the segment linked list until current_total ≥ L; New nodes do not rely on continuous memory. For example, when system memory is fragmented, multiple small nodes can still be allocated and spliced ​​together, solving the problem of failure of continuous memory expansion in scenarios such as embedded devices. Based on the difference between L and current_total, only necessary data is received to avoid memory waste caused by excessive reception; For example, the current total length of the segment linked list is 12 bytes (packet header), the data volume L is 10240, and the predicted expansion volume is 12288 bytes (12 nodes need to be expanded). After adding 11 nodes, data is continuously received until the total length reaches 10240 bytes. At this time, the segment linked list contains 12 nodes, the first 10240 bytes are the effective load, and the remaining 2048 bytes are reserved for subsequent data packets.

[0022] Obtain the payload start offset based on the total data length current_total of the segment linked list and the packet header analysis; According to the packet header parsing result, calculate the starting offset of the payload in the linked list, load_offset. For example, if the packet header is fixed at 12 bytes, then load_offset = 12, that is, the 13th byte after the packet header is the starting point of the payload; When traversing the linked list, when current_total ≥ load_offset, determine the node where the load starts and the offset within the node; The packet header and payload may be stored across nodes in the segmented linked list. Therefore, the payload offset within the node must be accurately calculated to avoid misjudgment of the payload starting position due to segmented storage. Find the node curr_node where the load starts, and calculate the local offset local_offset = load_offset - current_total within the node; The load end position is load_offset+L. Similarly, the node and local offset where the load ends are determined to form the load area [data_ptr+local_offset, data_ptr+local_offset+L]. The pointer offset directly maps to the physical memory address, avoiding data movement and achieving zero copy. At the same time, after the area is determined, the application layer can directly access the payload data through the pointer; For example, the packet header is 12 bytes and is stored in node 1 (10 bytes) and node 2 (2 bytes). Then load_offset=12 means that the starting position of the load data is after the end of the packet header, that is, after the total length of the packet header is 12 bytes. At this time, traverse node 1, the cumulative length current_total=10, which is less than 12. Continue to traverse node 2, the length of node 2=2, and after accumulation, current_total=10+2=12, which is exactly equal to load_offset. It is determined that the load starts in node 2. The offset in node 2 = load_offset-the cumulative length of the previous node = 12-10=2 bytes. Since the data_ptr of node 2 points to its data starting address, such as 0x2000, data_ptr+2 is the actual starting address of the load data: 0x2000+2=0x2002, where data_ptr represents the physical starting address pointer of the actual stored data in the segment node. Construct a descriptor containing a segment node pointer and an offset within the node, and locate the payload data area through the descriptor; Create a descriptor structure to record the location information of the payload in the segment linked list, including: payload start node, offset within the start node, total payload length, and payload end node; The descriptor is passed to the application layer, and the application layer accesses the data by traversing the nodes and offsets associated with the descriptor; The application layer reads data directly through pointer offsets based on the descriptor without memory copying; If you need to pass it to other modules, pass the descriptor directly instead of a copy of the data; Traditional solutions require copying segmented data to a continuous buffer. Descriptors can reduce CPU usage, and all modules access the same physical memory, avoiding the inconsistency problem of multiple copies caused by copying.

[0023] If the verification passes, it is delivered to the upper layer. If it fails, the error segment offset is located and accurate retransmission is requested. The above steps are repeated until the connection is closed. At the sending end, a CRC-32 checksum is calculated for each segment node and appended to the segment header; After receiving the segment, the receiver immediately calculates the CRC-32 checksum of the data part and compares the calculated value with the checksum carried in the segment header. If they do not match, the segment is marked as an error. Real-time verification can quickly detect errors and reduce invalid data processing; Maintain a list of error segments, recording the number and checksum of the error segment; Periodically send NAK packets to the sender to report the error segment number; Centralized management of error segments avoids duplicate detection, and the NAK mechanism is more efficient than ACK, reducing the number of confirmation packets and only reporting error segments. The sender maintains a cache of sent segments. After receiving a NAK, it extracts the corresponding segment from the cache and resends it with the same segment number and checksum. After receiving the retransmitted segment, the receiver verifies the CRC-32 checksum. If the check passes, the receiver replaces the original erroneous segment with the new segment and updates the data pointer in the segment list. After all segments are received, the overall CRC-32 checksum is calculated for the integrated complete data and compared with the global checksum provided in advance by the sender; Segment-level verification may miss boundary errors, such as errors at segment splicing. Global verification ensures end-to-end consistency of the final data.

[0024] Some of the data in the above formulas are dimensionless and numerically calculated. Meanwhile, the contents not described in detail in this specification belong to the prior art known to those skilled in the art.

[0025] The above embodiments are only used to illustrate the technical method of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical method of the present invention may be modified or replaced by equivalents without departing from the spirit and scope of the technical method of the present invention.

Claims

1. A method for receiving data packets of variable length via SOCKET communication, characterized in that: The following steps are involved: S1. Establish a custom communication protocol between the transmitting end and the receiving end, wherein the protocol includes a data packet header and a data payload, wherein the data packet header specifically includes a length field, a number field, and a CRC-32 checksum field; S2, the sending end encapsulates the data according to the protocol, fills the length field, assigns a number, calculates the CRC-32 checksum and sends it through the socket; S3. The receiving end creates a bidirectional linked list segment buffer, initializes the first node, temporary segment pointer, sliding window history array, and CRC-32 checksum calculator, establishes a socket connection, and binds the segment buffer. S4. Obtain received data and write it into a segment buffer. Synchronously calculate the CRC-32 checksum byte by byte. When the cumulative received data reaches the packet header length, parse the length field to obtain the number of payload bytes. Dynamically predict the extension amount based on the historical packet length and expand the buffer. S5, based on the total data length of the segment linked list and the packet header parsing to obtain the payload start offset, construct a descriptor containing the segment node pointer and the node offset; S6. If the verification passes, it is delivered to the upper layer. If it fails, the offset of the error segment is located and accurate retransmission is requested. The above steps are repeated until the connection is closed.

2. The method for receiving a data packet of variable length via SOCKET communication according to claim 1, wherein: The content of the first node initialization is: allocate the first segment node memory, the default size is set to 1024 bytes; initialize the node attributes, data_ptr points to the allocated memory address, the valid data length length is set to 0, and the next pointer points to null; set the first node as the current working node; The content of the temporary segment pointer temp_ptr is as follows: defining a temp_ptr pointer structure, including the starting segment node segment_ptr pointing to the unparsed remaining data, the byte offset offset in the starting node, and the remaining data length remaining_len; initially, segment_ptr is set to NULL, offset is set to 0, and remaining_len is set to 0; The content of the sliding window history array initialization is: create an unsigned integer array history_len[10] with a length of 10, initialize the array elements to 0, set the current write index window_index to 0, and the number of recorded packets window_count to 0; The contents of the CRC-32 checksum calculator initialization are: defining a CRC-32 checksum variable current_crc, setting the initial value to 0xFFFFFFFF, and loading a CRC-32 polynomial table.

3. The method for receiving a data packet of variable length via SOCKET communication according to claim 1, wherein: The specific steps for receiving and writing data are: Write the data_ptr pointer position of the current segment node and start appending from the current valid length, where data_ptr is the physical starting address of the node data; After each write, the node length value is updated and the remaining space is calculated according to the formula: remaining = node capacity - length; If remaining==0, create a new segment node, link it to the end of the linked list through the next pointer, and set it as the new current node; Every time 1 byte of data is received, the incremental CRC-32 function is called to calculate the checksum current_crc at that time. The CRC-32 function is based on the predefined CRC-32 polynomial and the initial value, and quickly calculates by table lookup method and saves current_crc in real time.

4. The method for receiving a data packet of indefinite length via SOCKET communication according to claim 1, wherein: The specific steps for dynamically predicting the extension amount based on the historical data packet length are as follows: Parse the packet header length field L; Check whether the sliding window history array history_len records the lengths of the first 10 packets; Calculate the average historical length avg_L. If history_count < 10, only the recorded data is used for calculation; The predicted expansion amount is calculated according to the formula predict_len = max(L,avg_L×1.5). The final predicted_len needs to be rounded up to a multiple of 1024 bytes.

5. The method for receiving a data packet of indefinite length via SOCKET communication according to claim 4, wherein: The total data length of the current segment list is calculated using the formula current_total=sum(length of each node). If current_total < L, the data is expanded and received according to the following rules: If the predicted extension amount predict_len does not reach the current total length, add a new segment node according to predict_len; Call the SOCKET receive function and write the data into the segment linked list until current_total ≥ L, where sum() is the summation function.

6. The method for receiving a data packet of indefinite length via SOCKET communication according to claim 1, wherein: The specific steps to locate the load area are: According to the packet header parsing result, calculate the starting offset of the load in the linked list load_offset; Traverse the linked list. When current_total ≥ load_offset, find the node curr_node where the load starts. Calculate the local offset within the node according to the formula local_offset = load_offset - current_total. The load end position is obtained as load_offset+L, forming the load area [data_ptr+local_offset,data_ptr+local_offset+L].

7. The method for receiving a data packet of variable length via SOCKET communication according to claim 1, wherein: The descriptor specifically includes a payload start node, an offset within the start node, a total payload length, and a payload end node.

8. The method for receiving a data packet of indefinite length via SOCKET communication according to claim 1, wherein: The descriptor is passed to the application layer, and the application layer reads data directly through the pointer offset according to the descriptor. If it needs to be passed to other modules, the descriptor can also be passed directly.

9. The method for receiving a data packet of indefinite length via SOCKET communication according to claim 1, wherein: The specific steps for data verification and accurate retransmission are: The sender calculates the CRC-32 checksum for each segment node and appends it to the header; After receiving the segment, the receiver immediately calculates the CRC-32 checksum of the data part and compares it with the checksum carried in the segment header. If they do not match, the segment is marked as an error. Periodically send NAK packets to the sender to report the error segment number; After receiving the NAK, the sender extracts the corresponding segment from the cache and resends it with the same segment number and checksum. After receiving the retransmitted segment, the receiver verifies the CRC-32 checksum. If the check passes, the receiver replaces the original erroneous segment with the new segment and updates the data pointer in the segment list.

10. The method for receiving a data packet of variable length via SOCKET communication according to claim 1, wherein: After all segments are received, the overall CRC-32 checksum needs to be calculated for the integrated complete data and compared with the global checksum provided in advance by the sender.

Images