Network status-based smart terminal with screen diagnosis data processing method and system

Abstract

The application discloses a network state-based screen-equipped intelligent terminal diagnosis data processing method and system, and relates to the technical field of data processing.The method comprises the following steps: calculating a confirmation byte rate according to a cumulative confirmation load position and a confirmation duration returned after a server completes persistent writing; determining a rate correction value according to a current rate difference value and a previous rate difference value of adjacent confirmation byte rates, and then obtaining a predicted confirmation byte number; and determining a next confirmation cycle sending byte number in combination with a remaining diagnosis data byte number.The application solves the problem that the sending byte number does not correspond to the actual persistent processing progress when the network and server processing state continuously changes, adjusts the sending amount according to the application layer confirmation rate change, and reduces the accumulation of pending confirmation diagnosis data.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and specifically to a method and system for processing diagnostic data of a smart terminal with a screen based on network status. Background Technology

[0002] Smart terminals with screens continuously generate display interaction diagnostic data and terminal operation diagnostic data during operation. To support remote fault location and operational status analysis, the terminal typically needs to upload diagnostic data to a diagnostic data server via wireless network, mobile communication network, or wired network. Diagnostic data is characterized by continuous generation, data volume varying with operational status, and the upload process potentially spanning multiple network status stages. Furthermore, network transmission capacity, server digest verification speed, and persistent write speed may continuously change during the upload process.

[0003] Existing technologies typically employ a fixed number of bytes sent, or adjust the number of bytes sent based on wireless signal strength, network type, and historical average transmission rate. However, wireless signal strength and network type primarily reflect the physical connection status on the terminal side and cannot directly indicate the amount of diagnostic data that the diagnostic data server has completed digest verification and persistent writing within the current upload cycle. Confirmations returned by the transmission protocol usually only indicate that the data has reached the corresponding protocol processing layer, and cannot be equated to the diagnostic data content having completed application layer processing. If such parameters are used as the primary basis for the number of bytes sent, the measurement object used by the sending side is inconsistent with the data object actually processed by the receiving side.

[0004] Furthermore, the historical average transmission rate smooths out data across multiple upload cycles. When the actual processing rate of the diagnostic data server continuously decreases, and the decrease in adjacent upload cycles continues to increase, the historical average may still remain at a relatively high level, making it difficult to reflect recent changes in a timely manner. For example, the terminal's network interface and routing may remain unchanged, but due to storage access contention, the amount of data persisted in each adjacent upload cycle decreases sequentially. In this case, if the terminal continues to send data at a fixed number of bytes or at an average rate that includes earlier high-speed phases, the amount of data sent in the next upload cycle may exceed the amount of data the server can process simultaneously. This results in a continuous increase in diagnostic data that has been sent but has not yet received application layer confirmation, further consuming the terminal's send buffer, network transmission resources, and the server's receive buffer.

[0005] Therefore, the core problem in existing diagnostic data uploading technology is that when the network and server processing status changes continuously, it is difficult to determine the number of bytes to be sent in the next confirmation cycle based on the amount of data actually persisted and written by the diagnostic data server recently and its changing trend. This makes it easy for the number of bytes sent to not correspond to the actual confirmation processing capacity of the receiving side. Summary of the Invention

[0006] This invention provides a method and system for processing diagnostic data of a smart terminal with a screen based on network status, which solves the problem that when the processing status of the network and the diagnostic data server changes continuously, the number of bytes sent in the next confirmation cycle is difficult to correspond to the diagnostic data processing capability of the diagnostic data server that has recently completed persistent writing.

[0007] This invention provides a method for processing diagnostic data of a smart terminal with a screen based on network status. The method includes: acquiring diagnostic data to be sent; subtracting the starting cumulative confirmation load position from the end cumulative confirmation load position of the confirmation period to obtain the number of confirmation load bytes; dividing the number of confirmation load bytes by the current confirmation duration to obtain the confirmation byte rate; sequentially assembling the confirmation byte rates of each confirmation period into a confirmation byte rate sequence; subtracting the previous term from the last term of the confirmation byte rate sequence to obtain the current rate difference; subtracting the term before that from the previous term to obtain the previous rate difference; determining a rate correction value based on the current rate difference and the previous rate difference: when both are negative and the former is less than the latter, the sum of the former and the difference between the two is taken; in other cases where the former is negative, the former is taken; when the former is non-negative, 0 is taken; adding the last term to the rate correction value and setting the negative value to 0, to obtain a candidate confirmation byte rate; obtaining the expected number of confirmation bytes based on the candidate confirmation byte rate and the current confirmation duration; obtaining the remaining number of diagnostic data bytes of the diagnostic data to be sent; taking the smaller value between the expected number of confirmation bytes and the remaining number of diagnostic data bytes to obtain the number of bytes to be sent in the next confirmation period; and transmitting the diagnostic data to be sent according to the number of bytes to be sent in the next confirmation period.

[0008] Optionally, acquiring the diagnostic data to be sent includes: collecting display interaction diagnostic data; collecting terminal operation diagnostic data; merging and sorting the display interaction diagnostic data and terminal operation diagnostic data according to their respective data generation time and local record sequence number to obtain a diagnostic data sorting result; converting and sequentially concatenating the diagnostic data sorting result to obtain a diagnostic data byte sequence; and determining the diagnostic data byte sequence as the diagnostic data to be sent.

[0009] Optionally, the number of acknowledgment payload bytes is obtained by subtracting the starting cumulative acknowledgment payload position from the ending cumulative acknowledgment payload position, including: obtaining candidate cumulative acknowledgment payload positions based on the diagnostic data content that has been continuously persisted; discarding candidate cumulative acknowledgment payload positions when they are less than the starting cumulative acknowledgment payload position; obtaining the maximum end position of the sent diagnostic data; comparing the candidate cumulative acknowledgment payload positions with the maximum end position of the sent diagnostic data to obtain the sent boundary verification result; when the sent boundary verification result indicates that the candidate cumulative acknowledgment payload position has not exceeded the maximum end position of the sent diagnostic data, the candidate cumulative acknowledgment payload position is determined as the ending cumulative acknowledgment payload position.

[0010] Optionally, the acknowledgment byte rate is obtained by dividing the number of acknowledgment payload bytes by the current acknowledgment duration, including: reading a monotonic clock before the first byte of the diagnostic data transmission segment is committed to obtain the transmission time; reading the same monotonic clock after the corresponding acknowledgment message is received to obtain the acknowledgment reception time; subtracting the transmission time from the acknowledgment reception time to obtain the candidate acknowledgment duration; reading the clock resolution of the monotonic clock; comparing the candidate acknowledgment duration and the clock resolution to obtain a duration comparison result; when the duration comparison result indicates that the candidate acknowledgment duration is greater than the clock resolution, the candidate acknowledgment duration is determined as the current acknowledgment duration; and dividing the number of acknowledgment payload bytes by the current acknowledgment duration to obtain the acknowledgment byte rate.

[0011] Optionally, forming an acknowledgment byte rate sequence includes: querying the current destination route of the diagnostic data server to obtain the egress network interface index; querying the current destination route to obtain the next-hop address of the route; comparing the current egress network interface index with the previous egress network interface index to obtain an interface index comparison result; if the interface index comparison result indicates a difference, clearing the acknowledgment byte rate sequence; if the interface index comparison result indicates a similarity, comparing the current route next-hop address with the previous route next-hop address to obtain a next-hop address comparison result; if the next-hop address comparison result indicates a difference, clearing the acknowledgment byte rate sequence; if the next-hop address comparison result indicates a similarity, adding the newly obtained acknowledgment byte rate to the acknowledgment byte rate sequence.

[0012] Optionally, the candidate acknowledgment byte rate is obtained by adding the terminal term to the rate correction value and setting the negative value to 0; the expected number of acknowledgment bytes is obtained based on the candidate acknowledgment byte rate and the current acknowledgment duration, including: adding the terminal term to the rate correction value to obtain the initial candidate acknowledgment byte rate; when the initial candidate acknowledgment byte rate is negative, the candidate acknowledgment byte rate is determined to be 0; when the initial candidate acknowledgment byte rate is non-negative, the initial candidate acknowledgment byte rate is determined as the candidate acknowledgment byte rate; the original expected number of acknowledgment bytes is obtained based on the candidate acknowledgment byte rate and the current acknowledgment duration; and the non-integer part of the original expected number of acknowledgment bytes is discarded.

[0013] Optionally, obtaining the remaining number of diagnostic data bytes and the number of bytes to be sent in the next confirmation cycle includes: obtaining the total number of diagnostic data bytes to be sent; subtracting the end of the cumulative confirmation payload position from the total number of diagnostic data bytes to obtain the remaining number of diagnostic data bytes; taking the smaller value between the expected number of confirmation bytes and the remaining number of diagnostic data bytes to obtain the number of bytes to be sent in the next confirmation cycle; when the number of bytes to be sent in the next confirmation cycle is 0 and the remaining number of diagnostic data bytes is positive, obtaining the upper limit of the network interface payload in bytes; taking the smaller value between the upper limit of the network interface payload in bytes and the remaining number of diagnostic data bytes to obtain the number of probe bytes to be sent; and transmitting the diagnostic data to be sent according to the number of probe bytes to be sent.

[0014] Optionally, transmitting the diagnostic data to be sent according to the number of bytes to be sent in the next confirmation cycle includes: generating an upload task identifier; obtaining diagnostic data content based on the number of bytes to be sent in the next confirmation cycle and the diagnostic data to be sent; generating a digest value based on the diagnostic data content; determining the end of the cumulative confirmation payload position as the start payload position; generating a send segment header based on the upload task identifier and the start payload position; generating a send segment payload based on the diagnostic data content and the digest value; generating a diagnostic data send segment based on the send segment header and the send segment payload; and transmitting the diagnostic data send segment.

[0015] Optionally, the diagnostic data transmission segment includes: receiving diagnostic data content from the diagnostic data transmission segment to obtain received diagnostic data content; receiving a digest value from the diagnostic data transmission segment to obtain a received digest value; generating a check digest value based on the received diagnostic data content; comparing the check digest value with the received digest value to obtain a digest comparison result; when the digest comparison result indicates consistency, obtaining the transmission segment load position range based on the starting load position of the diagnostic data transmission segment and the length of the received diagnostic data content.

[0016] Optionally, when the summary comparison results indicate consistency, processing is performed based on the transmit segment payload position interval and the current cumulative confirmed payload position, including: if the end position of the transmit segment payload position interval does not exceed the current cumulative confirmed payload position, the continuous diagnostic data content to be persistently written is determined to be empty; if the transmit segment payload position interval covers the current cumulative confirmed payload position, the suffix starting from the current cumulative confirmed payload position is extracted to obtain the continuous diagnostic data content to be persistently written; the non-empty continuous diagnostic data content to be persistently written is persistently written to obtain the updated cumulative confirmed payload position; and an acknowledgment message is generated based on the upload task identifier and the updated cumulative confirmed payload position.

[0017] Optionally, obtaining the acknowledgment byte rate based on the number of acknowledgment payload bytes and the current acknowledgment duration further includes: when the transport protocol stack returns a timeout code, determining the starting cumulative acknowledgment payload position as the ending cumulative acknowledgment payload position; obtaining the actual waiting time based on the monotonic clock readings before and after the timeout; comparing the actual waiting time with the clock resolution to obtain a waiting time comparison result; when the waiting time comparison result indicates that the actual waiting time is greater than the clock resolution, determining the actual waiting time as the current acknowledgment duration; the first valid acknowledgment message after the timeout is only used to synchronize the current cumulative acknowledgment payload position and does not generate an acknowledgment byte rate; after synchronization is completed, generating and transmitting a probe diagnostic data transmission segment according to the number of probe transmission bytes; obtaining a new acknowledgment byte rate based on the number of acknowledgment payload bytes and the acknowledgment duration corresponding to the probe diagnostic data transmission segment.

[0018] A network-state-based diagnostic data processing system for smart terminals with screens is also provided. This system implements a network-state-based diagnostic data processing method for smart terminals with screens. The system includes a terminal diagnostic data processing device and a diagnostic data server. The terminal diagnostic data processing device includes a diagnostic data generator and a transmission controller. The transmission controller includes an acknowledgment rate calculator and a byte-to-send calculator. The diagnostic data generator acquires diagnostic data to be sent. The acknowledgment rate calculator forms an acknowledgment byte rate sequence. The byte-to-send calculator obtains the number of bytes to be sent in the next acknowledgment cycle. The transmission controller generates and transmits a diagnostic data transmission segment based on the byte-to-send number in the next acknowledgment cycle and the diagnostic data to be sent. The diagnostic data server persists the diagnostic data content written into the diagnostic data transmission segment, obtaining the updated cumulative acknowledgment payload position. The diagnostic data server also generates an acknowledgment message based on the updated cumulative acknowledgment payload position.

[0019] The beneficial effects of this invention are reflected in: This invention uses the cumulative acknowledgment payload position returned by the diagnostic data server after completing digest verification and persistent writing as the application layer acknowledgment basis. The number of acknowledgment payload bytes is obtained from adjacent cumulative acknowledgment payload positions, and the acknowledgment byte rate is obtained by combining this with the acknowledgment duration measured by the same monotonic clock. Since the cumulative acknowledgment payload position only advances with the continuously persistent writing of diagnostic data, the acknowledgment byte rate corresponds to the actual amount of diagnostic data processed by the diagnostic data server, rather than just the amount of data entering the transport protocol stack, receive buffer, or page cache. This unifies the statistical objects for the number of acknowledgment payload bytes, the remaining number of diagnostic data bytes, and the number of bytes sent, improving the correspondence between the transmission control basis and the actual processing progress on the receiving side.

[0020] This invention further forms an acknowledgment byte rate sequence according to the acknowledgment cycle order. It obtains the current rate difference and the previous rate difference based on the adjacent acknowledgment byte rates at the end of the sequence, and determines a rate correction value based on the sign of the two rate differences and their further changes. When the acknowledgment byte rate continuously decreases and the current decrease value continues to increase, the candidate acknowledgment byte rates are simultaneously narrowed using the current decrease value and its further changes; in other decreasing scenarios, the current decrease value is continued; and when the acknowledgment byte rate does not decrease, the increasing value is not extrapolated. This process directly utilizes adjacent acknowledgment results, without relying on manually assigned network levels, empirical weights, or wireless signal thresholds, thus enabling a more timely distinction between general decreases and accelerated decreases.

[0021] After obtaining the candidate acknowledgment byte rate, this invention determines the expected number of acknowledgment bytes based on the current acknowledgment duration and limits the number of bytes sent in the next acknowledgment cycle to the number of remaining diagnostic data bytes, while limiting negative candidate acknowledgment byte rates to 0. These processes ensure that the number of bytes sent will not become negative or exceed the remaining range of diagnostic data to be sent. As the actual processing rate on the receiving side continuously decreases, the number of bytes sent in the next acknowledgment cycle can shrink accordingly with the application layer acknowledgment process, thereby reducing the continuous accumulation of diagnostic data that has been sent but not yet persisted, making the diagnostic data sending process more adaptable to continuous changes in network transmission and server processing status. Attached Figure Description

[0022] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0023] Figure 1 This is a schematic diagram illustrating the steps of the network status-based diagnostic data processing method for smart terminals with screens according to the present invention. Figure 2 This is a schematic diagram of some steps in S1 of the network status-based diagnostic data processing method for smart terminals with screens according to the present invention. Figure 3 This is a schematic diagram of some steps in step S2 of the network status-based diagnostic data processing method for smart terminals with screens according to the present invention. Figure 4 This is a schematic diagram of some steps in S3 of the network status-based diagnostic data processing method for smart terminals with screens in this invention. Figure 5 This is a schematic diagram of part of step S4 in the network status-based diagnostic data processing method for smart terminals with screens of the present invention; Figure 6This is a schematic diagram of the module structure and data flow of the network status-based diagnostic data processing system for smart terminals with screens according to the present invention. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0025] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0026] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0027] This invention provides a method for processing diagnostic data of a smart terminal with a screen based on network status, such as... Figure 1 As shown, in one embodiment, the method includes: S1. Collect and display interactive diagnostic data and terminal operation diagnostic data, merge and sort them according to the data generation time and local record sequence number, and convert them into continuous bytes to obtain diagnostic data to be sent; obtain the number of confirmed load bytes according to the positions of two adjacent valid cumulative confirmed loads, obtain the confirmed byte rate according to the number of confirmed load bytes and the confirmation duration in the same confirmation cycle, and form a confirmed byte rate sequence according to the confirmation cycle order; S2. When the egress network interface index and the next-hop address of the route have not changed, obtain the current acknowledgment byte rate, the previous acknowledgment byte rate and the previous acknowledgment byte rate from the end of the acknowledgment byte rate sequence. Obtain the current rate difference and the previous rate difference based on the adjacent acknowledgment byte rates. Obtain the rate correction value based on the current rate difference, the previous rate difference and the difference between the two. S3. Add the current acknowledgment byte rate to the rate correction value and limit the negative value to 0 to obtain the candidate acknowledgment byte rate; obtain the expected number of acknowledgment bytes based on the candidate acknowledgment byte rate and the current acknowledgment duration; obtain the remaining number of diagnostic data bytes based on the total number of diagnostic data bytes and the current cumulative acknowledgment payload position; and obtain the number of bytes to be sent in the next acknowledgment cycle based on the expected number of acknowledgment bytes and the remaining number of diagnostic data bytes. S4. According to the number of bytes sent in the next confirmation cycle, extract continuous diagnostic data content starting from the current cumulative confirmation payload position, generate and transmit the diagnostic data sending segment; after the digest verification is passed, the diagnostic data server completes the persistent writing of the continuous diagnostic data content starting from the current cumulative confirmation payload position, updates the cumulative confirmation payload position and returns an confirmation message, so that the updated cumulative confirmation payload position enters the calculation of the number of confirmation payload bytes in the next confirmation cycle.

[0028] Among them, a smart terminal with a screen refers to an electronic device that has a display screen, processor, memory, operating system, and network communication interface, and is capable of generating display interaction diagnostic data and terminal operation diagnostic data. Display interaction diagnostic data refers to diagnostic records generated by display interaction processes such as touch, button presses, window switching, display refresh, and display anomalies. Terminal operation diagnostic data refers to diagnostic records generated by terminal operation processes such as processor operation, memory usage, storage access, task scheduling, and anomaly handling.

[0029] The acknowledgment period refers to the time from the start of reading the diagnostic data transmission segment until the acknowledgment message matching that segment is fully received and passes the task identifier verification. If the transport protocol stack returns a timeout error, the acknowledgment period ends when the timeout error occurs. The transmission time is read before the first byte of the diagnostic data transmission segment is submitted to the transport protocol stack to avoid underestimating the acknowledgment duration if some data from a large application layer data frame is prematurely sent during multiple writes to the transport buffer.

[0030] Specifically, the diagnostic data transmission segment is an application-layer data frame as defined in this method, not the maximum TCP segment size. A diagnostic data transmission segment can be split into multiple transport-layer messages and multiple network-layer packets by the transport protocol stack. The number of bytes sent in the next acknowledgment cycle indicates the length of the diagnostic data content in an application-layer diagnostic data transmission segment, not the data length of a single link-layer frame or a single TCP segment. The maximum number of bytes for the network interface payload is only used to generate small probe diagnostic data transmission segments required for recovery rate measurement.

[0031] Furthermore, the cumulative confirmed payload position refers to the exclusive end position of the diagnostic data content that has continuously completed digest verification and persistent writing, starting from the upload start position. For example, the cumulative confirmed payload position is 3.2 × 10 5byte, representing the first 3.2 × 10 bytes starting from the upload start position. 5 The byte diagnostic data has been continuously persisted, and the next unacknowledged byte starts from this position. Using an exclusive end position allows the number of newly acknowledged bytes to be obtained by directly subtracting adjacent cumulative acknowledged payload positions, avoiding boundary errors caused by repeatedly incrementing the end byte of the interval.

[0032] The acknowledgment payload bytes refer to the number of diagnostic data bytes added to the acknowledgment payload position within a acknowledgment period. The acknowledgment duration refers to the monotonic clock reading difference between the transmission time of the diagnostic data transmission segment and the acknowledgment reception time of the matching acknowledgment message. The acknowledgment byte rate refers to the byte processing rate of the acknowledgment payload bytes relative to the acknowledgment duration within the same acknowledgment period. The current acknowledgment byte rate, the previous acknowledgment byte rate, and the previous-previous acknowledgment byte rate represent the end, the term preceding the end, and the two terms preceding the end of the acknowledgment byte rate sequence, respectively.

[0033] The current rate difference refers to the change in the current acknowledged byte rate relative to the previous acknowledged byte rate. The previous rate difference refers to the change in the previous acknowledged byte rate relative to the acknowledged byte rate before that. The rate correction value is a signed rate value obtained based on the current rate difference, the previous rate difference, and the difference between the two, and is used to correct the current acknowledged byte rate. The candidate acknowledged byte rate is the non-negative rate obtained after rate correction and limiting negative values ​​to 0.

[0034] Specifically, the expected number of acknowledgment bytes refers to the number of integer diagnostic data bytes corresponding to the candidate acknowledgment byte rate within the current acknowledgment duration. The remaining number of diagnostic data bytes refers to the number of diagnostic data bytes in the total number of diagnostic data bytes that have not yet been acknowledged through the cumulative acknowledgment payload position. The number of bytes to be sent in the next acknowledgment cycle refers to the number of diagnostic data bytes included in the next application layer diagnostic data transmission segment. The number of probe bytes to be sent refers to the number of small diagnostic data bytes used to recover the effective acknowledgment byte rate measurement when the number of bytes to be sent in the next acknowledgment cycle is 0 and there is still diagnostic data to be sent.

[0035] Specifically, this implementation uses diagnostic data content as a unified statistical object for the cumulative acknowledgment payload location, acknowledgment payload bytes, total diagnostic data bytes, remaining diagnostic data bytes, expected acknowledgment bytes, bytes to be sent in the next acknowledgment cycle, and probe bytes to be sent. The digest value, transmit segment header, acknowledgment message header, transport layer header, network layer header, and link layer header are not included in the aforementioned byte count, thereby avoiding the mixing of the application layer diagnostic data byte count with the total network packet byte count.

[0036] In this embodiment, it should be noted that in S1, both the displayed interactive diagnostic data and the terminal operation diagnostic data include at least the data generation time, record type, record content, and local record sequence number. The data generation time is used for merging and sorting, and the local record sequence number is used to determine a stable arrangement order when multiple diagnostic data have the same data generation time. Each sorted diagnostic data is converted into bytes according to a unified binary encoding rule and concatenated into diagnostic data to be sent according to the sorting result.

[0037] Furthermore, the diagnostic data server only advances the cumulative acknowledgment payload position after the digest verification passes and the corresponding diagnostic data content has been confirmed to be in persistent storage. Persistent storage refers to the completion of file writing and storage synchronization operations, or the successful commit of the database transaction. Data that only enters the network receive buffer, application process memory, or operating system page cache is not used to advance the cumulative acknowledgment payload position. The resulting acknowledgment byte rate simultaneously reflects the time consumed by network transmission, server-side digest verification, and persistent writing.

[0038] For example, the starting cumulative confirmed load position for a certain confirmation period is 3.0 × 10 5 This value comes from the previous valid acknowledgment message; the end of the cumulative acknowledgment payload position is 4.2 × 10. 5 This value comes from the acknowledgment message generated after the persistent write is completed in this acknowledgment cycle. The end of the cumulative acknowledgment payload position is increased by 1.2 × 10^6 bytes compared to the start of the cumulative acknowledgment payload position. 5 Therefore, the payload byte count is confirmed to be 1.2 × 10^6 bytes. 5 The acknowledgment duration, measured by a monotonic clock, is 0.4 seconds. Dividing the number of acknowledgment payload bytes by the acknowledgment duration yields an acknowledgment byte rate of 3.0 × 10^6 bytes. 5 byte / s.

[0039] The reason for adopting the above processing logic is that the transmission protocol confirmation can only indicate that the data has arrived at the corresponding protocol processing layer, and cannot directly indicate that the diagnostic data content has passed the application layer digest verification and been persistently written. This step uses the cumulative confirmation payload position at the application layer as the byte statistics basis and the difference in monotonic clock readings as the time statistics basis, so that the confirmation byte rate corresponds to the diagnostic data content actually processed by the diagnostic data server.

[0040] In S2, to address the issue that acknowledgment byte rates on different network paths cannot be directly grouped into adjacent samples, the terminal queries the operating system's routing table before the start of each acknowledgment cycle based on the destination address of the diagnostic data server to obtain the egress network interface index and the next-hop address. The egress network interface index is the index value assigned by the operating system to the network interface undertaking this transmission; the next-hop address is the gateway address pointed to by the current destination route. If the directly connected route does not have a gateway address, the diagnostic data server address is used as the next-hop address.

[0041] Specifically, when the egress network interface index or the next-hop address changes, the acknowledgment byte rate sequence used for difference calculation is cleared, and continuous samples are reacquired on the changed transmission path. The egress network interface index and the next-hop address are used to identify routing changes observable by the operating system, not to assert that every intermediate forwarding node in the Internet has remained unchanged. This limitation conforms to the range of information that the terminal can actually obtain through the regular routing interface.

[0042] Furthermore, when the network path identifier remains unchanged and the confirmed byte rate sequence already contains at least 3 valid samples, the last sample in the sequence is determined as the current confirmed byte rate, the preceding adjacent item is determined as the previous confirmed byte rate, and the two preceding adjacent items are determined as the even earlier confirmed byte rate. The current confirmed byte rate minus the previous confirmed byte rate yields the current rate difference, and the previous confirmed byte rate minus the even earlier confirmed byte rate yields the previous rate difference.

[0043] For example, the previous acknowledgment byte rate, the previous acknowledgment byte rate, and the current acknowledgment byte rate are respectively 6.0 × 10⁻⁶. 5 byte / s, 4.5×10 5 byte / s and 3.0×10 5 byte / s. The byte rate of the previous acknowledgment decreased by 1.5 × 10⁻⁶ compared to the byte rate of the acknowledgment before that. 5 In bytes / s, the current acknowledgment byte rate is also reduced by 1.5 × 10⁻⁶ compared to the previous acknowledgment byte rate. 5 byte / s, therefore the difference between the previous rate and the current rate is both -1.5 × 10^6 bytes / s. 5 The difference between the two is 0 bytes / s.

[0044] Furthermore, when both the current rate difference and the previous rate difference are negative, and the result of subtracting the previous rate difference from the current rate difference is still negative, the current rate difference is added to this result to obtain the rate correction value; when the current rate difference is negative but does not meet the aforementioned condition, the current rate difference is determined as the rate correction value; when the current rate difference is non-negative, the rate correction value is determined to be 0. This judgment covers both negative and non-negative states of the current rate difference, and there are no undefined branches.

[0045] The reason for adopting the above processing logic is that a single acknowledgment byte rate cannot distinguish whether the rate is decreasing, remaining stable, or increasing, nor can it distinguish whether the decreasing value continues to increase. Three consecutive acknowledgment byte rates can form two rate differences with a sequential relationship. Using the routing information available to the operating system as the basis for determining sequence continuity can reduce the possibility of misinterpreting rate abrupt changes caused by network interface switching or next-hop switching as continuous changes within the same path.

[0046] In S3, the terminal adds the current acknowledgment byte rate to the rate correction value to obtain the initial candidate acknowledgment byte rate. If the initial candidate acknowledgment byte rate is negative, it is set to 0; if it is non-negative, it is directly set as the candidate acknowledgment byte rate. The candidate acknowledgment byte rate and the current acknowledgment duration are used together to obtain the original estimated acknowledgment byte number. After discarding the non-integer part of the original estimated acknowledgment byte number, the estimated acknowledgment byte number is obtained.

[0047] Furthermore, the total number of bytes of diagnostic data is a non-negative integer obtained by counting the byte sequence length after all diagnostic records have been encoded and sequentially concatenated. The remaining number of bytes of diagnostic data is obtained by subtracting the current cumulative confirmed payload position from the total number of bytes of diagnostic data. If the expected number of confirmed bytes does not exceed the remaining number of bytes of diagnostic data, the expected number of confirmed bytes is determined as the number of bytes to be sent in the next confirmation cycle; if the expected number of confirmed bytes exceeds the remaining number of bytes of diagnostic data, the remaining number of bytes of diagnostic data is determined as the number of bytes to be sent in the next confirmation cycle.

[0048] For example, at the current acknowledgment byte rate of 3.0 × 10 5 The byte / s, current rate difference, and previous rate difference are all -1.5 × 10⁻⁶. 5 In the case of byte / s, the difference between the two rate differences is 0 byte / s, and the rate correction value is taken as the current rate difference. After correction, the candidate confirmed byte rate is 1.5 × 10^6 byte / s. 5 byte / s. With the current confirmation duration at 2.0 s, the estimated number of confirmed bytes is 3.0 × 10⁻⁶. 5 byte.

[0049] For example, the previous acknowledgment byte rate, the previous acknowledgment byte rate, and the current acknowledgment byte rate are respectively 6.0 × 10⁻⁶. 5 byte / s, 4.5×10 5 byte / s and 2.3×10 5 byte / s. Previous rate difference was -1.5 × 10⁻⁶. 5 byte / s, current rate difference is -2.2 × 10 5 The difference between the two is -0.7 × 10^6 bytes / s. 5 byte / s, therefore the rate correction is -2.9 × 10 5 byte / s. The current confirmed byte rate, after correction, is negative, and the candidate confirmed byte rate is limited to 0.

[0050] Specifically, when the number of bytes sent in the next confirmation cycle is 0 and the number of remaining diagnostic data bytes is positive, the terminal does not permanently stop transmission. Instead, it reads the maximum number of bytes for the network interface payload and takes the smaller value between the maximum number of bytes for the network interface payload and the number of remaining diagnostic data bytes as the number of bytes to send for probe. The probe diagnostic data sending segment still uses the normal task identifier, start payload position, digest check, and cumulative confirmation feedback process.

[0051] The reason for adopting the above processing logic is that negative candidate acknowledgment byte rates and negative number of bytes sent have no physical meaning, and sending more than the remaining diagnostic data range will cause out-of-bounds extraction. By limiting the candidate acknowledgment byte rate to a non-negative value, limiting the number of bytes sent in the next acknowledgment cycle to the remaining range, and performing limited probing when the normal number of bytes sent is 0, the problems of invalid byte counts and permanent loss of new rate samples can be avoided at the same time.

[0052] In S4, the terminal generates an upload task identifier for each upload and an incremental transmission segment sequence number for the diagnostic data transmission segment within the same upload task. The terminal uses the current cumulative acknowledged payload position as the starting payload position for the diagnostic data transmission segment and extracts continuous diagnostic data content from the diagnostic data to be transmitted according to the number of bytes sent or probed in the next acknowledgement cycle. The terminal generates a digest value based on the diagnostic data content, and constructs the transmission segment header by including the protocol version, total transmission segment length, upload task identifier, transmission segment sequence number, starting payload position, diagnostic data content length, digest algorithm identifier, and digest length.

[0053] Furthermore, the diagnostic data server generates a checksum value based on the received diagnostic data content and compares the checksum value with the received digest value byte by byte. If the digests do not match, persistent writing is not performed, and a failure response carrying the current cumulative acknowledgment payload position is returned. If the digests match, the transmit segment payload position range is determined based on the starting payload position and the length of the diagnostic data content.

[0054] Specifically, when the end position of the transmit segment load position interval does not exceed the current cumulative confirmed load position, the diagnostic data content is a duplicate that has already been persistently written and will not be written again; when the transmit segment load position interval covers the current cumulative confirmed load position, only the continuous diagnostic data content after the current cumulative confirmed load position is extracted; when the transmit segment load position interval starts after the current cumulative confirmed load position, it indicates that there is a data gap between the current cumulative confirmed load position and the transmit segment, and persistent writing will not be performed.

[0055] For example, the starting payload position of the diagnostic data transmission segment is 3.0 × 10 5 The diagnostic data content is 1.0 × 10 bytes long. 5 Therefore, the transmit segment payload location range is 4.0 × 10 bytes. 5 Ends at byte. The current cumulative confirmed payload position of the diagnostic data server is 3.2 × 10⁻⁶. 5 When dealing with bytes, the beginning of the interval already contains 2.0 × 10. 4 The byte has been persisted. The remaining 8.0 × 10 bytes of continuous diagnostic data are still pending persistence. 4 byte. After the persistent write is complete, the cumulative confirmed payload position is updated to 4.0 × 10. 5 byte.

[0056] The reason for adopting the above processing logic is that the loss of acknowledgment messages may lead to the retransmission of the same diagnostic data transmission segment, and connection restoration may also cause the old transmission segment to arrive with a delay. Based on the relationship between the transmission segment payload position interval and the current cumulative acknowledgment payload position, only writing continuous diagnostic data content immediately adjacent to the current cumulative acknowledgment payload position can avoid repeated persistent writing and also prevent the cumulative acknowledgment payload position from crossing the data gap that has not yet been received.

[0057] In summary, the entire network-state-based diagnostic data processing method for smart terminals with screens firstly obtains the number of confirmed payload bytes by using the cumulative confirmed payload position returned after digest verification and persistent writing, ensuring that the confirmed byte rate corresponds to the diagnostic data content actually processed by the diagnostic data server. Simultaneously, it obtains the current rate difference and the previous rate difference by using the continuous confirmed byte rates under the same transmission path identifier, enabling the identification of the current rate decrease and its change relative to the previous decrease. Further, it obtains a rate correction value based on the sign and direction of the two rate differences, further narrowing the candidate confirmed byte rate when the decrease continues to increase, continuing the current decrease in other decrease scenarios, and not extrapolating the increase when the confirmed byte rate does not decrease. This yields the expected number of confirmed bytes and the number of bytes to be sent in the next confirmation cycle. A closed loop is formed through probe sending, digest verification, continuous persistent writing, and cumulative confirmed feedback, ensuring consistent positional boundaries and continuous data processing during data transmission under actual conditions such as route changes, confirmed acknowledgment loss, repeated sending, and decreased processing rate.

[0058] In one implementation, such as Figure 2 As shown, S1 includes: S11. Collect and display interactive diagnostic data and terminal operation diagnostic data respectively, record the data generation time and local record number for each diagnostic data, merge and sort according to the data generation time and local record number, and convert them into diagnostic data byte sequence using a unified binary encoding rule.

[0059] S12. Generate an upload task identifier for this upload, obtain the upload start position from the diagnostic data server, determine the length of the diagnostic data byte sequence as the total number of diagnostic data bytes, and establish the correspondence between the upload task identifier, the upload start position, and the total number of diagnostic data bytes.

[0060] S13. Before the first byte of the diagnostic data transmission segment is submitted to the transport protocol stack, read the monotonic clock to obtain the transmission time; after the matching acknowledgment message is fully received and passes the identifier verification, read the same monotonic clock to obtain the acknowledgment reception time; obtain the candidate acknowledgment duration based on the two times, and verify the candidate acknowledgment duration using the monotonic clock resolution.

[0061] S14. Perform task identifier verification, position increment verification, and sent boundary verification on the candidate cumulative acknowledgment payload positions in the acknowledgment message. Obtain the number of acknowledgment payload bytes based on the adjacent cumulative acknowledgment payload positions that pass the verification, and obtain the acknowledgment byte rate based on the number of acknowledgment payload bytes and the acknowledgment duration.

[0062] In this embodiment, it should be noted that in S11, the entry point for collecting interactive diagnostic data is connected to the terminal display event distribution interface, and the entry point for collecting terminal operation diagnostic data is connected to the operating system performance statistics interface, task scheduling log interface, and exception log interface. The collection process only reads diagnostic events and operating status, without modifying the display control logic or task scheduling results. For example, the display event interface generates two pieces of interactive diagnostic data at 10.0 S and 10.4 S respectively, and the operation log interface generates one piece of terminal operation diagnostic data at 10.2 S; the aforementioned times all originate from the event timing interface within the same startup session, and after merging and sorting, the record order corresponds to 10.0 S, 10.2 S, and 10.4 S respectively.

[0063] The method for determining the data generation time is as follows: When a diagnostic event enters the data acquisition input, the terminal reads the monotonic clock, converts the clock reading into the number of integer nanoseconds elapsed since the device started, and stores it as an 8-byte unsigned integer. The integer nanosecond is only a unified storage unit for the data generation time and does not represent the actual resolution of the monotonic clock. The actual resolution of the monotonic clock is based on the reading result from the operating system's timing interface. When multiple events obtain the same time, they are sorted using the local record sequence number. For example, if the timing interface returns 10.0S, 10.2S, and 10.4S sequentially, the converted integer values ​​are only used for sorting data and not for confirming duration calculations. The conversion unit and field width are fixed by the protocol version, and the receiving end parses them according to the same rules.

[0064] Specifically, the local record sequence number starts from 1 each time the device starts up. A thread-safe atomic increment operation assigns a unique sequence number to each diagnostic record, incrementing by 1 for each new record generated. When the device restarts, a new startup session identifier is generated simultaneously. The order of entries is determined solely by the local record sequence number, without crossing startup sessions. For example, if two diagnostic records were generated at the same time, their local record sequence numbers would be 21 and 22 respectively. The record with sequence number 21 is sorted first. The starting value and increment rule are data format rules, not empirical thresholds for determining network status.

[0065] Furthermore, the unified binary encoding rule adopts length-prefix binary encoding. Each diagnostic record sequentially writes the record type, data generation time, local record number, record content length, and record content; the record type occupies 1 byte, the data generation time occupies 8 bytes, the local record number occupies 8 bytes, and the record content length occupies 4 bytes. Multi-byte integers adopt network byte order, and the record content is written continuously according to its length. For example, if a record has 120 bytes of content and fixed fields totaling 21 bytes, the encoded record length is 141 bytes. The field width is determined based on the representable range of a single diagnostic record and cross-platform parsing requirements; when the record content exceeds the representable range of the length field, it is split into multiple diagnostic records with consecutive local record numbers.

[0066] The record type value is determined by the diagnostic record type table. This table is stored in both the terminal program and the diagnostic data server using the same protocol version, with each type assigned a unique integer identifier. For example, display touch events, display refresh events, and task exception events can be assigned type identifiers 1, 2, and 3, respectively; these values ​​are only used to illustrate the mapping process. When adding a new record type, an unused identifier is selected from the type table, and a compatible parsing entry is added or the protocol version is updated simultaneously to prevent the same identifier from representing different content at both ends of the communication.

[0067] After obtaining the sorting results, the terminal concatenates the encoded diagnostic records sequentially according to the sorting order. The concatenation process first obtains the actual length of each encoded record, then allocates a byte storage area sufficient to hold all records, and subsequently copies the record bytes in record order and updates the write position. When using block storage, the logical starting position of each block is saved to ensure that the result extracted by position is consistent with the continuous byte sequence. For example, if the lengths of three encoded records are 141 bytes, 160 bytes, and 139 bytes respectively, the length of the concatenated diagnostic data byte sequence is 440 bytes, a value derived from the sum of the lengths of the three records.

[0068] In S12, the upload task identifier preferably uses a universally unique identifier conforming to version 4 rules, occupying 16 bytes, and its format can be found in RFC9562. The terminal generates random bits and sets version and variant bits through the operating system's cryptographic random number interface. After generation, it is compared with the task metadata still retained by the local task record and the diagnostic data server; if duplicates are found, a new one is generated. For example, if the terminal and server currently retain a total of 3 task identifiers, a new upload task record is only established if the newly generated 16-byte identifier is different from all the aforementioned task identifiers.

[0069] The upload start position is obtained through the persistent task metadata of the diagnostic data server. When a new upload task does not have the same upload task identifier, the upload start position is 0 bytes. When resuming an upload task, the diagnostic data server reads the positions of the already submitted cumulative confirmed payloads and returns them as the upload start position. For example, the task metadata displays the first 3.2 × 10 bytes. 5 The byte has been continuously persisted. After the terminal verifies that this position does not exceed the total number of bytes of diagnostic data, it starts from 3.2 × 10. 5 The byte continues to be uploaded. This position comes from the server's persistent records and is not estimated by the terminal or preset manually.

[0070] Furthermore, the total number of bytes in the diagnostic data is obtained through the actual length of the encoded diagnostic data byte sequence. When using block storage, the terminal reads the logical start position and actual byte length of the last block to obtain the length of the complete byte sequence; when using contiguous storage, the length of the byte container is read directly. The terminal also performs unsigned integer overflow checks on position addition; if the position or length exceeds the range that the field can represent, the upload task is stopped. For example, after encoding, the total number of bytes is 4.0 × 10. 6 The byte value represents the total number of bytes in the diagnostic data.

[0071] In S13, the monotonic clock is a timing source that increments unidirectionally during device operation and is unaffected by system date calibration. The terminal reads the transmission time before the first byte of the diagnostic data transmission segment enters the transmission process, and reads the acknowledgment reception time after all bytes of the acknowledgment message have been received and verified by the upload task identifier and transmission segment sequence number. When the diagnostic data transmission segment requires multiple calls to the transmission interface to write all data, the transmission time still uses the reading before the first write call, ensuring that the acknowledgment duration covers the entire application layer data frame submission and transmission process.

[0072] Specifically, the monotonic clock resolution is read directly from the operating system's timing interface, without using a manually set time threshold. The terminal reads it once when starting an upload task and rereads it whenever the operating system or timing source changes. For example, if the monotonic clock resolution read from the operating system's timing interface is 1ms, and the duration of a candidate acknowledgment is 0.4s (400ms), the candidate acknowledgment duration is greater than the clock resolution; therefore, 0.4s is determined as the acknowledgment duration. When the candidate acknowledgment duration is not greater than the clock resolution, the terminal can still process the cumulative acknowledgment payload position, but it does not use this time sample to calculate the acknowledgment byte rate.

[0073] Furthermore, the timeout status is determined by a connection timeout error or retransmission termination error returned by the transport protocol stack. This implementation does not superimpose a fixed acknowledgment time threshold unrelated to the protocol stack's retransmission mechanism. The transport protocol stack generates a timeout error based on the current connection's round-trip time estimate, retransmission timing, and connection status. The terminal records the actual waiting time between the transmission time and the timeout error return time, and uses the same monotonic clock resolution for verification. For example, if the transport protocol stack returns a timeout error after an actual wait of 8.0 seconds, and the monotonic clock resolution read through the operating system's timing interface is 1ms, the actual waiting time is greater than the monotonic clock resolution; therefore, 8.0 seconds is determined as the acknowledgment duration for this acknowledgment period.

[0074] Specifically, when a timeout occurs, the terminal temporarily sets the end of the current confirmation cycle's cumulative confirmation payload position to the previous cumulative confirmation payload position, making the confirmation payload byte count 0. If the diagnostic data has actually been persistently written but the confirmation message is lost, the first valid confirmation message after the timeout may carry the cumulative confirmation payload position spanning the timeout cycle. To avoid incorrectly including cross-cycle confirmation data in a single probe confirmation cycle, the first valid confirmation message is only used to synchronize the current cumulative confirmation payload position and does not generate an confirmation byte rate; only the next probe diagnostic data transmission segment sent after synchronization is completed is used to generate a new valid confirmation byte rate.

[0075] In S14, the task identifier check is used to confirm that the message belongs to the current upload task; the position increment check is used to confirm that the position of the candidate cumulative confirmed payload is not less than the position of the previous cumulative confirmed payload; and the sent boundary check is used to confirm that the position of the candidate cumulative confirmed payload is not greater than the maximum end position of the sent diagnostic data. The maximum end position of the sent diagnostic data is obtained from the start position and content length of each actual submitted diagnostic data, and is updated after the two are added together and pass the overflow check.

[0076] For example, the previously confirmed cumulative load location was 3.0 × 10 5 The candidate cumulative confirmed payload location is 4.2 × 10 bytes. 5 The maximum end position of the sent diagnostic data is 4.5 × 10 bytes. 5 The candidate position is checked against both incremental checksums and sent boundary checks. If the candidate cumulative acknowledgment payload position is less than the previous cumulative acknowledgment payload position, the acknowledgment message is identified as an expired message; if the candidate cumulative acknowledgment payload position is greater than the maximum end position of the sent diagnostic data, the acknowledgment message is identified as an out-of-bounds message.

[0077] Furthermore, the cumulative confirmed payload location, confirmed payload byte count, and transmitted byte count are stored using at least 64-bit unsigned integers; the rate difference and rate correction value are stored using signed numbers capable of representing negative values; and the confirmed byte rate is stored using floating-point or fixed-point numbers capable of storing non-integer results. The implementation program performs range checks before integer addition, subtraction, and type conversion. For example, the total number of diagnostic data bytes is 4.0 × 10⁻⁶. 6 The current cumulative confirmed payload locations are 2.7 × 10 bytes. 6 Both bytes are within the range of the selected integer type, and the difference can be safely stored as 1.3 × 10^6 bytes. 6 byte.

[0078] In one implementation, such as Figure 3 As shown, S2 includes: S21. Query the current destination route based on the diagnostic data server address, obtain the egress network interface index and the next-hop address of the route, and compare it with the corresponding value saved in the previous confirmation period.

[0079] S22. When the egress network interface index or the next-hop address of the route changes, the acknowledgment byte rate sequence is cleared; when neither of them changes, the newly acquired valid acknowledgment byte rate is added to the acknowledgment byte rate sequence.

[0080] S23. Obtain the current confirmed byte rate, the previous confirmed byte rate, and the previous confirmed byte rate from the end of the confirmed byte rate sequence, and obtain the current rate difference and the previous rate difference in sequence.

[0081] S24. Obtain the rate correction value based on the current rate difference, the previous rate difference, and the direction of change of the current rate difference relative to the previous rate difference.

[0082] In this embodiment, it should be noted that in S21, both the egress network interface index and the next-hop address are obtained through an actual route query performed by the operating system against the diagnostic data server address, rather than reading a static network type unrelated to the destination address. When a direct connection route does not have a gateway field, the diagnostic data server address is used as the next-hop address, ensuring that the comparison object always has a definite value.

[0083] For example, if the egress network interface index obtained in the previous acknowledgment cycle query was 7, and the current acknowledgment cycle query result is also 7, and both queries obtain the same next-hop address, then the acknowledgment byte rate sequence will continue to be retained. If the egress network interface index obtained in the current query becomes 12, and the value 12 comes from the index of the newly selected interface by the operating system, then even if the next-hop address remains unchanged, the original acknowledgment byte rate sequence will be cleared.

[0084] Furthermore, in S22, the acknowledgment byte rate sequence only accepts valid acknowledgment byte rates that have passed duration verification, position verification, and timeout synchronization. The minimum number of samples used for calculation in this algorithm is 3. This is because the current rate difference requires the current acknowledgment byte rate and the previous acknowledgment byte rate, and the previous rate difference requires the acknowledgment byte rate from the period before that. Therefore, fewer than 3 samples cannot form two adjacent rate differences. This number is directly determined by the computational relationship and is not a manually set statistical threshold.

[0085] Specifically, when the confirmed byte rate sequence has fewer than three valid samples, the terminal queries the most recently completed historical upload task whose diagnostic data server address, egress network interface index, and next-hop routing address are all identical to the current upload task. It reads the total number of valid bytes sent from this historical upload task and takes the middle value after sorting as the initial number of bytes to send. If the number of valid values ​​is even, the smaller of the two middle values ​​is taken to maintain a conservative sending rate. If no historical upload task meets the conditions, the upper limit of the network interface payload in bytes is used as the initial number of bytes to send. This method uses the actual data from the most recent finite historical task and no longer introduces historical window length, empirical weights, or manual network levels.

[0086] For example, the most recent historical upload task that met the path conditions contained 5 valid bytes sent, which were 7.0 × 10. 5 8.0×10 5 9.0×10 5 1.0×10 6 and 1.1×10 6 byte. The value 5 comes from the actual number of valid records saved in this historical task, not the preset sample threshold; the value in the middle position after sorting is 9.0 × 10. 5 Therefore, the initial number of bytes to send is 9.0 × 10. 5 byte. During the period when the current task generates the first 3 valid acknowledgment byte rate samples, the initial number of bytes to be sent is reused, provided that it does not exceed the number of remaining diagnostic data bytes.

[0087] In S23, the acknowledgment byte rate sequence is saved in the order of the end of the acknowledgment period. Each sample is simultaneously associated with the upload task identifier, acknowledgment period order, egress network interface index, and next-hop routing address. The terminal retains at least the last three valid samples in the sequence; earlier samples can be saved if historical changes need to be audited, but these earlier samples are not included in the current rate difference calculation. The current acknowledgment byte rate, the previous acknowledgment byte rate, and the acknowledgment byte rate before that all use the same byte and time statistical methods.

[0088] In S24, the branch decision for the rate correction value is obtained entirely from the current rate difference, the previous rate difference, and the difference between the two, without using weighting coefficients, network level thresholds, or manual scoring. When both the current rate difference and the previous rate difference are negative and the current decrease value further increases, the rate correction value includes both the current decrease value and the further change in the decrease value; when the current confirmed byte rate decreases but the decrease value does not further increase, the rate correction value only includes the current rate difference; when the current confirmed byte rate does not decrease, the rate correction value is 0.

[0089] For example, the previous rate difference was -1.5 × 10⁻⁶. 5 byte / s, current rate difference is -2.2 × 10 5 byte / s, the current rate difference has decreased by 0.7 × 10 compared to the previous rate difference. 5 byte / s, therefore the rate correction is -2.9 × 10 5 byte / s. All values ​​are obtained by subtracting the rate of consecutively acknowledged bytes.

[0090] In one implementation, such as Figure 4 As shown, S3 includes: S31. Add the current confirmed byte rate to the rate correction value to obtain the initial candidate confirmed byte rate, and limit the negative initial candidate confirmed byte rate to 0 to obtain the candidate confirmed byte rate.

[0091] S32. Obtain the original estimated number of confirmed bytes based on the candidate acknowledgment byte rate and the current acknowledgment duration, discard the non-integer part, and get the estimated number of confirmed bytes.

[0092] The remaining number of diagnostic data bytes is obtained based on the total number of diagnostic data bytes and the current cumulative confirmed payload position. The number of bytes to be sent in the next confirmation cycle is obtained based on the expected number of confirmed bytes and the remaining number of diagnostic data bytes. The number of probe bytes to be sent is obtained when the number of bytes to be sent in the next confirmation cycle is 0 and the remaining number of diagnostic data bytes is positive. Obtaining the number of bytes to be sent in the next confirmation cycle can be expressed as:

[0093] In the above formula, This indicates the number of bytes to be sent in the next confirmation cycle. The data source is the smaller of the expected number of confirmed bytes and the remaining number of diagnostic data bytes. The value is a non-negative integer and is used to determine the length of the diagnostic data content included in the next diagnostic data transmission segment. This indicates the number of remaining diagnostic data bytes. The data source is the total number of diagnostic data bytes minus the current cumulative confirmed payload position. The value is a non-negative integer and is used to prevent diagnostic data extraction from exceeding the range to be sent. This indicates the current confirmation duration. The data source is the current confirmation cycle duration verified by a monotonic clock resolution. The value is a positive number, and the unit is 1. ; This represents the current confirmed byte rate, with data sourced from the end of the confirmed byte rate sequence. The value is a non-negative number, and the unit is 1. ; This represents the current rate difference, with data sourced from the current acknowledged byte rate minus the previous acknowledged byte rate, and the unit is... ; This represents the difference in byte rate between the previous and subsequent acknowledgments. The data source is the previous acknowledgment byte rate minus the acknowledgment byte rate before that. The unit is byte rate. .

[0094] Where, subscript n represents the next confirmation cycle, subscript r represents the remaining state, subscript c represents the current state, and subscript p represents the previous state; min represents taking the smaller value of the two byte counts; max represents limiting the lower limit of the candidate confirmation byte rate to 0; ∧ indicates rounding down, discarding the non-integer part of the expected number of confirmed bytes; ∧ indicates that all concatenation conditions are true; ∨ indicates that at least one concatenation condition is true.

[0095] In this embodiment, the calculation logic of the mathematical model is as follows: First, select a rate correction branch based on the current rate difference, the previous rate difference, and the difference between the two; then, apply the rate correction value to the current confirmation byte rate and limit negative calculation results to 0; finally, apply the candidate confirmation byte rate to the current confirmation duration, discard non-integer parts, and limit the final output with the number of remaining diagnostic data bytes.

[0096] The reason for adopting this mathematical model is that the current rate difference can represent the most recent rate change, and the change of the current rate difference relative to the previous rate difference can indicate whether the decreasing value continues to increase. Further adjustments are only applied to cases of continuous decreases and increasing decreasing values, which allows for further reduction of the number of bytes sent when the actual processing rate at the receiving end decreases rapidly; when the current rate difference is non-negative, the increasing value is not extrapolated, thus avoiding a continuous increase in the number of bytes sent caused by a single short, rapid acknowledgment.

[0097] For example, the current confirmed byte rate is 3.0 × 10⁻⁶. 5 byte / s, the current rate difference and the previous rate difference are both -1.5 × 10⁻⁶. 5 The difference between the two is 0 bytes / s, therefore the rate correction value is -1.5 × 10^- ... 5 byte / s. The corrected candidate confirmation byte rate is 1.5 × 10^6 bytes / s. 5byte / s. With the current confirmation duration at 2.0 s, the estimated number of confirmed bytes is 3.0 × 10⁻⁶. 5 The remaining diagnostic data bytes are 1.3 × 10⁻⁶. 6 When the byte count is 3.0 × 10^6 bytes, the number of bytes sent in the next acknowledgment cycle is 3.0 × 10^6 bytes. 5 byte.

[0098] This calculation process ensures that the number of bytes sent in the next confirmation cycle is determined by the actual amount of data persisted by the diagnostic data server and the corresponding confirmation duration, and provides a byte boundary that will not exceed the remaining range for subsequent continuous extraction of diagnostic data content.

[0099] Furthermore, the maximum number of bytes for the network interface payload is not directly taken as the maximum transmission unit (MTB) of the link layer, nor is it a fixed value across all networks. When using TCP, the terminal reads the maximum valid segment length given by the protocol stack for the current connection, then subtracts the header and digest lengths to obtain the upper limit of diagnostic data content that can fit into a transport layer packet data area. The meaning of the maximum valid segment length can be found in existing TCP RFC6691 and RFC9293. When using other control transport protocols, the upper limit of valid packet data given by that protocol for the current path is read, and the same subtraction method is used.

[0100] For example, in an IPv4 example connection without additional IP and TCP options, the maximum transmission unit (MTU) of the interface is 1500 bytes, the fixed IPv4 header and fixed TCP header are each 20 bytes, and the maximum effective segment length given by the protocol stack is 1460 bytes. The sent segment header is 44 bytes, and the digest length is 32 bytes, therefore the maximum network interface payload in bytes is 1384 bytes. If transport layer options, network tunneling, or the maximum transmission unit of the path causes the protocol stack to return a smaller effective transmission limit, the smaller actual return value is used.

[0101] In one implementation, such as Figure 5 As shown, S4 includes: S41. Based on the upload task identifier, sending segment sequence number, current cumulative confirmed payload position and number of bytes sent, extract continuous diagnostic data content from the diagnostic data to be sent, and generate a summary value, sending segment header and diagnostic data sending segment.

[0102] S42. The diagnostic data server parses the diagnostic data transmission segment, generates a checksum value based on the received diagnostic data content, and compares the checksum value with the received digest value.

[0103] S43. After the digest verification is passed, obtain the continuous diagnostic data content to be persisted and written according to the transmit segment payload position range and the current cumulative confirmed payload position, and update the cumulative confirmed payload position after the persistence write is successful.

[0104] S44. Generate an acknowledgment message based on the uploaded task identifier, the sent segment sequence number, and the updated cumulative acknowledgment payload position. The terminal verifies the acknowledgment message and uses the updated cumulative acknowledgment payload position for the next acknowledgment cycle.

[0105] In this embodiment, it should be noted that in S41, the transmission segment sequence number starts from 0 and increments by 1 according to the transmission order at the beginning of each upload task, and is stored as an 8-byte unsigned integer; the starting payload position is also stored as an 8-byte unsigned integer. The transmission segment sequence number is only used to match the transmission time, acknowledgment message, and retransmission record, and does not participate in the calculation of the cumulative acknowledgment payload position. For example, the transmission segment sequence numbers corresponding to the first two diagnostic data transmission segments of the same upload task are 0 and 1 respectively. When the second transmission segment is retransmitted, the sequence number 1 is still used, and a new sequence number is not generated due to the retransmission.

[0106] Specifically, the continuous diagnostic data extraction process uses the current cumulative confirmed load position as the read offset and the number of bytes sent in the next confirmation cycle or the number of bytes sent by the probe as the read length. When using contiguous memory, boundary checks are performed before copying the corresponding bytes; when using segmented files, the starting segment is located based on the logical offset, and reads are performed in segment order until the target length is reached. If the actual read length does not match the target length, no diagnostic data transmission segment is generated. For example, the current cumulative confirmed load position is 2.7 × 10 6 byte, target read length is 4.5 × 10 5 The extracted result starts from the current position and is 3.15 × 10 bytes. 6 End at byte.

[0107] The protocol version is determined through a protocol version table jointly maintained by the terminal and the diagnostic data server. When the current field layout is first used, protocol version 1 can be assigned. When incompatible changes occur in the field order, field width, or parsing rules, a new protocol version is assigned, without altering the meaning of existing fields in the original version. For example, if the terminal sends protocol version 1, and the server's version list includes version 1, it will continue parsing; if the server does not support this version, it will return a version incompatibility status, without guessing the field meaning based on other versions. The version number is a protocol identifier, not a threshold for network status judgment.

[0108] Specifically, the header fields are written in a fixed order: protocol version (1 byte), total length of the sent segment (4 bytes), upload task identifier (16 bytes), sent segment sequence number (8 bytes), starting payload position (8 bytes), diagnostic data content length (4 bytes), digest algorithm identifier (1 byte), and digest length (2 bytes), totaling 44 bytes. Multi-byte integers use network byte order. When the length of the diagnostic data content exceeds the range indicated by the length field, the diagnostic data content is split into multiple application-layer diagnostic data sent segments.

[0109] Furthermore, the total length of the transmitted segment is obtained by sequentially adding the length of the transmitted segment header, the length of the diagnostic data content, and the digest length. The receiving end first checks whether the actual number of received bytes matches the total length of the transmitted segment, and then checks whether the length of the diagnostic data content and the digest length fall within the range limited by the total length of the transmitted segment. An integer overflow check is performed before adding any lengths. For example, if the transmitted segment header is 44 bytes, the diagnostic data content is 1200 bytes, and the digest value is 32 bytes, the total length of the transmitted segment is obtained by adding the aforementioned three lengths, and the receiving end defines the verification boundary according to the same field.

[0110] The digest algorithm identifier is determined through a digest algorithm mapping table, which is jointly stored by the terminal and the diagnostic data server according to the protocol version. Each digest algorithm uses a unique identifier. When establishing an upload task, both parties select an algorithm from the digest algorithms that are jointly supported and conform to the deployment security policy, and write the algorithm identifier into the task metadata. This identifier is not arbitrarily changed during the same upload task. For example, digest algorithm identifier 1 can be mapped to SHA-256, with a digest length of 32 bytes; the algorithm definition can refer to the existing secure hash standard NISTFIPS 180-4. In this embodiment, the digest is used to detect changes in the diagnostic data content and does not replace authentication and encrypted communication.

[0111] In S42, the diagnostic data server first performs boundary checks based on the total length of the transmitted segment and each length field, and then queries the task metadata based on the uploaded task identifier. Persistent writing is not performed if the task does not exist, the protocol version is unsupported, the length fields are inconsistent, or the digest check fails. Digest comparison uses a byte-by-byte comparison for the same length; the input is the received digest value and the recalculated checksum value, and the output is a determination of whether they match or do not match.

[0112] In S43, the transmit segment payload position interval adopts a boundary rule where the start position includes the endpoint but the end position does not. The transmit segment end position is obtained by adding the start payload position to the length of the diagnostic data content, and an overflow check is performed before addition. When the current cumulative confirmed payload position is within the transmit segment payload position interval, the suffix is ​​extracted starting from the content byte corresponding to the current cumulative confirmed payload position; when the current cumulative confirmed payload position is equal to the transmit segment end position, the continuous diagnostic data content to be persisted is empty; when the transmit segment start position is greater than the current cumulative confirmed payload position, the cumulative confirmed payload position remains unchanged.

[0113] Specifically, the completion condition for persistent writes is determined by the result returned by the storage interface. When using file storage, the diagnostic data server performs a location write at the current cumulative acknowledgment payload position of the task file, and then calls an interface that can synchronize the file content and necessary metadata to the stable storage medium. The new position is only committed after the synchronization interface returns a successful return. When using database storage, the diagnostic data content and the new cumulative acknowledgment payload position are written within the same transaction. The new position is only used after the transaction is successfully committed. For example, writing 8.0×10 4 If the synchronization interface fails after a byte, the server retains the original cumulative acknowledgment payload position; only after rewriting and successful synchronization will the cumulative acknowledgment payload position be advanced by 8.0 × 10. 4 byte.

[0114] Furthermore, the persistent updates of the cumulative confirmed payload location and task metadata are consistent with the persistent results of the diagnostic data content. In file storage mode, the diagnostic data content is written first and storage synchronization is completed, then the task metadata is updated using atomic replacement; in database storage mode, the diagnostic data content and task metadata are included in the same transaction. After the device recovers from an anomaly, the server checks the diagnostic data file based on the persistent task metadata. If the effective file length is less than the task metadata location, the cumulative confirmed payload location exceeding the effective file length is not returned.

[0115] In S44, the acknowledgment message is written in a fixed field order, including the protocol version, total acknowledgment message length, upload task identifier, sent segment sequence number, cumulative acknowledgment payload position, and processing status. The protocol version occupies 1 byte, the total acknowledgment message length occupies 4 bytes, the upload task identifier occupies 16 bytes, the sent segment sequence number occupies 8 bytes, the cumulative acknowledgment payload position occupies 8 bytes, and the processing status occupies 2 bytes, totaling 39 bytes for the fixed fields. The field widths are consistent with the corresponding fields in the sent segment, facilitating task matching and position verification by the terminal.

[0116] Specifically, the processing status is determined through a protocol status table. For example, status value 0 indicates successful processing, status value 1 indicates digest verification failure, status value 2 indicates discontinuous start position, and status value 3 indicates persistent write failure. These status values ​​are merely discrete identifiers agreed upon by both communicating parties, not algorithmic thresholds. The terminal only uses the acknowledgment message to generate the acknowledgment byte rate when the processing status indicates success and the task identifier, transmission segment sequence number, and cumulative acknowledgment payload position all pass verification.

[0117] Furthermore, to ensure a clear correspondence between the acknowledgment duration and the number of acknowledgment payload bytes, only one routine diagnostic data transmission segment awaiting application layer acknowledgment is maintained for the same upload task at any given time. In the event of a transport layer retransmission, it is still considered the same diagnostic data transmission segment and the same acknowledgment cycle; the next acknowledgment cycle is only initiated after a matching acknowledgment message is received or a timeout error is returned by the transport protocol stack. The value 1 is determined by the measurement requirement of a one-to-one correspondence between a single acknowledgment cycle and a single transmission segment, and is not a transport protocol congestion window parameter.

[0118] This invention also provides a network status-based diagnostic data processing system for smart terminals with screens, such as... Figure 6 As shown, the system includes the following physical and logical modules: The terminal diagnostic data processing unit is used to collect, encode, save, and transmit diagnostic data to be sent, and to receive acknowledgment messages returned by the diagnostic data server. The diagnostic data server receives diagnostic data transmission segments, performs length verification, digest verification, continuous diagnostic data content extraction and persistent writing, and generates acknowledgment messages. The diagnostic data generator, located within the terminal diagnostic data processing unit, collects interactive diagnostic data for display and terminal operation diagnostic data, sorts and encodes it according to the data generation time and local record sequence number, and extracts continuous diagnostic data content according to the number of bytes sent. The transmission controller, located within the terminal diagnostic data processing unit, generates upload task identifiers and transmission segment sequence numbers, records monotonic clock readings, transmits diagnostic data transmission segments, and matches acknowledgment messages. The acknowledgment rate calculator, located within the transmission controller, verifies the cumulative acknowledgment load position and obtains the number of acknowledgment load bytes, acknowledgment duration, acknowledgment byte rate, current rate difference, and previous rate difference. The transmission byte count calculator, located within the transmission controller, obtains the rate correction value, candidate acknowledgment byte rate, expected number of acknowledgment bytes, remaining number of diagnostic data bytes, number of bytes to be sent in the next acknowledgment cycle, and number of probe bytes to be sent.

[0119] In one implementation, the diagnostic data generator is configured to: obtain display interaction diagnostic data from the display event distribution interface, obtain terminal operation diagnostic data from the system performance statistics interface and the operation log interface; save the data generation time and local record number for each piece of diagnostic data; generate diagnostic data to be sent using a unified binary encoding rule; and perform boundary checks and continuous content extraction based on the current cumulative confirmed payload position and the number of bytes sent.

[0120] In one implementation, the transmission controller is configured to: query the egress network interface index and the next-hop address of the routing based on the diagnostic data server address; record the transmission time, acknowledgment time, and actual timeout waiting time using a monotonic clock; control the transmission order according to the method that a regular diagnostic data transmission segment awaiting application layer acknowledgment corresponds to one acknowledgment cycle; and match acknowledgment messages based on the upload task identifier and the transmission segment sequence number.

[0121] In one implementation, the acknowledgment rate calculator is configured to: perform task identifier verification, position increment verification, and sent boundary verification on candidate cumulative acknowledgment payload positions; obtain the number of acknowledgment payload bytes based on adjacent cumulative acknowledgment payload positions that have passed the verification; obtain the acknowledgment byte rate based on the acknowledgment duration verified by clock resolution; form an acknowledgment byte rate sequence according to the acknowledgment cycle order, and obtain the current rate difference and the previous rate difference.

[0122] In one implementation, the byte count calculator is configured to: obtain a rate correction value based on the current rate difference, the previous rate difference, and the difference between the two; obtain a candidate acknowledgment byte rate based on the current acknowledgment byte rate and the rate correction value; obtain the expected number of acknowledgment bytes based on the candidate acknowledgment byte rate and the current acknowledgment duration; obtain the number of bytes to be sent in the next acknowledgment cycle based on the expected number of acknowledgment bytes and the number of remaining diagnostic data bytes; and when the normal byte count is 0 and there is still diagnostic data to be sent, obtain the probe byte count based on the network interface load limit bytes.

[0123] In one implementation, the diagnostic data server is configured to: parse the upload task identifier, send segment sequence number, starting payload position, and diagnostic data content length from the send segment header; recalculate the verification digest value of the diagnostic data content; after the digest verification passes, obtain the continuous diagnostic data content to be persistently written based on the send segment payload position range and the current cumulative confirmed payload position; update the cumulative confirmed payload position after successful storage synchronization or transaction commit, and write the update result to the confirmation message. The diagnostic data send segment flows from the terminal diagnostic data processing device to the diagnostic data server, the confirmation message flows from the diagnostic data server to the confirmation rate calculator, and the number of bytes sent in the next confirmation cycle flows from the number of bytes sent to the diagnostic data generator.

[0124] The following uses a specific application scenario to integrate and verify the calculation logic and data flow process of each step in the above implementation method.

[0125] Assume that at a certain moment, the diagnostic data generator completes the acquisition, sorting, binary encoding, and sequential concatenation of the interactive diagnostic data for display and the diagnostic data running on the terminal. The byte container length is 4.0 × 10⁻⁶. 6 Therefore, the total number of bytes in the diagnostic data is 4.0 × 10^6 bytes. 6 This value represents the actual length of the encoded diagnostic data content, excluding the send header, digest value, and protocol headers at each layer. The diagnostic data server does not store the task metadata corresponding to the currently uploaded task identifier; therefore, the returned starting position for the new task upload is 0 bytes. The value 0 indicates that the new task has not yet persisted diagnostic data content.

[0126] The current route lookup retrieves the egress network interface index 7 from the operating system's routing table. The value 7 is the index assigned by the operating system to the current actual egress network interface. Throughout consecutive acknowledgment cycles, the egress network interface index remains 7, and the cycle-by-cycle lookup results for the next-hop address also remain the same; therefore, the acknowledgment byte rate sequence is not cleared. The path consistency conclusion comes from cycle-by-cycle route lookups and comparisons, not from inference based on signal strength.

[0127] Before forming the initial acknowledgment byte rate sequence for the current task, the terminal queries the most recently completed historical upload task that has the same diagnostic data server address, egress network interface index, and next-hop routing address. This historical task actually stores 5 valid bytes sent, with the value 5 derived from the number of historical task records; the corresponding values ​​are 7.0 × 10⁻⁶. 5 8.0×10 5 9.0×10 5 1.0×10 6 and 1.1×10 6 Each byte represents the number of bytes actually sent that have been acknowledged in the corresponding historical acknowledgment period. The sorted median value is 9.0 × 10^6 bytes. 5 Therefore, the initial number of bytes to send is 9.0 × 10. 5 byte.

[0128] The algorithm requires at least three consecutive acknowledgment byte rate samples to obtain the current rate difference and the previous rate difference. The value of three is determined by the calculation relationship between two adjacent rate differences. Therefore, during the initialization process of S1, the first three acknowledgment cycles send 9.0 × 10^9 bytes of data, provided that the number of bytes of remaining diagnostic data does not exceed the limit. 5The diagnostic data content is in bytes. The starting cumulative acknowledgment payload position for the first acknowledgment cycle is byte 0, the starting position of the new task upload. After the diagnostic data server completes the digest verification and persistent writing of the first diagnostic data transmission segment, the cumulative acknowledgment payload position advances to 9.0 × 10. 5 Therefore, the first acknowledged payload byte count is 9.0 × 10^9 bytes. 5 byte.

[0129] The second confirmation cycle continues sending the initialization bytes: 9.0 × 10. 5 This value, a byte, comes from the same historical median. The diagnostic data server has been accumulating confirmed payloads since the last time the value was 9.0 × 10. 5 After the byte completes continuous persistent writing, the cumulative confirmed payload position advances to 1.8 × 10. 6 byte; the number of positions added is 9.0 × 10 5 Therefore, the second confirmed payload bytes are still 9.0 × 10^6 bytes. 5 byte.

[0130] The third acknowledgment cycle will send the initialization bytes again: 9.0 × 10^9. 5 byte. The diagnostic data server has accumulated 1.8 × 10^6 bytes of payload location since the last confirmed data entry. 6 After the byte began completing continuous persistent writing, the cumulative confirmed payload position advanced to 2.7 × 10. 6 byte; the number of positions added is 9.0 × 10 5 Therefore, the third confirmed payload also has 9.0 × 10 bytes. 5 The three cumulative positions all originate from the metadata of the diagnostic data server's persistent task, and none exceed the maximum end position of the diagnostic data already sent.

[0131] The monotonic clock resolution returned by the operating system timing interface is 1ms, a value directly derived from the timing interface. The transmission and reception times of the first acknowledgment cycle differ by 1.5s, the second by 2.0s, and the third by 3.0s. These three times are all differences in the actual monotonic clock values ​​read in each acknowledgment cycle, and all are greater than the monotonic clock resolution; therefore, they are all valid acknowledgment durations. The sequentially increasing acknowledgment duration indicates that the same amount of diagnostic data requires a longer time to complete transmission, verification, and persistent writing within consecutive acknowledgment cycles. This variation does not violate network and storage processing rules.

[0132] The first confirmation period is 9.0 × 10 5 Dividing the number of bytes in the byte-acknowledgment payload by the corresponding 1.5 S yields 6.0 × 10^6 bytes.5 The acknowledgment byte rate in bytes / s. 9.0 × 10⁻⁶ in the second acknowledgment period. 5 Dividing the byte by the corresponding 2.0 S, we get 4.5 × 10. 5 byte / s. 9.0 × 10⁻⁶ in the 3rd confirmation period. 5 Dividing the byte by the corresponding 3.0 S yields 3.0 × 10 5 byte / s. The aforementioned calculation results are added to the acknowledgment byte rate sequence in the order of the acknowledgment period's end.

[0133] In S2, the current acknowledgment byte rate is 3.0 × 10⁻⁶ at the end of the sequence. 5 byte / s, the rate of the last acknowledged byte is 4.5 × 10⁻⁶ of the adjacent term. 5 byte / s, the previously confirmed byte rate was 6.0 × 10⁻⁶. 5 byte / s. The current acknowledgment byte rate is 1.5 × 10⁻⁶ byte rate lower than the previous acknowledgment byte rate. 5 byte / s, therefore the current rate difference is -1.5 × 10 5 byte / s; the byte rate of the previous acknowledgment is also reduced by 1.5 × 10⁻⁶ byte rate compared to the byte rate of the acknowledgment before that. 5 byte / s, therefore the previous rate difference is also -1.5 × 10 5 byte / s. The result of subtracting two rate differences is 0 byte / s, and the value 0 comes from the subtraction of two identical differences.

[0134] In S3, both the current rate difference and the previous rate difference are negative, but the difference between them is 0 bytes / s, which does not meet the condition for the decreasing value to continue increasing. Therefore, the rate correction value is the current rate difference minus 1.5 × 10. 5 byte / s. Current acknowledged byte rate: 3.0 × 10⁻⁶ 5 After correction, the candidate acknowledgment byte rate is 1.5 × 10⁻⁶. 5 byte / s.

[0135] The current confirmation duration is 3.0 seconds, actually measured during the 3rd confirmation cycle, and the candidate confirmation byte rate corresponds to 4.5 × 10⁻⁶ byte rate during this duration. 5 Therefore, the expected number of confirmed bytes is 4.5 × 10⁻⁶. 5 The total number of bytes in the diagnostic data is 4.0 × 10^6 bytes, obtained from encoding statistics. 6 The current cumulative confirmed payload position is 2.7 × 10 bytes, carried in the 3rd confirmed message. 6 The difference between the two is 1.3 × 10^2 bytes. 6Number of remaining diagnostic data bytes. Expected confirmed bytes: 4.5 × 10⁻⁶ 5 The number of bytes is less than 1.3 × 10^3 bytes of remaining diagnostic data. 6 Therefore, the number of bytes sent in the next confirmation cycle is 4.5 × 10^6 bytes. 5 byte.

[0136] In S4, firstly, the diagnostic data generator uses the current cumulative confirmed load position of 2.7 × 10⁻⁶. 6 Using byte as the starting point for reading, and taking 4.5 × 10 as the output of S3. 5 The length of the read operation is byte, used to extract continuous diagnostic data. The end position of the read operation is 3.15 × 10^6 bytes, which is the sum of the start position and the read length. 6 byte. Value 3.15 × 10 6 A byte contains only two decimal places and comes from explicit positional addition; it is not a measurement approximation.

[0137] Secondly, the terminal generates a 44-byte header according to the field definitions. The 44-byte value comes from the sum of the widths of the fixed fields in the header. It uses the SHA-256 standard negotiated during task establishment, with a length of 4.5 × 10. 5 The diagnostic data content generates a 32-byte digest value, with the 32-byte value derived from the fixed output length of the digest algorithm. This diagnostic data transmission segment belongs to the application layer data frame. The transport protocol stack can split it into multiple TCP packets based on the currently valid maximum segment length, without requiring the entire content to be loaded into a single link layer frame.

[0138] Next, the diagnostic data server parses the sent segment header and recalculates the checksum value. The checksums match, and the server's current cumulative acknowledgment payload position is 2.7 × 10^6 KB, which was returned in the previous acknowledgment message. 6 The byte is located at the same position as the starting payload of this transmission segment; therefore, all 4.5 × 10 bytes extracted in this instance are included. 5 All bytes represent continuous diagnostic data to be persistently written. After the server completes the write and storage synchronization, it will move the data from its original location to 2.7 × 10. 6 The byte advances forward by 4.5 x 10^6 bytes from this successful write. 5 The updated cumulative confirmed payload position is 3.15 × 10 bytes. 6 byte.

[0139] Finally, the diagnostic data server generates a data set including the corresponding upload task identifier, the transmission segment sequence number, and 3.15 × 10^6 bytes. 6 The terminal sends an acknowledgment message for the cumulative confirmed payload position. The updated cumulative confirmed payload position is compared with the previous 2.7×10 bytes.6 Byte comparison yields 4.5 × 10^6 bytes of new acknowledgment payload available for the next acknowledgment cycle. 5 The newly added acknowledgment payload byte count, together with the next actual measured acknowledgment duration, generates a new acknowledgment byte rate, and continues into path consistency verification and rate difference calculation.

[0140] The preferred embodiments of this disclosure have been described in detail above with reference to the accompanying drawings. However, this disclosure is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this disclosure, various simple modifications can be made to the technical solutions of this disclosure, and these simple modifications all fall within the protection scope of this disclosure.

[0141] It should also be noted that the various specific technical features described in the above embodiments can be combined in any suitable manner without contradiction. To avoid unnecessary repetition, this disclosure will not describe the various possible combinations separately.

[0142] Furthermore, various different embodiments of this disclosure can be combined in any way, as long as they do not violate the spirit of this disclosure, they should also be regarded as the content disclosed in this disclosure.

[0143] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be covered within the scope of the claims and specification of the present invention.

Claims

1. A method for processing diagnostic data of a smart terminal with a screen based on network status, characterized in that, The methods include: Obtain the diagnostic data to be sent; subtract the starting cumulative acknowledgment load position from the end cumulative acknowledgment load position of the acknowledgment cycle to obtain the number of acknowledgment load bytes; The acknowledgment byte rate is obtained by dividing the number of acknowledgment payload bytes by the current acknowledgment duration; the acknowledgment byte rates of each acknowledgment cycle are then sequentially arranged into an acknowledgment byte rate sequence. The current rate difference is obtained by subtracting the previous term from the last term of the confirmed byte rate sequence; the previous rate difference is obtained by subtracting the term before that from the previous term; the rate correction value is determined based on the current rate difference and the previous rate difference: when both are negative and the former is less than the latter, the sum of the former and the difference between the two is taken; in other cases where the former is negative, the former is taken; when the former is non-negative, 0 is taken. Add the terminal item to the rate correction value and set the negative value to 0 to obtain the candidate acknowledgment byte rate; based on the candidate acknowledgment byte rate and the current acknowledgment duration, obtain the expected number of acknowledgment bytes; obtain the remaining number of diagnostic data bytes to be sent; take the smaller value between the expected number of acknowledgment bytes and the remaining number of diagnostic data bytes to obtain the number of bytes to be sent in the next acknowledgment cycle; Transmit the diagnostic data to be sent according to the number of bytes sent in the next confirmation cycle.

2. The method for processing diagnostic data of a smart terminal with a screen based on network status according to claim 1, characterized in that, Subtracting the starting cumulative confirmed load position from the ending cumulative confirmed load position yields the number of confirmed load bytes, including: Based on the diagnostic data content that has been continuously persisted, the candidate cumulative confirmed load position is obtained; if the candidate cumulative confirmed load position is less than the starting cumulative confirmed load position, the candidate cumulative confirmed load position is discarded. Obtain the maximum end position of the sent diagnostic data; compare the candidate cumulative confirmed payload position with the maximum end position of the sent diagnostic data to obtain the sent boundary verification result; If the sent boundary verification result indicates that the candidate cumulative confirmed load position has not exceeded the maximum end position of the sent diagnostic data, the candidate cumulative confirmed load position will be determined as the end position of the cumulative confirmed load.

3. The method for processing diagnostic data of a smart terminal with a screen based on network status according to claim 1, characterized in that, The acknowledgment byte rate is obtained by dividing the number of acknowledgment payload bytes by the current acknowledgment duration, including: Read the monotonic clock before the first byte of the diagnostic data transmission segment is committed to obtain the transmission time; read the same monotonic clock after the corresponding acknowledgment message is received to obtain the acknowledgment reception time. Subtract the sending time from the receiving time to obtain the candidate acknowledgment duration; read the clock resolution of the monotonic clock; compare the candidate acknowledgment duration with the clock resolution to obtain the duration comparison result; The duration comparison result indicates that when the candidate confirmation duration is greater than the clock resolution, the candidate confirmation duration is determined as the current confirmation duration; The acknowledgment byte rate is obtained by dividing the number of acknowledgment payload bytes by the current acknowledgment duration.

4. The method for processing diagnostic data of a smart terminal with a screen based on network status according to claim 1, characterized in that, Forming a confirmed byte rate sequence includes: Query the current destination route of the diagnostic data server to obtain the outgoing network interface index; query the current destination route to obtain the next hop address of the route; Compare the current egress network interface index with the previous egress network interface index to obtain the interface index comparison result; if the interface index comparison result is different, clear the confirmation byte rate sequence. If the interface index comparison results are the same, compare the next-hop address of the current route with the next-hop address of the previous route to obtain the next-hop address comparison result; if the next-hop address comparison results are different, clear the confirmation byte rate sequence. If the next-hop address comparison results are the same, the newly acquired acknowledgment byte rate is added to the acknowledgment byte rate sequence.

5. The method for processing diagnostic data of a smart terminal with a screen based on network status according to claim 1, characterized in that, Add the end term to the rate correction value and set the negative value to 0 to obtain the candidate confirmed byte rate; Based on the candidate acknowledgment byte rate and the current acknowledgment duration, the expected number of acknowledgment bytes is obtained, including: Add the end term to the rate correction value to obtain the initial candidate acknowledgment byte rate; When the initial candidate acknowledgment byte rate is negative, the candidate acknowledgment byte rate is set to 0; when the initial candidate acknowledgment byte rate is non-negative, the initial candidate acknowledgment byte rate is set to the candidate acknowledgment byte rate. Based on the candidate acknowledgment byte rate and the current acknowledgment duration, the original estimated acknowledgment byte count is obtained; the non-integer part of the original estimated acknowledgment byte count is discarded to obtain the estimated acknowledgment byte count.

6. The method for processing diagnostic data of a smart terminal with a screen based on network status according to claim 1, characterized in that, Obtain the remaining number of diagnostic data bytes and the number of bytes to be sent in the next confirmation cycle, including: Obtain the total number of bytes of diagnostic data to be sent; subtract the end of the cumulative acknowledgment payload position from the total number of bytes of diagnostic data to obtain the remaining number of bytes of diagnostic data; Take the smaller value between the expected number of acknowledgment bytes and the remaining number of diagnostic data bytes to obtain the number of bytes to be sent in the next acknowledgment cycle; When the number of bytes sent in the next confirmation cycle is 0 and the number of remaining diagnostic data bytes is positive, obtain the upper limit of the network interface load in bytes; take the smaller value between the upper limit of the network interface load in bytes and the number of remaining diagnostic data bytes to obtain the number of probe bytes sent; Transmit the diagnostic data to be sent according to the number of bytes sent by the probe.

7. The method for processing diagnostic data of a smart terminal with a screen based on network status according to claim 1, characterized in that, Transmit the diagnostic data to be sent according to the number of bytes to be sent in the next confirmation cycle, including: Generate an upload task identifier; obtain the diagnostic data content based on the number of bytes to be sent in the next confirmation cycle and the diagnostic data to be sent; Generate a summary value based on the diagnostic data; determine the end of the cumulative confirmed load position as the start load position; generate the send segment header based on the uploaded task identifier and the start load position; Generate the transmit segment payload based on the diagnostic data content and summary value; generate the diagnostic data transmit segment based on the transmit segment header and transmit segment payload; Transmit diagnostic data sending segment.

8. The method for processing diagnostic data of a smart terminal with a screen based on network status according to claim 7, characterized in that, The diagnostic data transmission segment includes: Receive the diagnostic data content from the diagnostic data transmission segment to obtain the received diagnostic data content; receive the digest value from the diagnostic data transmission segment to obtain the received digest value; A checksum value is generated based on the received diagnostic data; the checksum value is compared with the received digest value to obtain the digest comparison result; When the summary comparison results indicate that they are consistent, the payload position range of the transmitting segment is obtained based on the starting payload position of the diagnostic data transmitting segment and the length of the received diagnostic data content.

9. The method for processing diagnostic data of a smart terminal with a screen based on network status according to claim 8, characterized in that, When the summary comparison results indicate a match, processing is performed based on the transmit segment payload location range and the current cumulative confirmed payload location, including: If the end position of the transmit segment load position interval does not exceed the current cumulative confirmed load position, the continuous diagnostic data content to be persisted and written will be determined as empty; When the transmit segment payload position range covers the current cumulative confirmed payload position, extract the suffix starting from the current cumulative confirmed payload position to obtain the continuous diagnostic data content to be persistently written. Persistently write non-empty continuous diagnostic data content to be persisted to obtain the updated cumulative confirmed load position; A confirmation message is generated based on the uploaded task identifier and the updated cumulative confirmed payload location.

10. A network status-based diagnostic data processing system for smart terminals with screens, characterized in that, The system is used to implement the network status-based diagnostic data processing method for smart terminals with screens as described in any one of claims 1 to 9; The system includes a terminal diagnostic data processing device and a diagnostic data server; the terminal diagnostic data processing device includes a diagnostic data generator and a transmission controller, and the transmission controller includes an acknowledgment rate calculator and a number of bytes sent calculator. The diagnostic data generator is used to acquire diagnostic data to be sent; the acknowledgment rate calculator is used to generate the acknowledgment byte rate sequence; and the number of bytes sent calculator is used to obtain the number of bytes to be sent in the next acknowledgment cycle. The transmission controller is used to generate and transmit diagnostic data transmission segments based on the number of bytes to be sent in the next confirmation cycle and the diagnostic data to be sent; The diagnostic data server is used to persist the diagnostic data content written to the diagnostic data sending segment and obtain the updated cumulative acknowledgment payload position; the diagnostic data server is also used to generate acknowledgment messages based on the updated cumulative acknowledgment payload position.

Images