An HID batch data sharding resuming transmission scheduling method, an electronic device and a storage medium

Abstract

The application belongs to the technical field of communication control, and relates to a HID batch data fragmentation resuming transmission scheduling method, an electronic device and a storage medium. The method comprises the following steps: obtaining to-be-sent HID service data and scheduling attributes, and writing the to-be-sent HID service data and the scheduling attributes into a plurality of logical channels comprising a batch transmission channel; when the service data is batch data, performing fragmentation according to a HID report payload length to obtain batch data fragments and establish fragmentation confirmation records; determining a channel health degree and a global flow limiting coefficient according to logical channel operation indexes, and adjusting a token replenishment rate and a sending window according to the channel health degree and the global flow limiting coefficient to determine a sending logical channel; taking out the HID service data from the sending logical channel and encapsulating the HID service data into a HID report for sending; and when the sending logical channel is the batch transmission channel, updating the fragmentation confirmation records according to service layer feedback or a timeout state to resume transmission or retransmit the batch data fragments. The application can realize HID service data channel scheduling, and provide a basis for batch data fragmentation resuming transmission and retransmission.

Description

Technical Field

[0001] This invention relates to the field of communication control technology, specifically to a method for scheduling HID batch data fragmentation and retransmission, an electronic device, and a storage medium. Background Technology

[0002] HID communication is commonly used for transmitting control commands, status information, input data, configuration data, and log data between a host computer and external devices. In related technologies, HID data is typically processed according to a single transmission queue or a fixed-priority queue. The sending end encapsulates the data to be sent into HID reports and sends them sequentially, waiting for feedback from the device when confirmation is required. For small amounts of control commands or status data, this method can meet basic communication requirements.

[0003] However, when control data, high-frequency data, batch data, alarm data, and log data coexist in the same HID link, a single queue or simple priority method is insufficient to distinguish the acknowledgment requirements, timeliness requirements, and data volume characteristics of different data. Batch data usually exceeds the payload length of a single HID report and needs to be split into multiple reports for transmission. If processed only according to the transmission order, it is impossible to stably record the transmission status and acknowledgment status of each segment. After negative feedback, timeout, device busy, or disconnection and reconnection, the sending end has difficulty determining which segments have been received by the device and which segments need to be retransmitted, which can easily lead to duplicate transmission, missed transmission, or continuation of transmission from the wrong position.

[0004] Meanwhile, existing processing methods mostly control HID report transmission based on single-transmission results or fixed transmission rates, failing to incorporate queue length, response latency, timeout rate, retransmission rate, error rate, device busy ratio, and the number of unacknowledged messages into a unified scheduling judgment. When device-side processing capacity decreases or link feedback slows down, the sending end may still continue to deliver data, leading to the accumulation of unacknowledged messages, batch transmission consuming link resources, and affecting the transmission order of control, alarm, and other service data. Therefore, it is necessary to solve the scheduling, acknowledgment, retransmission, and resumption control issues of multiple types of service data and batch data fragments in HID communication under the same link. Summary of the Invention

[0005] This invention provides a method, electronic device, and storage medium for scheduling HID batch data fragmentation and retransmission, which at least solves the problem of how to uniformly schedule, acknowledge, retransmit, and resume multiple types of service data and batch data fragmentation in HID communication links.

[0006] In a first aspect, the present invention provides a method for scheduling HID batch data fragmentation and retransmission, the method comprising: Obtain the HID service data to be sent and its scheduling attributes, and write the HID service data to be sent into multiple logical channels, including the batch transmission channel, according to the scheduling attributes; When the HID service data to be sent is batch data, it is fragmented according to the HID report payload length to obtain batch data fragments, and a fragmentation confirmation record is established. The channel health and global rate limiting coefficient are determined based on the operating metrics of each logical channel, and the token replenishment rate and sending window are adjusted based on the channel health and global rate limiting coefficient to determine the sending logical channel; Retrieve the HID service data to be sent from the sending logical channel, or select the batch data fragments to be sent based on the fragmentation confirmation record when the sending logical channel is a batch transmission channel, and encapsulate them into an HID report for sending; When the sending logical channel is a batch transmission channel, the fragmentation confirmation record is updated according to the feedback from the service layer, the timeout status, or the disconnection and reconnection status, so as to resume or retransmit batch data fragments.

[0007] In one possible implementation, the scheduling attributes include a service type identifier, an acknowledgment requirement identifier, an overlay permission identifier, a maximum wait time, a fragment size, a retry count, and a service priority. Based on these scheduling attributes, the HID service data to be sent is written to multiple logical channels, including a batch transmission channel, including: The logical channel to which the HID service data to be sent belongs is determined based on the service type identifier, and the HID service data to be sent, along with the confirmation request identifier, coverage permission identifier, maximum waiting time, fragment size, number of retries, and service priority, are written into the scheduling queue in the logical channel.

[0008] In one possible implementation, the multiple logical channels include a control channel, a status channel, a high-frequency data channel, a batch transmission channel, an alarm channel, and a log channel; The control channel is used to write control data, the status channel is used to write status data, the high-frequency data channel is used to write high-frequency data, the batch transmission channel is used to write batch data, the alarm channel is used to write alarm data, and the log channel is used to write log data.

[0009] In one possible implementation, a fragmentation acknowledgment record is established, including: configuring a batch task identifier, fragment sequence number, fragment offset, fragment length, acknowledgment identifier, and verification field for each batch data fragment; establishing a batch transmission task based on the batch task identifier, and writing the fragment sequence number, fragment offset, sent fragment position, acknowledged fragment position, and unacknowledged fragment position into the fragmentation acknowledgment record of the batch transmission task.

[0010] In one possible implementation, the operational metrics include queue length, response latency, timeout rate, retransmission rate, error rate, device busy ratio, number of unacknowledged messages, current sending window, and current number of tokens. The operational metrics are determined based on the sending records of multiple logical channels, service layer feedback from the HID device, and timeout timing records, and are used to determine channel health and global rate limiting coefficients.

[0011] In one possible implementation, the channel health and global rate limiting coefficient are determined based on the operational metrics of each logical channel, including: determining the channel health based on error rate, timeout rate, retransmission rate, device busy ratio, and normalized response latency; and determining the global rate limiting coefficient based on the average device busy ratio, average timeout rate, average retransmission rate, total queue pressure determined by queue length, and device buffer pressure determined by device busy ratio and number of unacknowledged messages for multiple logical channels.

[0012] In one possible implementation, adjusting the token replenishment rate and sending window to determine the sending logical channel includes: configuring a logical channel priority for each logical channel, and determining the token replenishment rate for multiple logical channels based on channel health, global rate limiting coefficient, and logical channel priority; adjusting the current sending window based on channel health and service layer feedback; identifying logical channels with fewer unacknowledged messages than the current sending window and a greater than zero current token count as candidate logical channels; determining a sending score based on the logical channel priority of the candidate logical channels, the waiting time determined by the enqueue time of the HID service data to be sent in the candidate logical channels and the current scheduling time, the queue pressure determined by the queue length, the congestion state determined by the timeout rate, retransmission rate, error rate, and device busy ratio, and the retry state determined by the sending records, and identifying the candidate logical channel with the highest sending score as the sending logical channel.

[0013] In one possible implementation, the fragmentation confirmation record is updated based on business layer feedback, timeout status, or disconnection / reconnection status to resume or retransmit batch data fragments. This includes: business layer feedback including confirmation feedback, negative feedback, and device busy feedback; if the business layer feedback is confirmation feedback, the batch data fragment indicated by the confirmation feedback is marked as a confirmed fragment, and the confirmed fragment position is updated; if the business layer feedback is negative feedback, or if no business layer feedback is received and a timeout status is formed, the unconfirmed batch data fragments are retransmitted based on the unconfirmed fragment position; if the business layer feedback is device busy feedback or a disconnection / reconnection occurs, the resumption start point is determined based on the confirmed fragment position, and batch data fragments are continued to be sent from the resumption start point.

[0014] Secondly, the present invention provides an electronic device, including a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to implement an HID batch data fragmentation and retransmission scheduling method.

[0015] Thirdly, the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements an HID batch data fragmentation and retransmission scheduling method.

[0016] Compared with the prior art, the advantages and beneficial effects of the present invention are as follows: By writing the HID service data to be sent and scheduling attributes together into multiple logical channels, separate channel management of control data, status data, high-frequency data, batch data, alarm data and log data is realized, so that data of different service categories can enter subsequent scheduling according to their respective confirmation requirements, waiting time, coverage permission and priority.

[0017] By fragmenting batch data according to the HID report payload length when it enters the batch transmission channel, and establishing a fragment confirmation record that includes fragment sequence number, fragment offset, fragment length, sent fragment position, confirmed fragment position, and unconfirmed fragment position, the batch data transmission process can have a traceable fragment status, providing a clear basis for subsequent confirmation, retransmission, and continuation.

[0018] By determining the channel health and global rate limiting coefficient based on the operating indicators of each logical channel, and adjusting the token replenishment rate and sending window accordingly, the sending rhythm can be matched with the device busy feedback, timeout, retransmission, and unacknowledged message accumulation.

[0019] By updating the fragmentation confirmation record based on confirmation feedback, negative feedback, device busy feedback, timeout status, or disconnection and reconnection status, it is possible to locate unconfirmed fragments or the start point of resume transmission after batch transmission anomalies or link recovery, so that batch data fragments form a recoverable transmission control process in the same HID communication link. Attached Figure Description

[0020] Figure 1 This is a schematic flowchart of the method of the present invention; Figure 2 This is a schematic diagram of scheduling attribute parsing and logical channel writing in this invention; Figure 3 This is a schematic diagram illustrating the batch data sharding and confirmation record establishment in this invention; Figure 4 This is a schematic diagram of dynamic scheduling and retransmission control in this invention. Detailed Implementation

[0021] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings of one or more embodiments. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this invention.

[0022] In this embodiment, the fragmented retransmission scheduling uses the HID service data to be sent received by the HID communication scheduler as the processing object. The HID service data to be sent is submitted by the host computer-side service module and enters the scheduling process along with scheduling attributes such as service type identifier, confirmation request identifier, coverage permission identifier, maximum waiting time, fragment size, retry count, and service priority. The HID communication scheduler writes different service data into the corresponding logical channels according to the scheduling attributes; when the service data belongs to batch data, it further forms batch data fragments according to the HID report payload length, and establishes a fragment confirmation record with the batch task identifier. The fragment confirmation record is used to save the fragment sequence number, fragment offset, transmission status, and confirmation status. Subsequently, combined with the service layer feedback returned by the HID device, the timeout status formed by the host computer, and the disconnection and reconnection status, the continued transmission position, retransmission position, or retransmission start point of the batch data fragments is determined.

[0023] like Figure 1 As shown, a method for scheduling HID batch data fragmentation and retransmission includes the following processing steps.

[0024] The host computer-side HID communication scheduler receives the HID service data to be sent submitted by the service module.

[0025] The HID service data to be sent can originate from various service processes, such as control command issuance, device status synchronization, high-frequency input data transmission, batch file transfer, alarm event reporting, or log output. When submitting the HID service data to be sent, the service module simultaneously configures the scheduling attributes.

[0026] The HID communication scheduler reads the service type information from the scheduling attributes to determine the logical channel that the HID service data to be sent needs to enter.

[0027] A logical channel is a queued scheduling entry point established on the same HID communication link, used to manage data of different service categories, confirmation requirements, and real-time requirements separately. After channel selection is completed, the HID communication scheduler writes the HID service data to be sent and scheduling attributes into the scheduling queue of the corresponding logical channel.

[0028] Once the scheduling queue is formed, subsequent scheduling phases can execute transmission control based on the queue status, acknowledgment requirements, fragmentation constraints, and priority relationships of each logical channel.

[0029] like Figure 2 As shown, in one embodiment, the scheduling attributes are configured by the service module when generating the HID service data to be sent, or they can be supplemented by the HID communication scheduler based on the service call interface, HID report number, command number, or data length.

[0030] The service type identifier in the scheduling attributes is used to characterize the service category of the HID service data to be sent. After reading the service type identifier, the HID communication scheduler allocates the HID service data to be sent to the matching logical channel. The service type identifier can be represented by an enumeration value, a protocol field, or an internal task type number, as long as it can reliably distinguish between control data, status data, high-frequency data, batch data, alarm data, and log data.

[0031] The confirmation requirement identifier indicates whether HID service data to be sent needs to wait for feedback from the HID device at the service layer after transmission. Control commands, batch data fragments, and alarm data typically require confirmation; some status refresh data, high-frequency data, or log data may not require confirmation.

[0032] Once the confirmation request identifier enters the scheduling queue, it will be used during the sending phase to determine whether to establish an unacknowledged message record, whether to start a timeout countdown, and whether to participate in retry control.

[0033] The overwrite permission flag indicates whether HID service data to be sent is allowed to be replaced by newer data of the same type before it has been sent. Status refresh data, high-frequency data, or some log data are time-sensitive, and newer data of the same type can replace older data in the queue that has not yet been sent. Control commands and batch data are generally not allowed to be overwritten to avoid command loss or incomplete batch transmission content.

[0034] The maximum waiting time limits the allowed queuing time for HID service data to be sent in the scheduling queue. The maximum waiting time can be set according to the service type, device response requirements, and host computer task cycle. Control data and alarm data typically use shorter maximum waiting times, while batch data and log data can use longer maximum waiting times.

[0035] Fragment size is used to determine the payload boundary of a single batch data fragment after batch data enters the batch transmission channel. The fragment size can be determined based on the HID report payload length, service header field length, checksum field length, and HID device buffering capacity. When the HID service data to be sent is not batch data, the fragment size can be left at the default value and will not participate in normal data transmission.

[0036] The retry count limits the number of times the same HID service data can be retransmitted after a negative feedback, timeout, or device busy feedback. Service priority is used for sorting within the same logical channel or among multiple logical channels.

[0037] After determining the logical channel into which the HID service data to be sent should enter, the HID communication scheduler writes the HID service data to be sent, along with the acknowledgment requirement identifier, coverage permission identifier, maximum waiting time, fragment size, retries, and service priority, into the scheduling queue of that logical channel. The records in the scheduling queue store both the data content and the scheduling fields required for subsequent transmission control, thus providing a data source for performance statistics, transmission window control, and batch fragmented retransmission.

[0038] In one embodiment, multiple logical channels are divided according to business semantics and transmission constraints.

[0039] The control channel is used to receive control data. Control data typically corresponds to parameter settings, mode switching, function activation / deactivation, or command issuance by the host computer to the HID device. Control data is sensitive to the transmission order and acknowledgment results; once it enters the control channel, it generally maintains its queuing order and waits for confirmation from the device after transmission.

[0040] The status channel is used to receive status data. Status data is used to synchronize the operating status, on / off status, configuration status, or connection status of HID devices. Status data is highly time-sensitive; if old data for the same status object exists in the queue, it can be replaced using an overwrite permission flag, allowing subsequent transmission phases to process the latest status.

[0041] The high-frequency data channel is used to receive high-frequency data. High-frequency data can originate from continuous input, sensor data, key presses, pointer movement data, or other short-cycle traffic. High-frequency data is typically abundant but with small individual data volumes, requiring high real-time performance; however, some high-frequency data can be overwritten by subsequent data. The high-frequency data channel stores this type of data in a separate scheduling queue, preventing continuous influx of high-frequency data from crowding out the queue space of the batch transmission and control channels.

[0042] The bulk transfer channel is used to receive batch data. Batch data typically features large single-transfer volumes, requires complete delivery, necessitates fragmented confirmation, and may experience interrupted transmission. Firmware data, configuration file data, macro script data, and batch log export data can all be entered into the bulk transfer channel as batch data.

[0043] After batch data enters the batch transmission channel, it is not sent directly as a single HID report. Instead, it waits for the subsequent fragmentation stage to split it into multiple batch data fragments according to the HID report payload length. When enqueuing data, the batch transmission channel retains the fragment size, retry count, acknowledgment request identifier, and service priority, providing a basis for the establishment of subsequent fragmentation acknowledgment records and for resuming or retransmitting data.

[0044] The alarm channel is used to receive alarm data. Alarm data is typically triggered by equipment malfunctions, communication failures, out-of-bounds operating conditions, or security events, and has a high processing priority. The scheduling queue in the alarm channel stores alarm data independently, preventing alarm sources, alarm order, and alarm processing records from being mixed with ordinary control data.

[0045] The log channel is used to receive log-type data. Log-type data is typically used to record debugging information, runtime processes, or non-critical events. The real-time and integrity requirements for log-type data are lower than those for control-type data and batch-type data, and it can be combined with overlay permission identifiers, maximum waiting time, and business priorities to participate in subsequent scheduling.

[0046] After each logical channel completes data writing, the HID communication scheduler maintains the queue length, pending data records, and scheduling attribute records for each logical channel. In the subsequent operational metric statistics phase, the scheduler reads the pending queues and sending records for each logical channel to determine the queue length, number of unacknowledged messages, current token count, and current sending window, enabling data from different service categories to be scheduled according to independent queues within the unified HID communication link.

[0047] like Figure 3 As shown, when the HID communication scheduler identifies that the HID service data to be sent belongs to the batch data in the batch transmission channel, it does not directly encapsulate the entire batch data into a single HID report for transmission. Instead, it continuously fragments the batch data according to the length of the HID report payload.

[0048] The HID report payload length represents the effective space that a single HID report can carry for business data. Based on this effective space, the HID communication scheduler sequentially extracts data segments starting from the beginning of the batch data, forming multiple batch data fragments.

[0049] After each batch of data fragments is generated, the HID communication scheduler writes fragment identification and verification fields to the fragments and establishes a batch transmission task using the batch task identifier. The batch transmission task saves the sending and acknowledgment status of each batch of data fragment. Subsequent sending, feedback processing, timeout retransmission, and breakpoint resume stages all read the fragment acknowledgment records in the batch transmission task to determine the fragment positions to continue sending or to retransmit.

[0050] In one embodiment, before performing batch data fragmentation, the HID communication scheduler reads the total length of the batch data, the current HID report payload length, and the length occupied by the service protocol header.

[0051] The HID report payload length can be determined by the HID report descriptor, communication protocol configuration, or HID device negotiation results. The length occupied by the service protocol header can be determined based on the byte size of protocol fields such as batch task identifier, fragment sequence number, acknowledgment identifier, fragment length, and checksum field. When determining the data length that a single batch data fragment can carry, the HID communication scheduler avoids mixing protocol header fields and valid service data in the calculation, ensuring that the device can parse each batch data fragment according to the fixed field positions.

[0052] Batch data can be firmware data, configuration file data, macro script data, or batch log export data. This type of data typically has characteristics such as large volume, high integrity requirements, and transmission time potentially spanning multiple scheduling cycles. Sending the entire data segment directly could easily exceed the length of a single HID report payload, and would also hinder recovery after timeouts or disconnections. Therefore, the HID communication scheduler divides batch data into multiple consecutive data segments according to the HID report payload length, ensuring that each data segment can be encapsulated into a single HID report.

[0053] The fragmentation process follows the byte order of the batch data in the original data. The HID communication scheduler starts fracturing from the beginning of the batch data, with the fracturing length limited to the valid data length that a single HID report can carry. When the current fracturing position reaches the end of the batch data, if the remaining data length is less than the valid data length that a single HID report can carry, the last batch data fragment only carries the remaining valid data. When the device receives the last batch data fragment, it reads the payload according to the fragment length field, avoiding the use of padding bytes as batch data content.

[0054] After batch data fragments are generated, the HID communication scheduler maintains the order relationship between each batch data fragment and the original batch data. The fragment sequence number and fragment offset together reflect the position of the batch data fragment within the original batch data. The fragment sequence number indicates the transmission order of the batch data fragments, and the fragment offset indicates the position of the corresponding original byte. After receiving the batch data fragments, the device can write the payload into the corresponding position in the receive buffer according to the fragment offset and verify the continuity of the reception order based on the fragment sequence number.

[0055] After fragmentation is completed, the HID communication scheduler does not immediately release the original batch data. Instead, it associates and saves the original batch data with the batch transmission task. In this way, if any batch data fragment experiences negative feedback, timeout, or disconnection and reconnection, the HID communication scheduler can relocate the original data range based on the fragmentation acknowledgment record and regenerate or retrieve the batch data fragments that need to be sent, ensuring that retransmissions and resumes have a consistent data source.

[0056] In one embodiment, the HID communication scheduler configures a batch task identifier, fragment sequence number, fragment offset, fragment length, acknowledgment identifier, and verification field for each batch of data fragments.

[0057] Batch task identifiers are used to distinguish different batch transmission tasks. A batch task identifier can be formed by combining the service command number, batch transmission channel number, batch data length, and task creation time, or it can be assigned an incrementing number within the batch transmission channel by the HID communication scheduler. After the batch task identifier is entered into each batch data fragment, the device can group batch data fragments with the same batch task identifier into the same receive buffer, preventing fragments from different batch transmission tasks from being mixed.

[0058] Fragment sequence numbers are used to mark the order of batch data fragments within the same batch transmission task. Fragment sequence numbers increment sequentially according to the fragment generation order. During the transmission phase, the HID communication scheduler selects fragments to be sent based on their fragment sequence numbers, while the device checks for missing or out-of-order fragments based on their fragment sequence numbers during the reception phase. If the device detects discontinuous fragment sequence numbers, it can prompt the host computer to retransmit the missing fragments via feedback from the service layer.

[0059] Fragment offsets are used to mark the starting position of batch data fragments within the original batch data. The fragment offset and fragment length together define the range of original data covered by the batch data fragments. When the device reassembles the batch data, it can write the batch data fragments to the corresponding buffer locations based on the fragment offset. When the HID communication scheduler performs retransmissions, it can also reread the same range from the original batch data based on the fragment offset, avoiding inconsistencies between the retransmitted content and the initial transmission due to queue reordering.

[0060] The fragment length is used to mark the actual length of valid business data carried by the current batch data fragment. Except for the last batch data fragment, the fragment length of each batch data fragment is usually consistent with the valid data length that a single HID report can carry. The fragment length of the last batch data fragment is determined based on the remaining data. The device reads the payload based on the fragment length and uses the checksum field to determine whether the current fragment is complete.

[0061] The acknowledgment flag indicates whether the current batch of data fragments requires feedback from the device to the service layer. For batch data requiring complete delivery, the acknowledgment flag is typically configured to require acknowledgment. For batch transmission tasks that allow acknowledgment by window aggregation, the acknowledgment flag can be configured on the fragment at the end of the window or the fragment at the end of the task. After entering the subsequent transmission phase, the acknowledgment flag is used to determine whether the HID communication scheduler establishes an unacknowledged fragment state and whether to start a timeout countdown.

[0062] The checksum field is used to verify the integrity of batch data fragments during transmission. The checksum field can be generated based on the payload, batch task identifier, fragment sequence number, and fragment length of the batch data fragments. Upon receiving the batch data fragments, the device performs verification according to the same checksum rules. If the verification matches, the device returns an acknowledgment; if the verification fails, the device returns a negative response. Upon receiving a negative response, the HID communication scheduler keeps the corresponding fragment in an unacknowledged state and retransmits it during subsequent retransmission phases.

[0063] The HID communication scheduler establishes batch transmission tasks based on batch task identifiers. Batch transmission tasks are used to centrally store the status of all fragments corresponding to the same batch of data. When a batch transmission task is created, the fragment sequence number, fragment offset, sent fragment position, acknowledged fragment position, and unacknowledged fragment position are written to the fragment acknowledgment record.

[0064] The "Sent Fragment Position" records the batch data fragments that have been submitted to the HID sending interface. When a batch transmission task is created, the "Sent Fragment Position" is in an unsent state. Each time a batch data fragment is encapsulated into an HID report and submitted for transmission, the HID communication scheduler updates the "Sent Fragment Position," enabling subsequent transmission phases to determine the next batch data fragment.

[0065] The confirmed fragment position is used to record the fragment positions for which acknowledgment feedback has been received. After receiving acknowledgment feedback, the HID communication scheduler updates the confirmed fragment position based on the batch task identifier and fragment sequence number in the feedback. If the fragment sequence number corresponding to the acknowledgment feedback is adjacent to a consecutive acknowledgment range, the confirmed fragment position is advanced. If the acknowledgment feedback crosses an intermediate unacknowledgment fragment, the HID communication scheduler can record that the fragment has been acknowledged, but the consecutive acknowledgment position will not cross the missing fragment.

[0066] The unacknowledged fragment location is used to record batch data fragments that have been sent but have not yet been acknowledged. After a batch data fragment is sent, the HID communication scheduler writes the corresponding fragment to the unacknowledged fragment location. Upon receiving an acknowledgment, the corresponding fragment is removed from the unacknowledged fragment location. When a negative feedback is received or a timeout occurs, the corresponding fragment remains in the unacknowledged fragment location for subsequent retransmission.

[0067] Fragment acknowledgment records are maintained throughout the entire lifecycle of a batch transmission task. During the sending phase, the positions of sent fragments are read to determine the next fragment to send; during the feedback processing phase, the positions of acknowledged and unacknowledged fragments are updated; during the timeout retransmission phase, the positions of unacknowledged fragments are read to determine the fragments to be retransmitted; and during the resume transmission phase after a connection failure and reconnection, the positions of acknowledged fragments are read to determine the start point for retransmission. After the batch transmission task is completed, the HID communication scheduler can write the final acknowledgment status to the task record and release the cached data associated with that batch transmission task.

[0068] like Figure 4 As shown, after the HID communication scheduler establishes a queue to be scheduled for multiple logical channels, it continuously maintains the operating metrics of each logical channel.

[0069] The operational metrics are comprised of the transmission log, the service layer feedback returned by the HID device, and the timeout log. The transmission log reflects the number of HID service data transmissions, transmission time, number of retransmissions, and number of unacknowledged messages; the service layer feedback reflects the device's acknowledgment, denial, or busy status; and the timeout log reflects situations where no feedback is received within a specified time after transmission.

[0070] The HID communication scheduler determines channel health and global rate limiting coefficients based on the operational metrics of each logical channel. Channel health is used to evaluate the current communication status of a single logical channel, while the global rate limiting coefficient is used to evaluate the congestion status of the entire HID communication link.

[0071] After completing the above judgment, the HID communication scheduler adjusts the token replenishment rate and transmission window of each logical channel, and selects the transmission logical channel from the logical channels that meet the transmission conditions. After the transmission logical channel is determined, the HID service data in its queue enters the subsequent HID report encapsulation and transmission stage.

[0072] In one embodiment, performance metrics are statistically analyzed separately for each logical channel. The HID communication scheduler maintains a transmission record table, a feedback record table, and a timeout table for each logical channel.

[0073] The sending record table stores the sending time, logical channel identifier, service type, whether acknowledgment is required, number of retransmissions, and current sending window occupancy status for each HID service data submission to the HID sending interface. The feedback record table stores the service layer feedback returned by the HID device and the feedback time. The timeout table stores the waiting start point, maximum waiting time, and timeout status for HID service data requiring acknowledgment.

[0074] The queue length is directly determined by the queue to be scheduled in the logical channel, reflecting the current queuing pressure of that logical channel. The response latency is determined by the difference between the transmission time and the feedback time, reflecting the response speed of the HID device to data transmission in that logical channel.

[0075] The timeout rate is determined by the number of transmissions that timed out within the statistical range, reflecting the proportion of transmissions that did not receive feedback from the service layer within the specified waiting time. The retransmission rate is determined by the number of retransmissions within the statistical range, reflecting the frequency of repeated data transmissions on this logical channel. The error rate is determined by abnormal results such as verification failures, fragment sequence number errors, command processing failures, or negative feedback, reflecting situations where data transmitted on this logical channel was rejected or could not be processed correctly by the device.

[0076] The device busy ratio is determined by the number of times the HID device returns a busy feedback message, reflecting whether the device's receive buffer or processing capacity is under strain. The number of unacknowledged messages is determined by data records that have been sent but have not yet received acknowledgment feedback, reflecting the degree to which the current logical channel occupies the sending window.

[0077] The current sending window represents the maximum number of messages that the logical channel is allowed to wait for acknowledgments in parallel. The current token count represents the token balance that the logical channel currently has available for sending. The current sending window and the current token count together determine whether the logical channel is eligible to send.

[0078] Operational metrics can be calculated based on a fixed time window or on a number of recent transmission samples. The fixed time window can be set based on the HID device feedback cycle and the host computer scheduling cycle; the number of recent transmission samples can be set based on the transmission frequency of the logical channel. When there are insufficient samples, the HID communication scheduler can use initialization metrics or use stable metrics from the previous statistical period to allow newly established logical channels to enter the scheduling process.

[0079] In one embodiment, channel health is determined based on error rate, timeout rate, retransmission rate, device busy ratio, and normalized response latency.

[0080] Normalized response latency is used to convert the response times of different logical channels to a unified comparison range. In one embodiment, normalized response latency can be represented as RttLevel, where the value of RttLevel is limited to between 0 and 1. Channel health can be represented as Health, which is determined according to the following relationship: Health = clamp(1 - a × ErrorRate - b × TimeoutRate - c × RetryRate - d × BusyRate - e × RttLevel, 0, 1). Where ErrorRate is the error rate, TimeoutRate is the timeout rate, RetryRate is the retransmission rate, BusyRate is the device busy ratio, RttLevel is the normalized response latency, and a, b, c, d, and e are the influence weights corresponding to the error rate, timeout rate, retransmission rate, device busy ratio, and response latency, respectively. clamp indicates that the calculation result is limited to a given value range. The above influence weights can be determined by default parameter tables, factory calibration, user configuration, or updates to historical communication records. Normalization can be performed based on the historical response delay range under normal communication conditions. When the response delay of a certain logical channel is close to the lower limit of the normal range, the normalized response delay takes the lower value; when the response delay is close to or exceeds the upper limit of the normal range, the normalized response delay takes the higher value.

[0081] Error rate, timeout rate, retransmission rate, device busy ratio, and normalized response latency are all factors that reduce channel health. The HID communication scheduler can combine these factors according to a pre-configured order of influence or weight of influence to form channel health. Error rate and timeout rate usually reflect data transmission failure or missing feedback, retransmission rate reflects the instability of link or device processing, device busy ratio reflects the processing pressure on the device, and normalized response latency reflects the channel response speed.

[0082] A higher channel health value indicates a more stable communication status for the logical channel within the current statistical period, allowing it to maintain a high transmission rate. A lower channel health value indicates more failures, timeouts, retransmissions, busy devices, or slow responses, requiring a reduction in the token replenishment rate or a smaller transmission window.

[0083] The global rate limiting coefficient is determined based on the average device busy ratio, average timeout rate, average retransmission rate, total queue pressure, and device buffer pressure of multiple logical channels.

[0084] In one embodiment, the HID communication scheduler can first determine the global congestion factor, GlobalCongestion, and then determine the global rate limiting coefficient, GlobalFactor, based on the global congestion factor. The global congestion factor can be determined according to the weighted result of the average device busy ratio, average timeout rate, average retransmission rate, total queue pressure, and device buffer pressure; the global rate limiting coefficient can be determined according to GlobalFactor=clamp(1-GlobalCongestion,MinFactor,1). Here, MinFactor is the lower limit of the global rate limiting coefficient, used to ensure that critical channels retain minimum transmission capacity. The weights of each item in the above weighted result can be configured according to the HID device buffer capacity, historical device busy feedback distribution, historical timeout distribution, and service real-time requirements, used to determine the degree of impact of different congestion factors on the global transmission rhythm.

[0085] The average device busy ratio, average timeout rate, and average retransmission rate are obtained by summing up the corresponding indicators of multiple logical channels, and are used to reflect the overall stability of the entire HID communication link within the current statistical period.

[0086] The total queue pressure is determined by the queue lengths of multiple logical channels. An overall increase in queue length indicates a backlog of data to be sent on the host computer side. If there is also a high device busy ratio or a high timeout rate, it means that further increasing the sending rate may further increase the burden on the device side.

[0087] Device buffer pressure is determined by the device busy ratio and the number of unacknowledged messages. The device busy ratio reflects the busy status actively returned by the device, while the number of unacknowledged messages reflects the scale of data that has been delivered but not yet acknowledged by the host computer. Together, they are used to determine whether the device's receive buffer or processing link is close to saturation.

[0088] After determining the global rate limiting coefficient, the HID communication scheduler uses it as a unified constraint for sending messages across all logical channels. When the global rate limiting coefficient is high, each logical channel can replenish tokens normally according to its own channel health and priority; when the global rate limiting coefficient is low, the token replenishment rate of each logical channel is compressed, and the sending window can also shrink accordingly, thereby reducing the number of unacknowledged messages entering the HID link at the same time.

[0089] In one embodiment, the HID communication scheduler configures a logical channel priority for each logical channel. The logical channel priority is used to represent the relative transmission order when different service categories contend for the same HID communication link.

[0090] Control and alarm channels are typically configured with high logical channel priority to ensure that control and alarm data are sent as early as possible when transmission conditions are met. Bulk transmission channels can be configured with medium logical channel priority to ensure continuous delivery of bulk data, but will yield transmission opportunities when control or alarm data arrives. Log channels are typically configured with low logical channel priority to reduce transmission frequency when the link is congested.

[0091] The token replenishment rate is determined by the channel health, the global rate limiting coefficient, and the logical channel priority.

[0092] In one embodiment, the token replenishment rate can be represented as TokenRate, which is determined jointly by the base replenishment rate, logical channel priority weight, channel health, and global rate limiting coefficient. The token replenishment rate can be determined as TokenRate = BaseRate × PriorityWeight × Health × GlobalFactor. Where BaseRate is the base replenishment rate, PriorityWeight is the logical channel priority weight, Health is the channel health, and GlobalFactor is the global rate limiting coefficient.

[0093] Logical channels with high channel health, high global rate limiting coefficient, and high logical channel priority can obtain faster token replenishment. When the channel health is low or the global rate limiting coefficient is low, the HID communication scheduler reduces the token replenishment rate of the corresponding logical channel, thus reducing the chance of that logical channel entering the transmission phase.

[0094] The sending window is used to limit the number of unacknowledged messages in a single logical channel. The HID communication scheduler adjusts the sending window based on channel health and service layer feedback. When acknowledgment feedback is continuous and stable, the sending window can be maintained or appropriately expanded; when negative feedback, timeout states, busy device feedback, or retransmission states increase, the sending window shrinks. After the sending window shrinks, the number of data waiting for acknowledgment in parallel on the same logical channel decreases, thereby reducing the pressure on the link and device-side receive buffer.

[0095] The current sending window is adjusted between a preset minimum window and a preset maximum window. When acknowledgment feedback is continuous and stable and the channel health is higher than the window expansion threshold, the HID communication scheduler increases the current sending window. When negative feedback, timeout status, device busy feedback, or channel health is lower than the window shrinking threshold occurs, the HID communication scheduler decreases the current sending window, ensuring that the adjusted current sending window is not lower than the preset minimum window. The window expansion threshold and window shrinking threshold are determined by the historical acknowledgment feedback distribution, the HID device buffer capacity, or user configuration.

[0096] When the HID communication scheduler filters candidate logical channels, it checks both the number of unacknowledged messages and the current number of tokens. If the number of unacknowledged messages is less than the current sending window, it means that the logical channel still has sending capacity; if the current number of tokens is greater than zero, it means that the logical channel is eligible to send in this round. Only logical channels that meet both of these conditions will be included in the candidate logical channel set.

[0097] Once candidate logical channels are determined, the HID communication scheduler assigns a transmission score based on the logical channel priority, waiting time, queue pressure determined by queue length, congestion status determined by timeout rate, retransmission rate, error rate, and device busy ratio, and retry status determined by transmission records. Logical channel priority reflects the urgency of the service; waiting time can be determined by the enqueue time in the queue and the current scheduling time; queue pressure reflects the backlog of data to be transmitted; congestion status suppresses abnormally congested channels from continuing to transmit; and retry status prevents retry data from blocking other services for extended periods.

[0098] When determining the transmission score, the HID communication scheduler considers logical channel priority, waiting time, and queue pressure as positive factors to improve the transmission score, and congestion and retry status as negative factors to decrease the transmission score. Higher logical channel priority, longer waiting time, or greater queue pressure result in a higher transmission score for the corresponding candidate logical channel; conversely, higher timeout rates, retransmission rates, error rates, or higher device busy ratios, or when transmission records show the candidate logical channel is in a continuous retry state, result in a lower transmission score for the corresponding candidate logical channel. The order of influence of positive and negative factors can be determined by service real-time requirements, historical transmission records, HID device buffer capacity, or user configuration.

[0099] After the transmission score is generated, the HID communication scheduler determines the candidate logical channel with the highest transmission score as the transmission logical channel. If multiple candidate logical channels have the same transmission score, one of them can be selected based on logical channel priority, waiting time, or fixed channel order.

[0100] Once the logical channel is determined, the HID communication scheduler retrieves HID service data from the scheduling queue of that logical channel. If the retrieved HID service data is batch data, subsequent stages select batch data fragments to be sent according to the fragmentation confirmation record; if the retrieved HID service data is control data, status data, high-frequency data, alarm data, or log data, subsequent stages encapsulate and send HID reports according to their scheduling attributes.

[0101] After determining the transmission logical channel, the HID communication scheduler reads the HID service data to be transmitted in this round from the scheduling queue of the transmission logical channel.

[0102] The reading process is performed in conjunction with the scheduling attributes carried by the HID service data. If the HID service data is ordinary control data, status data, high-frequency data, alarm data, or log data, the HID communication scheduler directly encapsulates it according to the corresponding service protocol fields. If the HID service data is batch data, the HID communication scheduler reads the fragment acknowledgment record in the batch transmission task and selects the batch data fragment that needs to be sent.

[0103] The HID communication scheduler writes the data to be sent into the HID report payload area and configures the report number, logical channel identifier, service type information, confirmation requirement information and necessary verification fields in the HID report.

[0104] After the HID report is encapsulated, the HID communication scheduler submits the HID report to the HID sending interface and records the sending time, sending logical channel, sending data identifier, and whether feedback from the business layer is required. The sending record enters the subsequent operational metric statistics stage, used to update response latency, number of unacknowledged messages, retransmission rate, and current sending window occupancy.

[0105] In one embodiment, when the HID communication scheduler retrieves HID service data from the transmission logic channel, it performs a consistency check on the queue to be scheduled.

[0106] Consistency checks are used to confirm that the data to be sent still meets the sending conditions. The HID communication scheduler reads the head data of the queue to be scheduled or the data currently selected by the score, and checks whether the current token count is still greater than zero, whether the number of unacknowledged messages is still less than the current sending window, and whether the data to be sent has been overwritten or canceled.

[0107] For data that is allowed to be overwritten, if updated data for the same business object exists in the queue, the HID communication scheduler can discard the old data and retrieve the updated data. For data that is not allowed to be overwritten, the HID communication scheduler maintains the original enqueue order to avoid loss of control commands or batch data fragments.

[0108] After retrieving the HID service data, the HID communication scheduler determines the encapsulation method based on the service type. Control data typically carries the command number, command parameters, and confirmation requirements; status data typically carries the status object identifier and status value; high-frequency data typically carries short-cycle input values ​​or sensor sampling values; alarm data typically carries the alarm category, alarm source, and alarm trigger time; and log data typically carries the log level, log content fragment, and log sequence number.

[0109] The processing method for batch data differs from that for ordinary business data. The HID communication scheduler does not directly retrieve the entire batch data segment, but instead reads the fragment acknowledgment records in the batch transmission task. If there are unacknowledged fragments that need to be retransmitted, these unacknowledged fragments are retrieved first; if there are no fragments that need to be retransmitted, the next untransmitted batch data fragment is selected based on the position of the already sent fragments.

[0110] The selected batch data fragments enter the HID report encapsulation stage, carrying the batch task identifier, fragment sequence number, fragment offset, fragment length, acknowledgment identifier, and checksum field. This allows the HID device to identify which batch transmission task the report belongs to and write the fragment payload to the corresponding receive buffer location.

[0111] In one embodiment, the HID report encapsulation process is performed according to the report structure supported by the HID device.

[0112] The HID communication scheduler first determines the HID report number. The HID report number can be determined by the service type, logical channel type, or the report type defined in the HID report descriptor. If the HID device defines different report numbers for different service types, the HID communication scheduler selects the corresponding report number according to the service type; if multiple service types share the same report number, the logical channel identifier and service type information are written into the HID report payload for differentiation.

[0113] The HID report payload area is used to write actual business data. Regular business data can be written directly to the payload area; for batch data fragments, both the fragment header field and the valid fragment data are written to the payload area. The fragment header field includes the batch task identifier, fragment sequence number, fragment offset, fragment length, and acknowledgment identifier. The valid fragment data is the business data content carried by the current batch data fragment.

[0114] The confirmation request information indicates whether the HID communication scheduler needs to wait for feedback from the HID device at the service layer after sending. This confirmation request information can originate from scheduling attributes or from the confirmation flag in the batch data fragments. If the current HID report requires confirmation, the HID communication scheduler creates an unconfirmed message record and starts a timeout countdown after submitting the send interface. If the current HID report does not require confirmation, the HID communication scheduler marks it as requiring no feedback in the send record and releases the corresponding queue after sending is complete.

[0115] The checksum field assists HID devices in checking the integrity of the HID report payload. The checksum field can be generated using a checksum algorithm configured in the protocol or a checksum method agreed upon by the device. After the checksum field is written to the HID report, the HID device performs verification according to the same rules upon reception. If verification fails, the HID device can return negative feedback, and the HID communication scheduler will then include the corresponding data in the retransmission process.

[0116] In one embodiment, the HID communication scheduler submits the encapsulated HID report to the HID sending interface.

[0117] Before submitting the sending interface, the HID communication scheduler checks the connection status of the HID device. If the HID device is in an unconnected, suspended, or writable state, the HID report will not submit the sending interface in this round, and the data to be sent will remain in the original logical channel or batch transmission task, and the link unavailability status will be recorded. After the link is restored, the HID communication scheduler will re-participate in the selection of the sending logical channel.

[0118] After receiving the HID report, the HID transmission interface records the transmission time, report number, logical channel identifier, service data identifier, batch task identifier, and fragment sequence number. For non-batch data, the service data identifier can be determined by the command number, status object identifier, alarm number, or log sequence number. For batch data, the batch task identifier and fragment sequence number together constitute the transmission data identifier.

[0119] The transmission record is used for subsequent statistical analysis of response latency, timeout rate, retransmission rate, and the number of unacknowledged messages. If the current HID report requires acknowledgment, the HID communication scheduler synchronously writes the transmission record into the unacknowledged message record and increases the current transmission window size. After the HID device returns acknowledgment feedback, the unacknowledged message record is cleared, and the current transmission window size decreases. When the HID device returns negative feedback, device busy feedback, or the timeout count reaches the waiting limit, the transmission record enters the retransmission judgment stage.

[0120] For batch transmission tasks, the HID communication scheduler updates the position of sent fragments after submitting the HID report to the sending interface. If the current batch data fragment requires acknowledgment, the fragment simultaneously enters the unacknowledged fragment position. If acknowledgment feedback is subsequently received, the position of the acknowledged fragment advances with the feedback result; if negative feedback is subsequently received or a timeout occurs, the position of the unacknowledged fragment remains unchanged and is used to determine retransmission fragments in subsequent transmission rounds.

[0121] After the HID report is sent, the HID communication scheduler deducts the current token count for the transmission logical channel and saves the transmission result for this round. This transmission result is used in the calculation of operational metrics for the next statistical cycle, enabling subsequent channel health, global rate limiting coefficient, token replenishment rate, and transmission window to be updated based on actual transmission conditions.

[0122] When the HID communication scheduler is a batch transmission channel, it performs feedback tracking on the already transmitted batch data fragments.

[0123] After the batch data fragments are encapsulated into HID reports and submitted to the sending interface, the HID communication scheduler saves the sending time, fragment sequence number, batch task identifier, and unacknowledged status in the batch transmission task, and starts the corresponding feedback waiting timer.

[0124] After the HID device returns feedback from the service layer, the HID communication scheduler parses the batch task identifier and fragment sequence number in the feedback to locate the corresponding batch transmission task and batch data fragment. Service layer feedback can be divided into acknowledgment feedback, negative feedback, and device busy feedback.

[0125] If no feedback is received from the business layer within the maximum waiting time, the HID communication scheduler will record the corresponding batch of data fragments as timeout.

[0126] The HID communication scheduler updates the fragment acknowledgment record based on service layer feedback, timeout status, or disconnection / reconnection status. Acknowledgment feedback is used to advance the position of the acknowledged fragment; negative feedback and timeout status are used to trigger retransmission of unacknowledged fragments; device busy feedback and disconnection / reconnection status are used to pause the current continuous transmission and determine the start point for retransmission based on the position of the acknowledged fragment.

[0127] In one embodiment, the acknowledgment feedback is returned by the HID device after successfully receiving and verifying the batch data fragments. The acknowledgment feedback carries the batch task identifier and fragment sequence number, and may also carry the position of the fragments that the device has continuously received.

[0128] After receiving the acknowledgment feedback, the HID communication scheduler reads the batch task identifier and locates the corresponding batch transmission task. If the batch task identifier does not exist, it indicates that the feedback may come from a batch transmission task that has already ended or been released. The HID communication scheduler can discard the feedback and record the abnormal feedback event. If the batch task identifier exists, the HID communication scheduler continues to read the fragment sequence number and locates the corresponding batch data fragment in the fragment acknowledgment record.

[0129] After location is established, the HID communication scheduler marks the batch data fragments indicated by the acknowledgment feedback as acknowledged fragments. This marking indicates that the batch data fragments have been received by the HID device and passed service layer verification, and do not need to be sent again. The corresponding fragments are removed from the unacknowledged fragments list, and the number of unacknowledged messages decreases accordingly.

[0130] The confirmed fragment position is used to represent the boundary of consecutively confirmed fragments in a batch transmission task. When updating the confirmed fragment position, the HID communication scheduler not only determines whether the current fragment has received confirmation feedback, but also checks whether there are still unconfirmed fragments before this fragment. If the fragment sequence number corresponding to the current confirmation feedback is exactly after the consecutive confirmation boundary, the confirmed fragment position is advanced. If the fragment sequence number corresponding to the current confirmation feedback crosses an intermediate unconfirmed fragment, the HID communication scheduler only records that the current fragment has been confirmed, but the consecutive confirmation boundary is not crossed beyond the missing position.

[0131] Using the above method, the confirmed fragment positions can stably represent the continuous confirmation range that can be used as the basis for resuming transmission. In the event of subsequent disconnection and reconnection or device busy recovery, the HID communication scheduler does not need to resend the already continuously confirmed batch data fragments; it can directly determine the resuming start point from after the continuous confirmation range.

[0132] After the confirmation feedback is processed, the HID communication scheduler updates the batch transmission task status. If all batch data fragments have been confirmed, the batch transmission task enters the completed state, and the associated cached data and unconfirmed records can be released. If there are still unsent or unconfirmed fragments, the batch transmission task remains running, waiting for subsequent scheduling rounds to continue sending.

[0133] In one embodiment, negative feedback is returned by the HID device when it detects an anomaly after receiving batch data fragments. The anomaly may be inconsistent verification fields, discontinuous fragment sequence numbers, abnormal fragment offsets, mismatched fragment lengths, or failure of device-side service processing.

[0134] Upon receiving a negative feedback, the HID communication scheduler locates the batch data fragments based on the batch task identifier and fragment sequence number in the feedback. If the location is successful, the HID communication scheduler does not advance the confirmed fragment position but retains the fragment in the unconfirmed fragment position and records the reason for the negative feedback. If the negative feedback does not carry a specific fragment sequence number, the HID communication scheduler can determine the retransmission starting point based on the earliest unconfirmed fragment position in the batch transmission task.

[0135] The timeout status is generated by the HID communication scheduler on the host computer side. After a batch of data fragments is sent, if the fragment requires confirmation from the device, the HID communication scheduler records the sending time and starts a waiting timer. If no confirmation, negative feedback, or device busy feedback is received after the waiting time reaches the corresponding maximum waiting time, the HID communication scheduler marks the corresponding batch of data fragments as timeout.

[0136] Negative feedback and timeout status are both used to trigger retransmission. The HID communication scheduler reads the unacknowledged fragment positions in the fragment acknowledgment record to determine the batch data fragments that have been sent but have not yet been acknowledged. During retransmission, the HID communication scheduler prioritizes the batch data fragment with the highest sorted position among the unacknowledged fragment positions, so that the batch transmission task maintains a continuous acknowledgment boundary as much as possible.

[0137] The retransmitted batch data fragments still use the original batch task identifier, original fragment sequence number, original fragment offset, and original fragment length. When the HID communication scheduler repackages the HID report, it can either regenerate the checksum field or use the same checksum field as the original fragment content. If the batch data fragment content has not changed, the device can still write the retransmitted fragments to the original receive buffer location based on the same fragment sequence number and fragment offset.

[0138] The number of retransmissions is constrained by the retry count in the scheduling attributes. Each time the HID communication scheduler performs a retransmission, it updates the retransmission record for the corresponding fragment. If the retransmission count has not reached the upper limit, the fragment continues to participate in subsequent transmissions within the batch transmission task. If the upper limit is reached and acknowledgment is still not obtained, the HID communication scheduler can mark the batch transmission task as an abnormal task and stop subsequent fragment transmissions to prevent abnormal tasks from occupying the batch transmission channel for an extended period.

[0139] In one embodiment, the device busy feedback is returned by the HID device when the receive buffer is insufficient, the service processing thread is busy, or the current batch transmission task is temporarily unable to continue receiving. Device busy feedback does not necessarily indicate that the batch data fragment content is incorrect, but rather that the device is temporarily unsuitable to continue receiving new batch data fragments.

[0140] After receiving busy feedback from the device, the HID communication scheduler reads the batch task identifier in the feedback and locates the corresponding batch transmission task. For batch data fragments that have received acknowledgment feedback, the HID communication scheduler retains the acknowledged status. For batch data fragments that have been sent but not yet acknowledged, the HID communication scheduler continues to retain the unacknowledged fragment position and does not misclassify them as acknowledged fragments.

[0141] Upon triggering a device busy feedback, the HID communication scheduler can suspend the continuous transmission of the batch transmission task and reduce the transmission opportunity of the batch transmission channel in subsequent scheduling rounds. The pause time can be determined based on the suggested waiting time carried in the device busy feedback, or based on the historical device busy feedback interval, the HID device buffer capacity, and the current number of unacknowledged messages. During the pause, the control channel, alarm channel, or other logical channels that meet the transmission conditions can still participate in scheduling.

[0142] When a disconnection and reconnection occur, the HID communication scheduler restores the transmission status based on the acknowledged fragment positions saved in the batch transmission task. Batch data fragments that were sent during the disconnection but for which no acknowledgment feedback has been received cannot be treated as acknowledged data and remain in the unacknowledged fragment position. After reconnection is complete, the HID communication scheduler reads the acknowledged fragment positions and determines the first incomplete fragment after the acknowledged fragment position as the start point for resuming transmission.

[0143] The resume start point is used to determine the starting fragment when the batch transmission task resumes transmission. If there are unacknowledged fragment positions in the fragment acknowledgment record, the HID communication scheduler can resume transmission from the earliest unacknowledged fragment position. If there are no unacknowledged fragment positions but there are still unsent fragments, the HID communication scheduler continues transmission from the next fragment after the acknowledged fragment position. If all fragments have been acknowledged, the batch transmission task directly enters the completion state.

[0144] During the reconnection process, the HID communication scheduler continues to use the original batch task identifier, enabling the HID device to fragment the reconnected batch data into the same receive buffer. If the HID device loses its original receive buffer after a disconnection and reconnection, the HID device can return a negative result or request a retransmission through feedback from the service layer. Upon receiving such feedback, the HID communication scheduler can retransmit fragments from the beginning of the batch transmission task, or re-determine the start point for reconnection based on the received position indicated by the device. This process allows the batch transmission task to resume the transmission process based on the fragment acknowledgment record in scenarios such as device busyness, missing feedback, and link disconnection.

[0145] In one embodiment, the electronic device may be a host computer device, an embedded control device, an industrial control terminal, or other computing device capable of communicating with the HID device.

[0146] The electronic device includes a processor, memory, and an HID communication interface. The memory stores computer programs, logical channel configuration data, batch transmission task records, and fragmentation confirmation records. When the processor executes the computer program, it interacts with the HID device through the HID communication interface and executes the aforementioned HID batch data fragmentation and retransmission scheduling method.

[0147] When the processor executes the computer program, it receives HID service data to be sent, schedules logical channels, performs batch data fragmentation, maintains fragmentation confirmation records, performs operational indicator statistics, controls the sending window, and processes service layer feedback. Based on confirmation feedback, negative feedback, device busy feedback, timeout status, or disconnection and reconnection status, it completes the confirmation, retransmission, and resumption of batch data fragmentation.

[0148] Therefore, electronic devices can realize HID service data channel scheduling, batch data fragment transmission, fragment confirmation record maintenance, and breakpoint resume and retransmission control.

[0149] In one embodiment, a computer-readable storage medium stores a computer program. When executed by a processor, the computer program causes the electronic device to perform the HID batch data fragmentation and retransmission scheduling method described above.

[0150] After the computer program is executed, it realizes the reception of HID service data to be sent, logical channel scheduling, batch data fragmentation, fragmentation confirmation record maintenance, operation indicator statistics, transmission window control, and service layer feedback processing. Based on the confirmation feedback, negative feedback, device busy feedback, timeout status, or disconnection and reconnection status, it completes the confirmation, retransmission, and resumption of batch data fragmentation.

[0151] Therefore, once the computer program in the computer-readable storage medium is executed, it enables electronic devices to perform multi-logic channel scheduling and batch data fragmentation and retransmission control in HID communication links.

[0152] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0153] The various embodiments in this invention are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

Claims

1. A method for scheduling batch data fragmentation and retransmission in HID, characterized in that, The method includes: Obtain the HID service data to be sent and the scheduling attributes, and write the HID service data to be sent into multiple logical channels including a batch transmission channel according to the scheduling attributes; When the HID service data to be sent is batch data, it is fragmented according to the HID report payload length to obtain batch data fragments, and a fragmentation confirmation record is established. The channel health and global rate limiting coefficient are determined based on the operating indicators of each logical channel, and the token replenishment rate and sending window are adjusted based on the channel health and the global rate limiting coefficient to determine the sending logical channel; Take out the HID service data to be sent from the sending logical channel, or when the sending logical channel is the batch transmission channel, select the batch data fragments to be sent according to the fragmentation confirmation record, and encapsulate them into an HID report for sending; When the sending logic channel is the batch transmission channel, the fragment confirmation record is updated according to the service layer feedback, timeout status, or disconnection and reconnection status to continue or retransmit the batch data fragments.

2. The method according to claim 1, characterized in that, The scheduling attributes include a service type identifier, a confirmation request identifier, an overlay permission identifier, a maximum waiting time, a fragment size, a number of retries, and a service priority. The step of writing the HID service data to be sent into multiple logical channels, including a batch transmission channel, according to the scheduling attributes includes: The logical channel to which the HID service data to be sent belongs is determined based on the service type identifier, and the HID service data to be sent, along with the confirmation request identifier, the coverage permission identifier, the maximum waiting time, the fragment size, the number of retries, and the service priority, are written into the scheduling queue in the logical channel.

3. The method according to claim 1, characterized in that, The multiple logical channels include a control channel, a status channel, a high-frequency data channel, a batch transmission channel, an alarm channel, and a log channel; The control channel is used to write control data, the status channel is used to write status data, the high-frequency data channel is used to write high-frequency data, the batch transmission channel is used to write batch data, the alarm channel is used to write alarm data, and the log channel is used to write log data.

4. The method according to claim 1, characterized in that, The establishment of the fragment confirmation record includes: Configure each batch data shard with a batch task identifier, shard number, shard offset, shard length, confirmation identifier, and verification field; A batch transmission task is established based on the batch task identifier, and the fragment sequence number, fragment offset, sent fragment position, confirmed fragment position, and unconfirmed fragment position are written into the fragment confirmation record of the batch transmission task.

5. The method according to claim 1, characterized in that, The operational metrics include queue length, response latency, timeout rate, retransmission rate, error rate, device busy ratio, number of unacknowledged messages, current sending window, and current number of tokens. The operational metrics are determined based on the transmission records of the multiple logical channels, service layer feedback from the HID device, and timeout records, and are used to determine the channel health and the global rate limiting coefficient.

6. The method according to claim 5, characterized in that, The process of determining the channel health and global rate limiting coefficient based on the operational metrics of each logical channel includes: The channel health is determined based on the error rate, timeout rate, retransmission rate, device busy ratio, and normalized response latency. The global rate limiting coefficient is determined based on the average device busy ratio, average timeout rate, average retransmission rate of the multiple logical channels, the total queue pressure determined by the queue length, and the device buffer pressure determined by the device busy ratio and the number of unacknowledged messages.

7. The method according to claim 5, characterized in that, The adjustment of the token replenishment rate and sending window, and the determination of the sending logical channel, include: Configure a logical channel priority for each logical channel, and determine the token replenishment rate of the multiple logical channels based on the channel health, the global rate limiting coefficient, and the logical channel priority; The current sending window is adjusted based on the channel health status and the service layer feedback; The logical channel with the number of unconfirmed messages being less than the current sending window and the current number of tokens being greater than zero is identified as a candidate logical channel; A transmission score is determined based on the logical channel priority of the candidate logical channel, the waiting time determined by the enqueue time of the HID service data to be sent in the candidate logical channel and the current scheduling time, the queue pressure determined by the queue length, the congestion state determined by the timeout rate, the retransmission rate, the error rate and the device busy ratio, and the retry state determined by the transmission record. The candidate logical channel with the highest transmission score is then determined as the transmission logical channel.

8. The method according to claim 4, characterized in that, The step of updating the fragment confirmation record based on business layer feedback, timeout status, or disconnection and reconnection status to resume or retransmit the batch data fragments includes: The business layer feedback includes confirmation feedback, negative feedback, and device busy feedback; If the business layer provides a confirmation response, the batch data shard indicated by the confirmation response is marked as a confirmed shard, and the position of the confirmed shard is updated. If the business layer provides negative feedback, or if no feedback is received from the business layer and a timeout occurs, the unacknowledged batch data fragments are retransmitted according to the unacknowledged fragment location. If the service layer reports that the device is busy or a disconnection and reconnection has occurred, the start point for resuming transmission is determined based on the confirmed fragment position, and the batch data fragments are continued to be sent from the start point.

9. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the method of any one of claims 1 to 8.

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

Images