A method for constructing a custom message analysis and transmission protocol for KVM remote control

Abstract

This invention discloses a method for constructing a custom message parsing and transmission protocol for KVM remote control, relating to the field of KVM remote control communication protocol technology. Compared with existing KVM hardware proprietary protocols, this invention adopts a two-level encoding system of type code + behavior code to classify instructions hierarchically according to functional modules. Adding new instructions only requires extending the behavior code under the corresponding type, eliminating cross-module encoding conflicts and significantly improving the extensibility and maintainability of the protocol. At the same time, through independently encapsulated serialization and deserialization tool layers and behavior code mapping table distribution mechanism, complete decoupling of protocol parsing logic and business logic is achieved. The protocol tool library only depends on the standard C++ library and can be quickly ported to different platforms such as Windows, Linux, and embedded ARM.

Description

Technical Field

[0001] This invention relates to the field of KVM remote control communication protocol technology, and in particular to a method for constructing a custom message parsing and transmission protocol for KVM remote control. Background Technology

[0002] KVM (Keyboard, Video, Mouse) remote control technology enables BIOS-level remote operation and maintenance by acquiring video signals and simulating USB keyboard and mouse input on the controlled device at the hardware level, without relying on an operating system. It is widely used in out-of-band management of data centers, industrial control, and unattended equipment. Currently, KVM remote transmission solutions fall into two categories: one is based on general remote desktop protocols (such as VNC, RDP, SPICE), relying on the graphical subsystem of the controlled operating system. This has inherent limitations such as high latency and inability to handle pre-operational operations, making it unsuitable for hardware-level control. The other category consists of proprietary binary protocols customized by hardware manufacturers, which transmit commands through custom messages and are the mainstream solution for professional KVM over IP products. However, existing proprietary hardware protocols generally adopt a flat structure of frame header + command type + data field + checksum, which has significant deficiencies in protocol scalability, maintainability, and transmission reliability.

[0003] For example, patent application CN105681398A discloses a method, encoding box, and system for KVM remote control. The client sends KVM messages to the master server, which forwards them to the encoding box. The encoding box simulates keyboard or mouse operations via an external USB cable to achieve KVM functionality. The core objective is to address the security risks associated with installing a KVM message processing application on the user's target PC in traditional solutions. However, this technical solution focuses on improving the overall system architecture and security of KVM remote control, without disclosing the specific definition of a custom binary frame structure, nor does it address a two-level encoding system combining type and action codes, a unified protocol-level unpacking and dual-verification mechanism, a serialization / deserialization framework independent of business logic, or a request-response mapping and timeout retransmission mechanism based on instruction sequence numbers.

[0004] Patent application CN102204184A discloses a method, service board, and system for KVM data transmission. In this technical solution, the service board converts KVM data into KVM packet messages and sends them to the switching board via a BASE channel, which then forwards them to the remote control console. The core of this solution lies in implementing KVM data transmission based on the ATCA (Advanced Telecom Computing Architecture) architecture, aiming to provide a channel with sufficient bandwidth for KVM data while ensuring compatibility with existing ATCA systems. However, this prior art focuses on the data transmission channel design under the ATCA architecture. The format definition of the KVM packet messages is completely different from the six-field binary frame structure proposed in this invention, which includes a type code, action code, instruction sequence number, length field, data field, and check bit. Furthermore, this document does not address the layered encoding system of application layer instructions, the decoupling method between protocol parsing and business logic, or a reliable transmission mechanism for KVM remote control scenarios. Summary of the Invention

[0005] The purpose of this section is to outline some aspects of the embodiments of the present invention and to briefly introduce some preferred embodiments. Some simplifications or omissions may be made in this section, as well as in the abstract and title of the present application, to avoid obscuring the purpose of this section, the abstract and title of the invention. Such simplifications or omissions shall not be used to limit the scope of the present invention.

[0006] In view of the aforementioned existing problems, the present invention is proposed.

[0007] Therefore, the technical problem solved by this invention is: the poor scalability of existing KVM hardware proprietary protocols, the high coupling between protocol parsing and business logic, the insufficient reliability of TCP transmission, and the lack of asynchronous instruction tracing.

[0008] To address the aforementioned technical problems, this invention provides the following technical solution: a method for constructing a custom message parsing and transmission protocol for KVM remote control, characterized by: constructing a binary frame structure containing a type code, behavior code, instruction sequence number, length field, data field, and checksum, wherein the data field supports a single instruction or multiple sub-instructions stored consecutively; classifying instructions based on a two-level encoding system composed of type code and behavior code, encoding single or multiple instructions into the data field and generating a binary byte stream for transmission; disassembling the TCP stream based on the length field, performing dual verification of length and checksum on each split frame, and filtering abnormal messages; parsing the verified messages into structured instruction objects, and sequentially disassembling the consecutively stored messages according to the sub-instruction structure, distributing them to the corresponding business logic according to the behavior code; associating requests and responses through instruction sequence numbers, establishing a mapping table with time records, periodically inspecting the mapping table, triggering retransmission for requests that have not been responded to within a timeout period, and clearing the mapping entries after the response reaches or reaches the retransmission limit.

[0009] As a preferred embodiment of the present invention, in the binary frame structure, the type code occupies 1 byte, the line code occupies 1 byte, the instruction sequence number occupies 1 byte, the length field occupies 1 byte, and the check bit occupies 1 byte and adopts XOR check. The XOR check range is all bytes from the start of the type code to the end of the data field.

[0010] In a preferred embodiment of the present invention, the type code uses a first value to identify the control command issuance class and a second value to identify the device response reporting class; under the control command issuance class, the behavior code uses a third value range to correspond to keyboard and mouse control, a fourth value range to correspond to video configuration, and a fifth value range to correspond to device management; under the device response reporting class, the behavior code uses a sixth value range to correspond to execution result response, a seventh value range to correspond to status information response, and an eighth value range to correspond to network heartbeat response.

[0011] In a preferred embodiment of the present invention, when serializing the absolute coordinate command of the mouse, the floating-point X coordinate value is multiplied by a preset quantization coefficient and converted into a 16-bit unsigned integer and written into the data field, and the floating-point Y coordinate value is multiplied by the quantization coefficient and converted into a 16-bit unsigned integer and written into the data field.

[0012] In a preferred embodiment of the present invention, when parsing a message that has passed verification, the value of the action code field is read, and a deserialization method matching the value is called to restore the structured data from the binary stream according to the byte length definition of each field in the data field; when constructing the serialization, the action code value of the instruction is read, and a serialization method matching the value is called to convert the structured data into a binary stream according to the frame format.

[0013] In a preferred embodiment of the present invention, the multiple sub-instructions stored consecutively are arranged sequentially in the data field according to the sending order. Each sub-instruction header contains a sub-line code and a sub-length field. When parsing, the receiving end reads the sub-length field sequentially and extracts the complete data of each sub-instruction from the data field according to the value of the sub-length field.

[0014] In a preferred embodiment of the present invention, each record in the mapping table includes an instruction sequence number, a sending timestamp, and a retransmission count; during retransmission, the instruction sequence number remains unchanged, and the response message carries the instruction sequence number of the requested response; during periodic inspection, the difference between the current time and the sending timestamp is compared with a preset timeout threshold; if a timeout occurs and the retransmission count has not reached the upper limit, the original instruction is retransmitted and the retransmission count is incremented; if a timeout occurs and the retransmission count has reached the upper limit, a timeout failure message is returned to the upper layer and the mapping record is deleted; if a response is received, the mapping record is searched and deleted based on the instruction sequence number carried in the response.

[0015] In a preferred embodiment of the present invention, when disassembling a TCP stream based on a length field, the received data is appended to the end of the buffer. The value of the length field is read from the starting position of the current valid data in the buffer, and the value of the length field is added to the fixed number of bytes in the frame header to obtain the complete frame length. It is checked whether the length of the valid data in the buffer is greater than or equal to the length of the complete frame. If it is, the complete frame is truncated from the starting position of the buffer, and a double check of length and check bit is performed. If the check passes, the truncated data is removed, and the remaining data in the buffer is moved forward to the starting position of the buffer. If the check fails, the current frame header position is abandoned, the starting position of the current valid data in the buffer is shifted backward by one byte, and the length field is read again from the new starting position, and the disassembly and check process is repeated. If the valid data in the buffer is less than 4 bytes or less than the length of the complete frame, the current state of the buffer is maintained and the subsequent data is allowed to arrive.

[0016] The beneficial effects of this invention are as follows: Compared with existing KVM hardware proprietary protocols, this invention adopts a two-level encoding system of type code + behavior code to classify instructions hierarchically according to functional modules. Adding new instructions only requires extending the behavior code under the corresponding type, without cross-module encoding conflicts, which significantly improves the extensibility and maintainability of the protocol. At the same time, through the independently encapsulated serialization and deserialization tool layer and behavior code mapping table distribution mechanism, the protocol parsing logic and business logic are completely decoupled. The protocol tool library only depends on the standard C++ library and can be quickly ported to different platforms such as Windows, Linux and embedded ARM.

[0017] At the transmission layer, the TCP streaming adaptive packet splitting mechanism based on the length field, combined with dual verification of length and XOR check bits, can effectively filter abnormal packets, avoid command parsing errors caused by packet merging and incomplete packets, and improve transmission reliability. For the quantized compression transmission method of absolute mouse coordinates, the floating-point value is multiplied by 10000 and mapped to a 16-bit integer. A single mouse command is only 9 bytes, which reduces the amount of data by about 40% compared to directly transmitting floating-point coordinates, effectively reducing bandwidth consumption and transmission latency.

[0018] Furthermore, by associating requests and responses with instruction sequence numbers, and combining this with a timed inspection of the mapping table and a timeout retransmission mechanism, accurate tracking of the execution result of each instruction is achieved in scenarios with concurrent multi-instruction issuance, avoiding asynchronous interaction problems such as mismatched responses and no response due to timeouts. This invention can be widely applied to the design of remote control communication protocols for KVM over IP hardware devices. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein: Figure 1 This is a flowchart illustrating the message construction process of this invention.

[0020] Figure 2 This is a flowchart illustrating the single-frame message parsing process of the present invention. Detailed Implementation

[0021] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0022] Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without inventive effort should fall within the scope of protection of this invention.

[0023] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0024] According to an embodiment of the present invention, in combination Figures 1-2 The flowchart shown illustrates a method for constructing a custom message parsing and transmission protocol for KVM remote control, including: S1: Construct a binary frame structure containing a type code, action code, instruction sequence number, length field, data field, and checksum. The data field supports a single instruction or multiple consecutively stored sub-instructions. S2: Classify instructions based on a two-level encoding system composed of type code and action code, encode single or multiple instructions into the data field, and generate a binary byte stream for transmission. S3: Disassemble the TCP stream based on the length field, perform dual verification of length and checksum on each split frame, and filter out abnormal packets. S4: Parse the verified packets into structured instruction objects, and disassemble consecutively stored packets according to the sub-instruction structure, distributing them to the corresponding business logic according to the action code. S5: Associate requests and responses through instruction sequence numbers, establish a mapping table with time records, periodically check the mapping table, trigger retransmission for requests that have not been responded to within a timeout period, and clean up the mapping entries after the response reaches or the retransmission limit is reached.

[0025] In some embodiments, the custom message parsing and transmission protocol construction method for KVM remote control provided by the present invention includes the following steps in step S1: A binary frame structure containing a type code, action code, instruction sequence number, length field, data field, and checksum is constructed as the unified carrier format for all KVM control instructions and response messages. This frame structure adopts a fixed-length frame header plus a variable-length data field. The data field supports a single instruction or multiple sub-instructions stored consecutively to adapt to both single instruction issuance and batch instruction aggregation and transmission scenarios.

[0026] Specifically, the binary frame structure consists of three parts: a fixed-length frame header, a variable-length data field, and a check bit at the end. The frame header contains four fields: type code, line code, instruction sequence number, and length field, which are arranged in sequence.

[0027] For example, the specific fields are as follows: Table 1: Example of Fields

[0028] In the table, M represents the number of bytes in the data field (i.e., the value of the length field), and the total number of bytes in the complete frame = M + 5 (4-byte frame header + 1-byte checksum).

[0029] As shown in Table 1, the type code field is used to identify the major category of the instruction, where 0xF5 indicates the control instruction issuance category and 0xE3 indicates the device response reporting category.

[0030] It should be noted that the data field starts from the 4th byte and has a variable length. Its specific length is determined by the value of the length field (denoted as M, ranging from 0 to 255), meaning the data field occupies bytes 4 to (M+3). The data field supports two storage modes: First, the single-instruction mode. The data field stores only the business data of one instruction, and different instruction types correspond to different data field structure definitions. For example, for an absolute mouse movement instruction, the data field contains 4 bytes, that is, the X coordinate and the Y coordinate each occupy 2 bytes, and the coordinate values ​​are represented by quantized and compressed 16-bit unsigned integers; for a device restart instruction, the data field length can be 0, and the instruction can be identified only by the type code and the action code.

[0031] Secondly, the multiple sub-instruction contiguous storage mode. The data field stores the complete data of multiple sub-instructions sequentially in the order of transmission. Each sub-instruction header contains a sub-line code (1 byte) and a sub-length field (1 byte), followed by the specific data payload of that sub-instruction. During parsing, the receiving end reads the sub-length field sequentially and extracts the complete data of each sub-instruction from the data field based on the value of this field. This mode is suitable for scenarios requiring the atomic submission of multiple instructions within a single message, reducing the frequency of TCP message exchanges.

[0032] Furthermore, the check bit occupies the last byte of the frame structure, is 1 byte long, and uses an XOR check algorithm. The check calculation range is all bytes from the start of the type code to the end of the data field (i.e., excluding the check bit itself). The receiving end recalculates the check value and compares it with the check bit when parsing the message to verify whether any bit errors have occurred during the transmission.

[0033] In the above frame structure, all multi-byte data is stored in little-endian order, which is consistent with the host byte order of mainstream processors. It can be read and written directly through memory copying without the need for additional byte order conversion.

[0034] As an alternative implementation to this method, a two-byte fixed frame header can be added before the type code field of the binary frame structure. The frame header uses a preset synchronization word, such as the first byte being 0xAA and the second byte being 0x55. The receiving end uses a dual positioning method combining the frame header identifier and the length field to identify frame boundaries. The advantage of this alternative is more accurate frame start positioning, effectively avoiding pseudo-synchronization problems caused by accidental byte sequences identical to those in the frame header field in the TCP stream, and stronger resistance to bit errors and frame start offsets during transmission. Its disadvantage is the addition of a two-byte fixed header overhead, resulting in a slightly larger message size. This alternative is suitable for industrial control environments with complex electromagnetic conditions and high bit error rates.

[0035] It should be noted that, through the constructed binary frame structure, all KVM control commands and response messages are carried in a unified frame format, providing a format foundation for subsequent message serialization construction, streaming unpacking, deserialization parsing, and service distribution.

[0036] In some embodiments, the custom message parsing and transmission protocol construction method for KVM remote control provided by the present invention includes step S2, which classifies the instruction to be sent based on a two-level encoding system composed of type code and behavior code, and determines the type code and behavior code values ​​corresponding to the instruction; constructs the corresponding data field content according to the instruction type, and combines the type code, behavior code, instruction sequence number, length field and data field in the frame format order, calculates the check bit and generates a complete binary byte stream; finally, the byte stream is sent to the other end through a TCP connection.

[0037] like Figure 1 As shown, the serialization building block converts a structured instruction object into a binary byte stream. Figure 1In the flowchart, starting from the beginning node, the process first obtains the incoming instruction object and determines its type code and behavior code. Then, a buffer is allocated and cleared. The type code, behavior code, instruction sequence number, and length fields are written sequentially. A data field is constructed based on the instruction type, where absolute mouse coordinates require quantization compression (floating-point value × 10000 → 16-bit integer). The XOR checksum is calculated and written to the checksum bit. Finally, a complete binary byte stream is returned. If any step (such as quantization conversion or buffer allocation) fails, the flowchart enters an error handling branch and returns an error status.

[0038] Specifically, the following steps are included: When the sending end needs to issue a command or send a response, it first obtains the structured command object to be sent. This command object contains a command type identifier and corresponding business data fields. Subsequently, the command is classified based on a two-level encoding system composed of type code and behavior code to determine the unique belonging of the command in the encoding space.

[0039] The classification logic of the two-level coding system is as follows: The system presets a first value (e.g., 0xF5) as the type code for control command issuance, and a second value (e.g., 0xE3) as the type code for device response reporting. Under the control command issuance category, the behavior codes correspond to keyboard and mouse control commands in the third value range, such as absolute mouse movement 0xA1, relative mouse movement 0xA2, mouse button operations 0xA4 / 0xA5 / 0xA6, and keyboard button operations 0xB1 / 0xB2 / 0xB3; video configuration commands in the fourth value range, such as OSD settings 0xC1, encoder settings 0xC2, frame rate settings 0xC3, transmission protocol settings 0xC4, and video pipeline selection 0xC5; and device management commands in the fifth value range, such as local keyboard and mouse loop-out settings 0xD1, IP settings 0xD2, device restart 0xD3, parameter query 0xE1, and local screenshot 0xE2.

[0040] Under the device response reporting category, the action code corresponds to the execution result response in the sixth value range (e.g., 0xA1), the status information response in the seventh value range (e.g., IP information response 0xA2, version information response 0xA3, hardware connection status response 0xA5), and the network heartbeat response in the eighth value range (e.g., 0xB1).

[0041] During classification, the corresponding type code and behavior code values ​​are obtained by looking up the table based on the instruction type identifier in the instruction object.

[0042] After determining the type code and action code, the sender assigns an instruction sequence number. The instruction sequence number is incremented cyclically; each time a new instruction is issued, the current sequence number is incremented by one. If the incremented value reaches 256 (exceeding the maximum value of 255 for a 1-byte unsigned integer), it wraps back to 0. Before assigning a new sequence number, the sender queries the mapping table using that sequence number as the key. If the sequence number is already occupied by an active record in the mapping table (i.e., a sequence number conflict occurs), the sequence number continues to increment until an unoccupied sequence number is found. If no free sequence number is found after incrementing to 255, the oldest record in the mapping table (sorted by sending timestamp) is forcibly cleared to release the sequence number. With a normal timeout cleanup mechanism, sequence number conflicts are a low-probability event. The strategy combining wrapping back and conflict handling ensures the determinism of sequence number allocation.

[0043] The sending end records the instruction sequence number along with the current timestamp and the initial retransmission count of 0 in the request mapping table for subsequent response matching and timeout retransmission.

[0044] As an alternative implementation to this method, the byte length of the instruction sequence number can be extended from 1 byte to 2 bytes. The advantage of this alternative is that the range of instruction sequence numbers is expanded from 0~255 to 0~65535, allowing for a larger number of concurrent request sequence numbers to be accommodated within a single connection's lifecycle. This effectively avoids the conflict between old and new request sequence numbers that may arise from sequence number loops, making it particularly suitable for high-concurrency instruction issuance scenarios. The disadvantage is that the length of a single frame increases by 1 byte, resulting in a slight increase in transmission overhead. This alternative is suitable for automated control scenarios that require frequent issuance of a large number of instructions and have high concurrency.

[0045] Furthermore, the sending end constructs the data field content according to the instruction type. The data field supports two encoding modes: Mode 1: Single instruction encoding.

[0046] For messages containing only a single instruction, the sending end directly fills the business data into the data field according to the predetermined field format based on the instruction type. Taking the absolute mouse movement instruction as an example: the data field of this instruction contains 2 bytes each for the X and Y coordinates. When constructing the data field, the sending end first multiplies the floating-point X coordinate value by a preset quantization coefficient (preferably 10000), rounds it to the nearest integer, converts it to a 16-bit unsigned integer, and writes it into the 0th and 1st bytes of the data field in little-endian order; similarly, it multiplies the floating-point Y coordinate value by 10000, converts it to a 16-bit unsigned integer, and writes it into the 2nd and 3rd bytes of the data field. For example, taking a keyboard key instruction as an example, the data field of this instruction contains two fields: key code (1 byte) and key status (1 byte). When constructing the data field, the sending end writes the key codes defined by the USBHID specification (e.g., 0x1E corresponds to the A key on the keyboard) into the 0th byte of the data field, and writes the key status flags (0x01 indicates pressed, 0x00 indicates released) into the 1st byte of the data field. The total length of the data field is 2 bytes, and the total length of the frame is 7 bytes. This instruction does not require coordinate quantization and is directly filled with raw bytes.

[0047] For parameter query commands, the data field may contain a query type subfield; for device restart commands, the data field length may be 0. In single command mode, the total length of the data field is determined by the specific command type and shall not exceed 255 bytes.

[0048] As an alternative implementation to this embodiment, the coordinate quantization coefficient can be adjusted from 10000 to 65535, that is, the normalized coordinates are mapped to the full range of 16-bit unsigned integers, which can provide higher positioning resolution and is suitable for 4K and above ultra-high-definition display scenarios.

[0049] During dequantization at the receiving end, the 16-bit integer value is divided by 65535 and then multiplied by the screen resolution to restore floating-point coordinates. The advantage of this alternative scheme is higher coordinate quantization accuracy, theoretically achieving higher control and positioning resolution, especially suitable for fine cursor control in 4K and higher resolution display scenarios. The disadvantage is that it requires strict uniformity of normalization mapping rules at both ends of the communication, and adaptation to different screen resolutions requires pre-agreed reference ranges for coordinate normalization. This quantization coefficient can be flexibly configured according to actual accuracy requirements and screen resolution. Both communicating parties default to a coefficient of 10000; if switching to 65535 or other values ​​is required, synchronization must be performed during the communication establishment phase through independent parameter negotiation commands. If negotiation succeeds, all subsequent coordinate encoding and decoding will be based on the negotiated value; if negotiation fails, it will revert to the default coefficient of 10000.

[0050] Mode 2: Multiple sub-instructions are stored consecutively.

[0051] When the business layer needs to aggregate and send multiple instructions in a single message, the sender stores the complete data of each sub-instruction sequentially in the data field according to the sending order. Each sub-instruction is arranged in a TLV format, consisting of a sub-line code (1 byte), a sub-length field (1 byte), and a sub-data payload (variable length).

[0052] During encoding, the sending end iterates through the list of sub-instructions to be packaged, determines the sub-line code for each sub-instruction, constructs the corresponding sub-data payload, calculates the sub-payload length and fills it into the sub-length field, and then appends the sub-line code, sub-length, and sub-payload sequentially to the end of the data field buffer. After all sub-instructions have been written, the complete data field content is obtained, and the total length of the data field is the sum of the number of bytes occupied by each sub-instruction. Since the length field is 1 byte and its value ranges from 0 to 255, the sending end must ensure that the total length of the data field does not exceed 255 bytes when aggregating multiple sub-instructions; if the total length of the sub-instructions to be sent exceeds this upper limit, the sending end needs to split the sub-instruction list into multiple messages and send them separately. In this mode, the length field records the total number of bytes in the data field.

[0053] After the data field is constructed, the sending end assembles the complete binary message according to the frame format: the 0th byte is written with the type code, the 1st byte with the line code, the 2nd byte with the instruction sequence number, the 3rd byte with the length value of the data field, and then all bytes of the data field are written sequentially. After assembly, the sending end calculates the check bit, performing an XOR operation on each byte from the start of the type code to the end of the data field, and writes the result into the last byte of the frame structure.

[0054] The sending end obtains a complete binary byte stream.

[0055] Subsequently, the sending end transmits the byte stream to the receiving end via the established TCP (Transmission Control Protocol) connection. After transmission, the sending end maintains the instruction sequence number in the mapping table and waits for the receiving end's acknowledgment message. If the instruction does not require acknowledgment (such as a one-way notification instruction), the sending end directly clears the mapping entry after transmission and does not enter the acknowledgment waiting state. The determination of whether an instruction does not require acknowledgment is based on its own behavior code attribute: during system initialization, each business module registers its behavior code and specifies whether the corresponding instruction requires acknowledgment through additional parameters of the registration interface; during serialization construction, the sending end queries this attribute based on the behavior code. If it is marked as requiring no acknowledgment, no mapping record is created; if it is marked as requiring acknowledgment, a mapping record is created according to the normal process and the sending end waits for acknowledgment.

[0056] It should be noted that the S2 encoding and transmission process realizes the complete conversion and transmission from structured instruction objects to binary byte streams that conform to the frame format definition. The instructions obtain a unique and conflict-free encoding attribution under the two-level encoding system. The data field supports both flexible single instruction and multi-instruction aggregation business requirements, laying the foundation for the receiving end to accurately parse and distribute based on type code and behavior code.

[0057] In some embodiments, the custom message parsing and transmission protocol construction method for KVM remote control provided by the present invention includes step S3, in which the receiving end maintains a dynamically growing buffer to temporarily store the raw byte stream data received from the TCP connection. To address the issues of packet merging (multiple frames of data concatenated) and partial packet formation (single-frame data arriving in segments) in TCP streaming transmission, S3 implements adaptive packet splitting based on the value of the length field in the frame structure, sequentially cutting complete frames from the byte stream; each split frame undergoes length validity verification and XOR check bit verification, and only after both verifications pass can the subsequent parsing process proceed; if either verification fails, a byte-by-byte offset recovery process is triggered, resynchronizing the frame boundaries through a sliding probe to avoid subsequent data being unparseable due to single-frame data corruption.

[0058] Specifically, it includes: The receiving end maintains an independent buffer for each TCP connection to store the raw data that has not yet been unpacked. Whenever data arrives at the underlying TCP socket, the receiving end appends the newly received byte stream to the end of the buffer, updating the effective data length of the buffer.

[0059] Furthermore, the receiving end enters a cyclic unpacking process. Each iteration of this process first checks if the length of the valid data in the buffer is sufficient to accommodate the fixed number of bytes in the frame header: 1 byte for the type code, 1 byte for the line code, 1 byte for the instruction sequence number, and 1 byte for the length field, totaling 4 bytes. If the valid data in the buffer is less than 4 bytes, it means that even the frame header cannot be completely read, and the receiving end exits the unpacking process, waiting for subsequent data to arrive.

[0060] When valid data in the buffer satisfies the frame header reading conditions, the receiving end reads the value of the length field from the beginning of the buffer. This value indicates the byte length of the current frame's data field. The receiving end then calculates the length of the complete frame using the following formula: Complete frame length = Fixed header bytes (4 bytes) + Length field value (data field bytes) + Checksum (1 byte). If the length field value is M (0 ≤ M ≤ 255), then the complete frame length is M + 5 bytes.

[0061] After obtaining the full frame length, the receiving end checks whether the length of valid data in the buffer is greater than or equal to the full frame length. If the valid data in the buffer is less than the full frame length, it means that the current frame has not yet fully arrived (i.e., in a half-packet state). The receiving end exits the unpacking process, maintains the current state of the buffer, and waits for subsequent TCP data to arrive before continuing to assemble the packet.

[0062] If the valid data in the buffer meets the length of a complete frame, the receiving end extracts the complete frame from the beginning of the current valid data in the buffer for verification. If the verification passes, the complete frame is removed from the buffer, and the remaining valid data in the buffer is moved forward to the beginning of the buffer. If the verification fails, no data removal operation is performed based on the error length.

[0063] Specifically, if the verification fails, it indicates that the starting position of the valid data in the current buffer is not a valid frame header, possibly due to data corruption or synchronization issues causing the length field to be misread. In this case, the receiving end executes a byte-by-byte offset recovery process: (a) Offset the starting position of the current valid data in the buffer by one byte, i.e. discard one byte at the current starting position; (b) Starting from the new starting position, reread the value of the length field and calculate the length of the complete frame; (c) Check if the length of the remaining valid data in the buffer meets the length of the complete frame. If it does, truncate the data and re-perform the double check. (d) If the verification still fails, repeat steps (a) to (c) until a valid frame that can pass the double verification is found, or the number of consecutive offsets reaches the preset maximum offset threshold (e.g., the current valid data length of the buffer or 256 bytes); if the remaining valid data in the buffer is insufficient to form a complete frame header (less than 4 bytes).

[0064] If no valid frame is found after the maximum offset count is reached, the recovery process is exited, the current valid data in the buffer is cleared to restart synchronization, and the buffer state is maintained while waiting for subsequent data to arrive.

[0065] This byte-by-byte sliding probe mechanism ensures that the receiver can automatically restore synchronization after a bit error or frame boundary loss, without relying on external frame header flags.

[0066] For each frame split from the buffer, the receiving end performs the following double verification in sequence: First layer of verification: length validity verification.

[0067] The receiving end reads the value of the length field in the frame structure and verifies whether it meets the preset legality constraints, namely, whether the length value is less than or equal to the maximum data field length of 255 bytes, and whether the complete frame length does not exceed the buffer reading range. Simultaneously, the receiving end determines whether the instruction type is a known instruction type defined in the protocol based on the values ​​of the type code and behavior code. The protocol encoding space consists of all legal encoding pairs registered in the type code-behavior code mapping table during system initialization. Any type code or behavior code value not registered in this mapping table is considered not defined in the protocol encoding space. If the type code and behavior code are not defined in the protocol encoding space, the length verification is also deemed to have failed.

[0068] If the length check fails, such as when the length exceeds the 255-byte limit or the type code / behavior code is undefined, it indicates that the current frame header position is invalid. In this case, the receiving end does not perform data removal based on an untrusted length value, but instead performs a byte-by-byte sliding recovery process. Specifically, the buffer read start position is shifted one byte forward, and the unpacking and verification are retried from the new position until a valid frame is found or the buffer data is insufficient to continue the attempt.

[0069] It should be noted that the specific implementation of length validity verification is not limited to the above constraints, and the corresponding validity check can be performed according to the instruction set actually defined in the protocol.

[0070] Second layer of verification: check bit verification.

[0071] After the length check passes, the receiving end performs data integrity verification on the frame content. The receiving end extracts the XOR check value stored in the check bit (the last byte of the frame) in the frame structure, and then recalculates the check value, that is, performs an XOR operation on all bytes from the start of the type code to the end of the data field to obtain the calculation result.

[0072] The receiving end compares the recalculated XOR value with the parity bit value extracted from the frame. If they match, the parity bit check passes, confirming that no bit error occurred during TCP transmission. If they do not match, the frame data is determined to be corrupted, and the aforementioned byte-by-byte offset recovery process is executed. No data removal operation is performed based on the error length, and an error log is recorded for troubleshooting.

[0073] A frame is considered a valid message only if both length validity and checksum verification pass, and is then delivered to subsequent steps for deserialization, decoding, and service distribution. Abnormal messages (including those with invalid length, undefined type / behavior codes, or mismatched checksums) are filtered and intercepted in S3, preventing them from entering the protocol parsing and service processing layers. This effectively avoids erroneous data triggering abnormal operations and ensures the reliability of KVM remote control execution.

[0074] As an alternative implementation to this method, the check algorithm used for the check bit can be replaced by CRC8 or CRC16 cyclic redundancy check instead of XOR check. The advantage of this alternative is that CRC (Cyclic Redundancy Check) has stronger error detection capabilities, capable of detecting multiple consecutive bit errors and bit order errors, resulting in a higher level of data transmission integrity assurance. The disadvantage is that its computational complexity is higher than XOR check, placing a slightly greater burden on the embedded microcontroller's computing power. This alternative is suitable for scenarios with high data integrity requirements, such as firmware upgrade command transmission or the distribution of key video configuration parameters, and is the preferred solution on hardware platforms with sufficient computing power.

[0075] Through the S3 packet unpacking and double verification process, the receiving end achieves transparent packet unpacking of TCP streaming data, hiding the network details of packet splicing and incomplete packet processing from the upper-layer services. At the same time, it filters abnormal packets through double checks of length and check bits, providing clean, complete and reliable data input for subsequent packet parsing.

[0076] In some embodiments, the custom message parsing and transmission protocol construction method for KVM remote control provided by the present invention, in step S4, for the complete message that has passed the double verification in S3, first reads the type code and behavior code fields to determine the instruction type; then, according to the behavior code, calls the corresponding deserialization method to restore the structured data from the binary stream according to the byte length definition of each field in the data field, generating a structured instruction object. If the data field in the message contains multiple sub-instructions stored consecutively, the sub-behavior codes and sub-length fields are read sequentially to decompose the structured objects of each sub-instruction. Finally, according to the behavior code, the parsed structured instruction objects are distributed to the corresponding business logic processing functions, completing the complete conversion from binary message to business action.

[0077] like Figure 2 As shown, the receiving end reads the type code and behavior code from the verified complete frame to determine the instruction type.

[0078] Specifically, it includes: After the S3 unpacking and double verification are successful, the receiving end obtains a complete and valid message frame. The receiving end first reads the type code field (byte 0) from the beginning of the message to determine the instruction category of the message.

[0079] Furthermore, the receiving end reads the action code field (byte 1) and, combined with the acquired type code, locates the specific type of the instruction within the two-level encoding system. It reads the instruction sequence number field (byte 2) for subsequent response matching. It reads the length field (byte 3) to obtain the data field length information, thereby determining the boundary range of the data field.

[0080] During the byte-by-byte reading of the data field, all multi-byte numeric fields are read in little-endian order, meaning the low byte is located at the low address and the high byte is located at the high address. The receiving end starts reading the data field from the 4th byte. If the data field contains a 16-bit integer value, such as the X coordinate in the absolute mouse movement command, then two consecutive bytes are read and combined in little-endian order to form a 16-bit value.

[0081] After determining the instruction type, the receiving end calls the deserialization (fromBuffer) method that matches the value of the action code.

[0082] Specifically, the receiving end maintains a mapping table between action codes and deserialization functions, where the action code value corresponds to a deserialization function pointer / reference.

[0083] This mapping table is populated during system initialization by each business module calling a unified registration interface. The interface parameters include the behavior code value and the corresponding function pointer. If the same behavior code has already been registered during registration, the old entry is overwritten and a warning is logged; if the mapping table is full (the maximum number of supported entries is 256 by default), a failure status code is returned. Each business module calls the registration interface sequentially in the protocol layer initialization function, with no dependency order requirement.

[0084] The receiving end queries the deserialization mapping table using the read action code value as the key. This mapping table adopts a hash table structure and stores the mapping entries from action codes to deserialization function pointers. If the search fails or the action code is not defined, the message format is determined to be invalid, the entire frame is discarded, an error log is recorded, and subsequent processing of the message is terminated. If the search is successful, the corresponding deserialization function pointer is obtained from the mapping entry, and the start address and length field value of the current frame's data field are passed to the function as input parameters. The function parses the binary content in the data field byte by byte and restores it into a structured instruction object according to the predefined field definitions of the instruction type. For example, the absolute mouse movement instruction corresponds to a structure containing X and Y coordinates, the video configuration instruction corresponds to a structure containing configuration item identifiers and configuration values, and the device response instruction corresponds to a structure containing response codes and response data. After parsing, the structured object is returned for subsequent business distribution.

[0085] During deserialization, the receiving end reads each field from the binary stream according to the field definition matched by the behavior code: For absolute mouse movement commands, the receiving end reads the 16-bit unsigned integer X coordinate value from the 0th to 1st byte of the data field, converts it to a floating-point type, and divides it by 10000 to restore the original floating-point coordinate value; it reads the Y coordinate value from the 2nd to 3rd byte and performs the same conversion; for other types of commands, it reads the corresponding number of parameter fields.

[0086] That is, the receiving end extracts the type code, action code, instruction sequence number, structured data field data, and verification result from the binary frame, which together constitute a complete structured instruction object.

[0087] Furthermore, the receiving end determines whether the data field of the current message contains multiple consecutively stored sub-instructions. The receiving end pre-determines the encoding mode of the message based on the instruction type. If the current message is a multi-sub-instruction aggregation mode, the receiving end performs a sub-instruction decomposition process on the data field: The receiving end reads each subinstruction sequentially, starting from the beginning of the data field. For each subinstruction, it first reads the subline code (1 byte), then reads the sublength field (1 byte), which indicates the byte length of the current subinstruction's data payload. Based on the value of the sublength field, the receiving end extracts the corresponding number of bytes from the current position in the data field as the data payload of that subinstruction.

[0088] At this point, the receiving end obtains a complete sub-instruction triple (sub-line code, sub-length, sub-payload), and passes it to the deserialization mapping table for further parsing. Specifically, it calls the corresponding deserialization method based on the sub-line code to restore the sub-payload to structured data. After processing the current sub-instruction, the receiving end moves the data field read position forward by (1 + 1 + sub-length) bytes and begins parsing the next sub-instruction until the data field read position reaches the end of the data field. If all sub-instructions in the data field are successfully decomposed, the entire message parsing is complete. If an exception occurs, such as data read exceeding the limit or an undefined sub-line code, the message format is determined to be incorrect, the entire packet is discarded, and no business operations are performed on the successfully parsed sub-instructions.

[0089] For aggregated messages that need to be identified as atomic transactions in the data domain, if any sub-instruction fails to be parsed during the decomposition process, the entire packet is discarded and no parsed partial results are returned to the business layer. The atomic transaction identification method is as follows: in the type code field of the frame structure, a specific type code value (such as 0xFF) indicates that the current message is an atomic transaction aggregated message; if the type code takes other values, it is processed as a normal aggregated message, with each sub-instruction parsed independently. Successfully parsed sub-instructions are submitted to the business layer normally, while failed sub-instructions are recorded in a separate error log but do not affect successfully parsed sub-instructions. The atomic transaction identification does not increase the frame length and is achieved by reusing the reserved value of the type code field.

[0090] In the specific implementation, the structured objects obtained from the parsing of sub-instructions are temporarily stored in a temporary container. Only after all sub-instructions in the data field have been successfully deserialized and deserialized are all the structured objects in the temporary container submitted to the business distribution layer. If an exception occurs midway, the temporary container is destroyed directly, and the temporarily stored objects are released accordingly, without the need for additional rollback operations. For atomic operation instructions that require a response, the sending end considers the atomic operation successful only when it receives the corresponding response; otherwise, a failure notification is triggered by the timeout retransmission mechanism.

[0091] After the instruction is decomposed, the receiving end distributes the parsed structured instruction object to the corresponding business logic according to the action code.

[0092] Specifically, the distribution process is as follows: The receiving end uses the behavior code field as an index to look up the mapping table from the behavior code to the business processing function (this mapping table is independent of the serialization mapping table and is registered by each business module during system initialization). After finding the corresponding business processing function, the receiving end passes the structured instruction object as a parameter, and the business processing function executes the specific business logic.

[0093] After being dispatched to the corresponding business logic, the business processing function performs the appropriate operation based on the instruction type. Specifically, these include the following types: For status information response commands (such as IP information response, version information response, hardware connection status response, etc.), the receiving end will pass the parsed structured status data to the upper layer application through callback notification, and the upper layer application will update the device status cache or trigger the interface refresh.

[0094] For network heartbeat response commands, the receiving end updates the connection's liveness timestamp after parsing to confirm that the other end is still online, without needing to perform any additional business processing.

[0095] For keyboard and mouse control commands, the receiving end converts the parsed keyboard and mouse operation parameters into a local USBHID report format, injects it into the controlled host through a simulated USB input device driver, and completes the physical simulation of the corresponding keyboard and mouse actions. For example, after the absolute mouse movement command is distributed, the controlled end converts the coordinate data into the absolute position on the screen and executes the cursor movement.

[0096] For video configuration commands, the receiving end parses the configuration parameters and calls the video encoder control interface to complete operations such as resolution switching, encoding parameter adjustment, or frame rate change.

[0097] For device management commands, the receiving end parses the management operation type and parameters and then executes the corresponding management action, such as device restart, IP setting update, parameter query, etc.

[0098] After all business logic is executed, the receiving end returns the instruction sequence number and parsing result in the response message to the protocol transaction processing layer (i.e., step S5). Step S5 is responsible for response matching, callback triggering and mapping cleanup. Step S4 itself does not involve any operation on the mapping table.

[0099] If the instruction is a type that requires a response, the business layer will construct a response message after the business logic is executed, encode it using S2, and send it back to the requesting end; if it is a type that does not require a response (such as a one-way heartbeat response), then no response needs to be constructed.

[0100] As can be seen, through the S4 parsing and distribution process, the receiving end completely converts the verified legal binary message into a structured instruction object that the business layer can understand. Single instructions and aggregated multiple sub-instructions are correctly decomposed and parsed, and finally accurately routed to the corresponding business processing function according to the instruction type, thus achieving a clear separation between the protocol layer and the business logic layer.

[0101] In some embodiments, the custom message parsing and transmission protocol construction method for KVM remote control provided by the present invention includes step S5, which establishes a request mapping table at the sending end to store request records that have been sent but have not yet received a response. Each record contains three core fields: instruction sequence number, sending timestamp, and retransmission count. The sending end creates mapping records synchronously when issuing instructions; upon receiving a response message, it searches for and clears the corresponding record based on the instruction sequence number carried in the response; simultaneously, a timed inspection task is started to periodically scan the mapping table, identify requests that have timed out and have not received a response, and trigger retransmissions until a response is received or the retransmission limit is reached, at which point the table is forcibly cleared, thereby achieving full lifecycle tracking and reliable delivery of asynchronous requests.

[0102] Specifically, it includes: During system initialization, the sending end creates a request mapping table. This mapping table uses the instruction sequence number as the key and the mapping record as the value, employing a hash table structure to achieve O(1) time complexity for lookup, insertion, and deletion operations. Each record in the mapping table contains the following fields: instruction sequence number (same as the key value, used for fast matching), sending timestamp (used to record the system time when the instruction was issued, used to calculate the waiting time), retransmission count (used to record the number of times the instruction has been retransmitted, used to determine whether the retransmission limit has been reached), instruction cache (used to store the complete binary data of the original request message or a reference to that data, used for direct reuse during retransmission), response callback function pointer (used to notify the upper-layer business when the response arrives, passing in the instruction sequence number, response data pointer and length), and timeout callback function pointer (used to notify the upper-layer business after retransmission timeout, passing in the instruction sequence number and the current retransmission count). The aforementioned callback functions are passed as parameters to the mapping record by the upper-layer business when sending instructions. When called, they are executed synchronously in the protocol processing thread, i.e., the underlying network I / O thread or timer thread. After the call is completed, the subsequent mapping record cleanup operation is performed immediately.

[0103] It should be noted that this mapping table uses read-write locks for concurrency control. Query operations (response matching, inspection reads) hold read locks, while insert, update, and delete operations hold write locks to improve concurrent query performance. All lock operations are managed using the RAII (Real Estate Information Interchange) model to ensure locks are correctly released in exceptional circumstances. Callback functions are executed after lock release to avoid deadlocks or reentrancy issues caused by reverse calls to the protocol interface within the callback function. When periodic inspections and responses arrive concurrently, the inspection thread performs a timeout check after acquiring the read lock. If a timeout is detected, the read lock is released, and a write lock is acquired for a second confirmation that the record still exists (to prevent the record from being deleted after the response has arrived). If the second confirmation indicates the record no longer exists, the write lock is immediately released and the current retransmission process ends. If the second confirmation indicates the record exists, the retransmission operation is then performed to ensure the atomicity of operations and data security.

[0104] When the sending end issues a command requiring a response in S2, it executes the mapping record creation process. After generating a command sequence number for the command, the sending end obtains the current system time as the sending timestamp, initializes the retransmission count to 0, copies the completed binary message to the buffer, and binds it to the business callback function for this request. Subsequently, the sending end inserts the record into the mapping table using the command sequence number as the key, and then sends the message out over the network.

[0105] For records that have already received a response and been cleared, if a duplicate response with the same instruction sequence number is subsequently received due to network delay, the receiving end will directly ignore the duplicate response when querying the mapping table because the entry no longer exists, and will not trigger any business callbacks or mapping operations, in order to avoid logical errors caused by duplicate processing.

[0106] It should be noted that S5 acts as the sole response transaction processing center. When S4 returns the parsed response message instruction sequence number and result data to S5, S5 executes the following response matching process: The instruction sequence number is used as the key to query the mapping table. If a corresponding record exists in the mapping table, the callback is invoked according to the response callback function pointer stored in the record, the response data is passed to the upper-level business logic, and threads that may be in a blocked waiting state are awakened; after the callback is executed, the record is deleted from the mapping table, and cache resources are released. If a corresponding record does not exist in the mapping table (it may have been cleared due to timeout), the response is ignored.

[0107] The sending end simultaneously starts an independent timed inspection thread (or timer callback task), which periodically scans all records in the mapping table according to a preset inspection cycle, and performs timeout judgment and retransmission decision: For each record in the mapping table, the sending end obtains the current system time, calculates the difference between the current time and the sending timestamp, and obtains the duration the request has been waiting (i.e., the waiting time). The sending end compares the waiting time with a preset timeout threshold (which can be configured according to the network environment, such as the default 3000 milliseconds): If the waiting time is less than the timeout threshold, it means that the request is still within the normal waiting window. The sender continues to retain the mapping record without any processing, and waits for the next inspection cycle to make another judgment.

[0108] If the waiting time is greater than or equal to the timeout threshold, the request has timed out, and the sender executes a retransmission decision process for that record. The sender first reads the retransmission count of the record and compares it with the preset maximum number of retransmissions (e.g., 3 times). If the retransmission count has not yet reached the limit, the sender retrieves the original request message from the record's instruction cache, resends it to the peer via the TCP connection, increments the retransmission count, updates the sending timestamp to the current time (i.e., resets the waiting timer window), records it in the mapping table, and continues to wait for a response. If the retransmission count has reached the limit, the sender abandons retransmission, calls the timeout callback function bound to the record, returns a timeout failure message to the upper-layer business, deletes the record from the mapping table, releases cache resources, and ends the lifecycle of the request.

[0109] For records that have received a response and have been cleared normally, the scheduled inspection task will no longer perform any operations on them.

[0110] Furthermore, considering the possibility of duplicate responses arriving due to network retransmissions during TCP transmission, S5 explicitly stipulates that when a response arrives, if there is no corresponding instruction sequence number record in the mapping table (possibly because the first response has been received and cleared normally, or because the retransmission limit has been reached due to timeout and forced clearing), the receiving end directly ignores the duplicate response and does not trigger any business callbacks or mapping operations, in order to avoid logical errors caused by duplicate processing.

[0111] Regarding the strategy for using instruction sequence numbers, since the instruction sequence number field is 1 byte long and its value ranges from 0 to 255, the sending end uses a cyclically incrementing method to use the instruction sequence number.

[0112] The inspection cycle should be less than the timeout threshold. As an example configuration, the timeout threshold can be set to 3000 milliseconds, and the inspection cycle can be set to 100 milliseconds, that is, the inspection cycle is 1 / 30 of the timeout threshold. The actual values ​​can be adjusted according to the network environment and latency sensitivity.

[0113] As an alternative implementation to this method, the binary frame structure and encoding / decoding method, while maintaining the same frame format, are compatible with using UDP instead of TCP as the transport layer carrier. In this alternative, the sending end needs to add packet loss retransmission logic, and the receiving end needs to add message deduplication logic based on instruction sequence numbers. The request mapping table and timeout retransmission mechanism established in S5 can be reused as the infrastructure for UDP packet loss recovery. The advantage of this alternative is its adaptability to connectionless transmission scenarios, reducing the overhead of TCP connection establishment and maintenance, and achieving lower transmission latency in high-reliability network environments such as LANs. The disadvantage is the need to additionally implement reliable transmission logic on UDP (User Datagram Protocol), increasing the overall protocol complexity. This alternative is suitable for LAN KVM control scenarios with extremely high real-time requirements and acceptable low packet loss retransmission rates.

[0114] The protocol processing method in this implementation distinguishes different operating system platforms through compiler macros, adapting to the differences in dynamic library export and import keywords between Windows and non-Windows platforms. The core protocol processing logic, such as serialization, deserialization, packet unpacking and verification, and mapping table management, is encapsulated in an independent tool library. This tool library is implemented using a purely static method, relying only on standard C++ libraries, and is not bound to any platform-specific network interfaces, file system APIs, or operating system calls. It can be directly ported to different operating environments such as Windows, Linux, and embedded ARM, achieving complete decoupling of the protocol processing logic from the underlying platform and upper-layer business logic.

[0115] It should be noted that through S5's mapping table establishment, timed inspection, timeout retransmission, and response matching mechanism, the sending end achieves independent lifecycle management for each asynchronous request. The closed-loop process of recording when a request is sent, matching and cleaning up when a response arrives, and automatically retransmitting or notifying of timeout failures ensures that the execution result of each instruction can be accurately tracked in scenarios with multiple concurrent instruction issuance, avoiding the chaos of asynchronous interaction logic caused by response mismatch, no response after timeout, or duplicate responses.

[0116] The method also includes one or more processors and memory.

[0117] The memory is used to store operable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations, including the flow of a custom message parsing and transmission protocol construction method for KVM remote control according to the foregoing embodiments, especially... Figure 1 The flowchart of the method is shown.

[0118] Other aspects disclosed in the embodiments of the present invention also propose a computer-readable medium for storing software including instructions executable by one or more computers, which, upon execution, cause the one or more computers to perform operations including the flow of a custom message parsing and transmission protocol construction method for KVM remote control according to the foregoing embodiments, particularly... Figure 1 The flowchart of the method is shown.

[0119] It should be recognized that embodiments of the present invention may be implemented or carried out by computer hardware, a combination of hardware and software, or by computer instructions stored in a non-transitory computer-readable storage medium.

[0120] The method can be implemented using standard programming techniques, including a non-transitory computer-readable storage medium configured with a computer program in the computer program, wherein the storage medium is configured such that the computer operates in a specific and predefined manner.

[0121] Each program can be implemented in a high-level procedural or object-oriented programming language to communicate with the computer system; however, if necessary, the program can be implemented in assembly or machine language.

[0122] In any case, the language can be either compiled or interpreted.

[0123] Furthermore, for this purpose, the program can run on programmed application-specific integrated circuits.

[0124] The processes described herein (or variations and / or combinations thereof) can be executed under the control of one or more computer systems configured with executable instructions, and can be implemented by hardware or a combination thereof as code (e.g., executable instructions, one or more computer programs, or one or more applications) that commonly executes on one or more processors. The computer program includes a plurality of instructions executable by one or more processors.

[0125] Furthermore, the method can be implemented in any suitable computing platform, including but not limited to personal computers, minicomputers, mainframes, workstations, networked or distributed computing environments, standalone or integrated computer platforms, or in communication with charged particle tools or other imaging devices.

[0126] Various aspects of the present invention can be implemented in machine-readable code stored on a non-transitory storage medium or device, whether portable or integrated into a computing platform, such as a hard disk, optical read and / or write storage medium, RAM, ROM, etc., such that it can be read by a programmable computer, and when the storage medium or device is read by the computer, it can be used to configure and operate the computer to perform the processes described herein.

[0127] Furthermore, machine-readable code, or parts thereof, can be transmitted via wired or wireless networks.

[0128] When such media includes instructions or programs that combine with a microprocessor or other data processor to implement the steps described above, the invention described herein includes these and other different types of non-transitory computer-readable storage media.

[0129] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for constructing a custom message parsing and transmission protocol for KVM remote control, characterized in that: include: Construct a binary frame structure that includes a type code, a behavior code, an instruction sequence number, a length field, a data field, and a check bit. The data field supports a single instruction or multiple sub-instructions stored consecutively. Instructions are classified based on a two-level encoding system consisting of type code and behavior code, and one or more instructions are encoded into the data field and generated into a binary byte stream for transmission. The TCP stream is split based on the length field, and each split frame is double-checked for length and checksum to filter out abnormal packets. The verified messages are parsed into structured instruction objects, and the continuously stored messages are disassembled sequentially according to the sub-instruction structure and distributed to the corresponding business logic according to the line code. By associating requests and responses with instruction sequence numbers, a mapping table with time records is established. The mapping table is checked periodically, and retransmission is triggered for requests that have not been responded to within a timeout period. The mapping entries are cleaned up after the response reaches or the retransmission limit is reached.

2. The method for constructing a custom message parsing and transmission protocol for KVM remote control as described in claim 1, characterized in that: In the binary frame structure, the type code occupies 1 byte, the line code occupies 1 byte, the instruction sequence number occupies 1 byte, the length field occupies 1 byte, and the check bit occupies 1 byte and uses XOR verification. The XOR verification range is all bytes from the start of the type code to the end of the data field.

3. The method for constructing a custom message parsing and transmission protocol for KVM remote control as described in claim 1, characterized in that: In the two-level coding system, the type code uses a first value to identify the control command issuance class and a second value to identify the device response reporting class. In the category of control command issuance, the behavior code corresponds to keyboard and mouse control in the third value range, video configuration in the fourth value range, and device management in the fifth value range. In the device response reporting category, the behavior code corresponds to the execution result response in the sixth value range, the status information response in the seventh value range, and the network heartbeat response in the eighth value range.

4. The method for constructing a custom message parsing and transmission protocol for KVM remote control as described in claim 3, characterized in that: When serializing absolute mouse coordinate commands, the floating-point X coordinate value is multiplied by a preset quantization coefficient and then converted into a 16-bit unsigned integer and written into the data field. The floating-point Y coordinate value is multiplied by the quantization coefficient and then converted into a 16-bit unsigned integer and written into the data field.

5. The method for constructing a custom message parsing and transmission protocol for KVM remote control as described in claim 1, characterized in that: When parsing a message that has passed verification, the value of the behavior code field is read, and the deserialization method that matches the value is called to restore the structured data from the binary stream according to the byte length definition of each field in the data field. During serialization construction, the behavior code value of the instruction is read, and the serialization method matching the value is called to convert the structured data into a binary stream in frame format.

6. The method for constructing a custom message parsing and transmission protocol for KVM remote control as described in claim 1, characterized in that: The multiple sub-instructions stored consecutively are arranged in the data field according to the sending order. Each sub-instruction header contains a sub-line code and a sub-length field. When parsing, the receiving end reads the sub-length field in sequence and extracts the complete data of each sub-instruction from the data field according to the value of the sub-length field.

7. The method for constructing a custom message parsing and transmission protocol for KVM remote control as described in claim 1, characterized in that: Each record in the mapping table includes an instruction sequence number, a sending timestamp, and a retransmission count; During retransmission, the instruction sequence number remains unchanged, and the response message carries the instruction sequence number of the requested response. During scheduled inspections, the difference between the current time and the sending timestamp is compared with a preset timeout threshold. If a timeout occurs and the retransmission count has not reached the upper limit, the original instruction is resent and the retransmission count is incremented. If a timeout occurs and the retransmission count has reached the upper limit, a timeout failure message is returned to the upper layer and the mapping record is deleted. If an acknowledgment is received, the mapping record is located and deleted based on the instruction sequence number carried in the acknowledgment.

8. The method for constructing a custom message parsing and transmission protocol for KVM remote control as described in claim 1, characterized in that: When disassembling a TCP stream based on the length field, the received data is appended to the end of the buffer. The value of the length field is read from the beginning of the currently valid data in the buffer, and the value of the length field is added to the fixed number of bytes in the frame header to obtain the complete frame length. Check whether the length of valid data in the buffer is greater than or equal to the length of the complete frame. If it is, extract the complete frame from the beginning of the buffer and perform dual checks on length and check bits. If the verification passes, the truncated data is removed and the remaining data in the cache is moved forward to the beginning of the cache. If the verification fails, the current frame header position is discarded, the starting position of the current valid data in the buffer is shifted one byte to the right, and the length field is read again from the new starting position and the unpacking and verification process is repeated. If the valid data in the buffer is less than 4 bytes or less than the length of the complete frame, the current state of the buffer is maintained and the subsequent data is allowed to arrive.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, it implements the steps of the custom message parsing and transmission protocol construction method for KVM remote control as described in any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the steps of the custom message parsing and transmission protocol construction method for KVM remote control as described in any one of claims 1 to 8.

Images