Session isolation of remote desktop input events

Abstract

The application relates to the technical field of remote control and session management, and provides a session isolation method and system for remote desktop input events. The method obtains a current remote session identifier through remote control connection establishment, generates a current local input life cycle identifier in response to an input interface opening operation and binds the current local input life cycle identifier with the current remote session identifier, performs identifier matching verification on a state event carrying the local input life cycle identifier and a closing command, simultaneously performs life cycle identifier matching, remote session identifier matching and inputtable state three joint verifications on an input event carrying the local input life cycle identifier and the remote session identifier, injects the current remote session when all the verifications are satisfied, discards the input event when all the verifications are not satisfied, and updates the current remote session identifier to make old input events invalid when the remote control connection is disconnected, reconnected or switched. The method has beneficial effects of late callback isolation, old closing command anti-misoperation, cross-session input prevention, intermediate state anti-misoperation and high asynchronous link fault tolerance.

Description

Technical Field

[0001] This application relates to the field of remote control and session management technology, and in particular to a session isolation method and system for remote desktop input events. Background Technology

[0002] When using remote desktop, users often perform a series of operations such as opening the keyboard, closing the keyboard, reopening the keyboard, switching remote computers, or disconnecting and reconnecting. These operations appear to the user as just a few clicks, but internally the application needs to go through multiple steps, including window creation, focus change, keyboard display, text submission, and network connection, and the order in which these steps are completed is not fixed.

[0003] For example, if a user closes the old keyboard and immediately opens the new one, the notification that the old keyboard is already displayed might arrive later. If the application cannot determine that this notification comes from the old keyboard, it might incorrectly update the state of the new keyboard; a delayed close command from the old page might also close the newly opened keyboard. The user might then experience the keyboard suddenly disappearing, buttons becoming unresponsive, requiring repeated clicks, or even no input response. Summary of the Invention

[0004] This application provides a session isolation method and system for remote desktop input events, aiming to solve the problem that users often perform operations such as opening the keyboard, closing the keyboard, reopening the keyboard, switching remote computers, or disconnecting and reconnecting when using remote desktop. These operations appear to the user as just a few clicks, but internally the application needs to go through multiple stages such as window creation, focus change, keyboard display, text submission, and network connection, and the order in which these stages are completed is not fixed.

[0005] In a first aspect, embodiments of this application provide a session isolation method for remote desktop input events, the method comprising: Establish a remote control connection and obtain the current remote session identifier; respond to the input interface opening operation, generate the current local input lifecycle identifier, bind the current local input lifecycle identifier with the current remote session identifier, and set the current input status to "on". Receive asynchronous events carrying local input lifecycle identifiers. For status events, update the current input state only if the local input lifecycle identifier carried by the status event is consistent with the current local input lifecycle identifier and the current input state allows state transition. For close commands, set the current input state to "closing and releasing the input interface instance" only if the expected local input lifecycle identifier carried by the close command is consistent with the current local input lifecycle identifier. For input events carrying both a local input lifecycle identifier and a remote session identifier, the system simultaneously determines whether the local input lifecycle identifier carried by the input event matches the current local input lifecycle identifier, whether the remote session identifier carried by the input event matches the current remote session identifier, and whether the current input state is an input-available state. If all conditions are met, the input event is injected into the current remote session; if any condition is not met, the input event is discarded. When a remote control connection is detected to be disconnected, reconnected, or switched, the system updates the current remote session identifier, invalidating input events carrying the old remote session identifier.

[0006] In some embodiments, establishing a remote control connection and obtaining the current remote session identifier includes: initiating a remote control connection request and establishing a remote control connection with a remote computer; after the remote control connection is successfully established, generating a unique current remote session identifier for this remote control connection; and binding and storing the current remote session identifier with the remote control connection.

[0007] In some embodiments, the step of responding to the input interface opening operation and generating a current local input lifecycle identifier includes: responding to the input interface opening operation when the user triggers the input interface opening operation; generating a current local input lifecycle identifier that is not repeated within a predetermined range, wherein the current local input lifecycle identifier adopts a monotonically increasing sequence number or a globally unique identifier; and associating the current local input lifecycle identifier with the current input interface opening operation.

[0008] In some embodiments, binding the current local input lifecycle identifier with the current remote session identifier and setting the current input state to "ongoing" includes: establishing a binding relationship between the current local input lifecycle identifier and the current remote session identifier to form a lifecycle-session binding pair; setting the current input state to "ongoing", and disallowing input events from being injected in the "ongoing" state; and storing the lifecycle-session binding pair and the current input state in the session isolation verification module.

[0009] In some embodiments, receiving asynchronous events carrying local input lifecycle identifiers, for status events, updating the current input state only when the local input lifecycle identifier carried by the status event matches the current local input lifecycle identifier and the current input state allows for state transition, includes: receiving asynchronous events, including status events, close commands, and input events, each asynchronous event carrying a local input lifecycle identifier; for status events, extracting the local input lifecycle identifier carried by the status event and comparing the local input lifecycle identifier carried by the status event with the current local input lifecycle identifier; if the local input lifecycle identifier carried by the status event matches the current local input lifecycle identifier and the current input state allows for target state transition, updating the current input state according to the status event; status events with mismatched identifiers are identified as late events and discarded.

[0010] In some embodiments, setting the current input state to "closing" and releasing the input interface instance only when the expected local input lifecycle identifier carried by the close command matches the current local input lifecycle identifier includes: for the close command, extracting the expected local input lifecycle identifier carried by the close command, comparing the expected local input lifecycle identifier carried by the close command with the current local input lifecycle identifier; when the expected local input lifecycle identifier carried by the close command matches the current local input lifecycle identifier, setting the current input state to "closing" and releasing the current input interface instance; when the expected local input lifecycle identifier carried by the close command does not match the current local input lifecycle identifier, ignoring the close command.

[0011] In some embodiments, the step of injecting the input event into the current remote session when all three conditions are met—that the local input lifecycle identifier carried by the input event matches the current local input lifecycle identifier, the remote session identifier carried by the input event matches the current remote session identifier, and the current input state is an input-enabled state—includes the following: for an input event, extracting the local input lifecycle identifier and the remote session identifier carried by the input event; simultaneously determining that the local input lifecycle identifier carried by the input event matches the current local input lifecycle identifier, the remote session identifier carried by the input event matches the current remote session identifier, and the current input state is an input-enabled state; when all three conditions are met, injecting the input event into the current remote session, and having the current remote session send the input event to the remote computer.

[0012] In some embodiments, discarding an input event when any of the conditions is not met includes: if the local input lifecycle identifier carried by the input event is inconsistent with the current local input lifecycle identifier, the input event is determined to originate from an old input interface instance, and the input event is discarded; if the remote session identifier carried by the input event is inconsistent with the current remote session identifier, the input event is determined to belong to an old remote session, and the input event is discarded; if the current input state is not an input-available state, the arrival time of the input event is determined to be invalid, and the input event is discarded; the event type, the current local input lifecycle identifier, the current remote session identifier, and the reason for discarding the input event are recorded.

[0013] In some embodiments, updating the current remote session identifier when a remote control connection is detected to be disconnected, reconnected, or switched, thereby invalidating input events carrying the old remote session identifier, includes: real-time monitoring of the remote control connection status; triggering a remote session identifier update process when a remote control connection is detected to be disconnected, reconnected, or switched; generating a new current remote session identifier after a successful reconnection or switch, and binding the new current remote session identifier to the reconnected or switched remote control connection; after updating the current remote session identifier, all input events carrying the old remote session identifier are discarded during the three-condition verification due to the mismatch of the remote session identifier, thus invalidating the old input events; the current input interface can be closed simultaneously, or the input interface can be retained but input can be disabled.

[0014] Secondly, this application provides a session isolation system for remote desktop input events, the system comprising: The connection establishment unit is used to establish a remote control connection and obtain the current remote session identifier; respond to the input interface opening operation, generate the current local input lifecycle identifier, bind the current local input lifecycle identifier with the current remote session identifier, and set the current input status to "opening"; The event receiving unit is used to receive asynchronous events carrying local input lifecycle identifiers. For status events, the current input state is updated only if the local input lifecycle identifier carried by the status event is consistent with the current local input lifecycle identifier and the current input state allows state transition. For close commands, the current input state is set to "closing and releasing the input interface instance" only if the expected local input lifecycle identifier carried by the close command is consistent with the current local input lifecycle identifier. The event invalidation unit is used to determine whether an input event carrying a local input lifecycle identifier and a remote session identifier is consistent with the current local input lifecycle identifier, whether the input event carrying a remote session identifier is consistent with the current remote session identifier, and whether the current input state is an input-available state. If all conditions are met, the input event is injected into the current remote session. If any condition is not met, the input event is discarded. When a remote control connection is detected to be disconnected, reconnected, or switched, the current remote session identifier is updated, invalidating the input event carrying the old remote session identifier.

[0015] The method provided in this application has the following beneficial effects: First, a new local input lifecycle identifier is used each time the input interface is opened. The visibility, hiding, or end callbacks of the old instance cannot cover the current instance state, thus isolating late state callbacks.

[0016] Second, the close command must carry and match the expected lifecycle identifier. When quickly opening, closing, or reopening, the old page cannot close the newly created input interface to avoid the old close command from being misused.

[0017] Third, the joint verification of local input lifecycle identifier and remote session identifier can invalidate old text and keystrokes after switching remote computers or reconnecting after disconnection, reducing the risk of inputting into the wrong remote target and preventing input across remote sessions.

[0018] Fourth, the input state is used as an independent gating condition, which prevents events during the opening and closing phases from being injected into the remote session even if the identifiers match, thus preventing erroneous input of intermediate states.

[0019] Fifth, the type-based validation does not rely on callbacks arriving in strict order, and can provide a second layer of blocking when the state of the native layer or cross-platform layer is temporarily delayed, thereby improving the fault tolerance of the asynchronous link.

[0020] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

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

[0022] Figure 1 This is a schematic flowchart illustrating the steps of a session isolation method for remote desktop input events provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating the principle of a session isolation method for remote desktop input events provided in an embodiment of this application; Figure 4 This is a schematic block diagram of a session isolation system for remote desktop input events provided in an embodiment of this application; Figure 5 This is a schematic block diagram of the structure of a terminal device provided in an embodiment of this application.

[0023] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Detailed Implementation

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

[0025] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the order described. For example, some operations / steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0026] It should be understood that, in order to clearly describe the technical solutions of the embodiments of the present invention, the terms "first" and "second" are used in the embodiments of the present invention to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and the terms "first" and "second" are not necessarily different.

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

[0028] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0029] When using remote desktop, users often perform a series of operations such as opening the keyboard, closing the keyboard, reopening the keyboard, switching remote computers, or disconnecting and reconnecting. These operations appear to the user as just a few clicks, but internally the application needs to go through multiple steps, including window creation, focus change, keyboard display, text submission, and network connection, and the order in which these steps are completed is not fixed.

[0030] For example, if a user closes the old keyboard and immediately opens the new one, the notification that the old keyboard is already displayed might arrive later. If the application cannot determine that this notification comes from the old keyboard, it might incorrectly update the state of the new keyboard; a delayed close command from the old page might also close the newly opened keyboard. The user might then experience the keyboard suddenly disappearing, buttons becoming unresponsive, requiring repeated clicks, or even no input response.

[0031] A more serious situation occurs when a user switches from one remote computer to another, or reconnects after a disconnection on the same computer. If text or keystrokes generated by the old keyboard continue to travel along the original asynchronous link, they may be sent to a remote session that should not be receiving input at that time. This not only causes garbled input but may also result in commands, passwords, or codes being entered into the wrong computer or window. Simply checking if the keyboard exists, or simply checking which computer is currently connected, cannot simultaneously resolve the problem of old keyboard callbacks and residual input from old remote connections.

[0032] Please refer to Figure 1 This application provides a session isolation method for remote desktop input events, applicable to, for example... Figure 2 The terminal device shown can be a foldable dual-screen tablet, a dual-screen laptop, a tablet with an external second display, a desktop computer, a laptop, or other computing device with remote desktop connection and input capabilities. The operating system of the terminal device can be Android, HarmonyOS, iOS, Windows, Linux, or other operating systems that support remote desktop protocols and input management. It should also be noted that every piece of information involved in the method provided in this application was extracted with the authorization of the relevant user and in accordance with relevant regulations, and will not infringe on user privacy.

[0033] Please refer to Figure 2 This application also provides a terminal device, including a first display screen, a second display screen, a processor, a memory, and a communication module. The first display screen is used to display a remote desktop session screen, and the second display screen is used to display a local input interface (soft keyboard, candidate word bar, voice input interface, etc.). The processor executes computer program instructions stored in the memory to implement the session isolation method for remote desktop input events provided in the embodiments of this application. The communication module is used to establish a network connection with a remote computer and transmit remote desktop screen data and input event data.

[0034] Please refer to Figure 3The remote desktop input event session isolation principle of this application embodiment is as follows: the first display screen of the terminal device displays the remote desktop session, and the second display screen displays the local input interface; the input state machine manages the life cycle state of the input interface (on, inputtable, off), and all asynchronous events (status events, close commands, input events) carry the local input life cycle identifier. The state machine only processes events whose identifier matches the current identifier; before an input event is injected into the remote session, a triple check is performed (local input life cycle identifier matches, remote session identifier matches, and the current inputtable state is met). Only if all three conditions are met is the event injected into the current remote session, and if any one condition is not met, the event is discarded; when the remote control connection is disconnected, reconnected, or switched, the current remote session identifier is updated, so that the input event carrying the old remote session identifier automatically becomes invalid.

[0035] The provided method for session isolation of remote desktop input events includes steps S101 to S103. Details are as follows: The provided method for session isolation of remote desktop input events includes steps S101 to S103. Details are as follows: Step S101. Establish a remote control connection and obtain the current remote session identifier; respond to the input interface opening operation, generate the current local input lifecycle identifier, bind the current local input lifecycle identifier with the current remote session identifier, and set the current input status to "on".

[0036] Specifically, the core function of step S101 is to establish a remote control connection with the remote computer and obtain the current remote session identifier that uniquely identifies this connection. When the user opens the input interface, a current local input lifecycle identifier that uniquely identifies the lifecycle of this input interface is generated. The two identifiers are bound to form a lifecycle-session binding pair, and the current input state is initialized to "opening", laying the foundation for session isolation verification of subsequent asynchronous events.

[0037] Establishing a remote control connection and obtaining the current remote session identifier: The user launches the remote desktop client application on the terminal device, enters the remote computer's network address (Internet Protocol address or hostname), port number, username, and authentication credentials (password, token, biometrics, or single sign-on credentials), and initiates a remote control connection request. The remote desktop client establishes a network connection with the remote computer through a communication module (wireless LAN, cellular network, or Ethernet). The connection establishment process includes Transmission Control Protocol connection establishment, transport layer security encryption handshake, user authentication, and remote desktop session parameter negotiation (display resolution, color depth, audio redirection, clipboard redirection, etc.). After the connection is successfully established, the remote computer continuously sends remote desktop screen data, which is compressed and encoded into video, to the terminal device. The client decodes the data and displays the remote desktop screen on the first display screen.

[0038] After a remote control connection is successfully established, a unique current remote session identifier is generated for this connection. This identifier uniquely identifies a single remote control connection session and can be generated in several ways: a session identifier assigned by the Remote Desktop Protocol (if the Remote Desktop Protocol itself assigns a unique identifier to each session, this can be used directly); or a unique identifier generated locally by the client (an auto-incrementing serial number, a universally unique identifier, or a combination of a timestamp and a random number). The current remote session identifier is bound to the remote control connection and stored in the session management module. Associated information includes the remote computer address, login username, connection establishment time, connection type (direct or relay), encryption protocol version, and negotiated display parameters. The current remote session identifier remains unchanged throughout the entire lifecycle of the remote control connection. When the connection is broken, reconnected, or switched to another remote computer, a new current remote session identifier is generated, and the old identifier becomes invalid.

[0039] Responding to the input interface opening operation and generating the current local input lifecycle identifier: When a user needs to input text or commands during remote desktop use, the input interface is activated. The activation can be triggered in several ways: the user actively clicks the keyboard icon button on the remote desktop client interface; the user clicks an input area (text box, address bar, terminal window, etc.) on the remote desktop screen; the user presses a hardware keyboard shortcut key; the user triggers the activation via voice command; or the application automatically detects that the currently active window on the remote computer is a text input application and prompts the user to activate it, which is then activated upon user confirmation.

[0040] Upon detecting an input interface opening operation, a current local input lifecycle identifier is generated in response. This identifier uniquely identifies the opening-use-closing lifecycle of an input interface. Generation methods include: a monotonically increasing sequence number (maintaining a global counter, atomically incrementing each time the input interface is opened, simple and efficient, the sequence number reflects the opening order); and a globally unique identifier (generating a 128-bit universally unique identifier, with extremely strong global uniqueness, suitable for cross-process or cross-device scenarios). The current local input lifecycle identifier is unique within a predetermined range, ensuring a unique identifier for each input interface opening, even with rapid consecutive openings and closings. The generated current local input lifecycle identifier is associated with the current input interface opening operation.

[0041] Binding and state initialization: After generating the current local input lifecycle identifier, a binding relationship is established between it and the current remote session identifier, forming a lifecycle-session binding pair. This binding relationship is stored in the session isolation verification module. The binding pair includes: the current local input lifecycle identifier, the current remote session identifier, the binding establishment time, the input interface instance reference, and the current input status. The purpose of this binding relationship is to ensure that all subsequent asynchronous events (status events, close commands, input events) carry the local input lifecycle identifier. This identifier is used to find the corresponding remote session identifier, which is then compared with the current remote session identifier to achieve isolation verification between the input event and the session. When the remote session identifier is updated (connection reconnection or switching), the remote session identifier in the old binding pair becomes inconsistent with the current identifier, and input events carrying the old local identifier are automatically verified and discarded.

[0042] Set the current input state to "On". The current input state is the core state variable of the input state machine, representing the current lifecycle stage of the input interface. Input states include: On (the input interface has been triggered to open but is not yet fully displayed and ready; input events are not allowed in this state to avoid incorrect processing of user input before the input interface is ready); Inputtable (the input interface is fully displayed and ready, and users can input normally; valid input events are allowed in this state); Closing (the input interface has been triggered to close but is not yet fully released; input events are not allowed in this state); and Closed (the input interface has been fully released, and there is no active input interface). Input events are not allowed to be injected in the On state because the input interface may not have completed display, focus acquisition, or input connection establishment, and the user's input operation may not have been correctly captured; premature injection will lead to input loss or errors.

[0043] The lifecycle-session binding and the current input state are stored in the session isolation verification module. This module is the core functional module of this application, responsible for maintaining the current local input lifecycle identifier, the current remote session identifier, and the current input state, and performing identifier and state verification on all asynchronous events. The session isolation verification module can be implemented as an independent module or service within the remote desktop client application, running in a separate thread to ensure real-time event verification and thread safety.

[0044] After step S101 is completed, the system status is as follows: the remote control connection has been established, the current remote session identifier has been generated and bound to the connection; the input interface opening operation has been responded to, and the current local input lifecycle identifier has been generated; the two identifiers have been bound to form a lifecycle-session binding pair; the current input status has been set to opening; all information is stored in the session isolation verification module, waiting to receive asynchronous events and perform verification.

[0045] Step S102. Asynchronous event reception, status event verification, and close command verification. Receive asynchronous events carrying local input lifecycle identifiers. For status events, update the current input state only if the local input lifecycle identifier carried by the status event matches the current local input lifecycle identifier and the current input state allows state transitions. For close commands, set the current input state to "closing and releasing the input interface instance" only if the expected local input lifecycle identifier carried by the close command matches the current local input lifecycle identifier.

[0046] Specifically, the core function of step S102 is to receive all asynchronous events carrying local input lifecycle identifiers, perform identifier verification and state transition validity verification on state events, and only process state events that belong to the current input lifecycle and whose state transition is valid; perform expectation identifier verification on close commands, and only close input interface instances that belong to the current input lifecycle, thereby avoiding the problem of late state events of old input interfaces incorrectly changing the state of new input interfaces and old close commands mistakenly closing new input interfaces.

[0047] Asynchronous event reception and classification: The session isolation verification module receives asynchronous events from various modules, including the input interface instance, input management service, and remote desktop client. Asynchronous events refer to events whose generation and processing are not completed at the same time, and whose arrival may be delayed. These include input interface display completion notifications, input interface hiding notifications, focus change notifications, user commands to close the input interface, and text or key input events generated by the user through the input interface. Due to the delay in the generation and transmission of asynchronous events, when a user performs rapid, continuous operations (closing the old interface and immediately opening the new one), events from the old interface may only arrive after the new interface is opened. Therefore, it is necessary to use identifier verification to distinguish the input lifecycle to which the event belongs.

[0048] Each asynchronous event carries a local input lifecycle identifier, which is attached to the input interface instance that generated the event when the event occurs (the input interface instance is assigned a current local input lifecycle identifier when it is created, and all subsequent events generated by it carry this identifier). Asynchronous events are divided into three categories: state events (events reflecting changes in the state of the input interface, such as display complete, hide complete, focus gained, focus lost, etc., used to drive the state transition of the input state machine); close commands (commands initiated by the user or system to close the input interface, carrying the local input lifecycle identifier of the input interface to be closed); and input events (text input or key operation events generated by the user through the input interface, which will be processed in detail in step S103).

[0049] Status event verification and status update: For status events, the local input lifecycle identifier carried by the status event is first extracted and compared with the current local input lifecycle identifier maintained in the session isolation verification module. Comparison results: If they match: the status event belongs to the lifecycle of the currently active input interface and is a valid event; the state transition validity verification continues. If they don't match: the status event belongs to the lifecycle of a closed old input interface (late event) or a new lifecycle that hasn't been opened yet; it is an invalid event, identified as a late event, and discarded. The current input state is not updated, and a discard log is recorded (event type, carried identifier, current identifier, discard reason). Identifier verification ensures that only status events generated by the currently active input interface can affect the current input state; late display notifications from the old interface will not incorrectly change the state of the new interface.

[0050] After the identifier verification passes, the system further checks whether the current input state allows the target state transition. The input state machine defines the following valid state transition paths: Opening → Inputtable (when the state event is that the input interface is fully displayed and has focus, the transition from Opening to Inputtable is allowed, indicating that the input interface is ready to receive input); Inputtable → Closing (when the state event is that the user triggers a close or close command, the transition from Inputtable to Closing is allowed); Opening → Closing (when the user triggers a close before the input interface is fully displayed, the transition from Opening to Closing is allowed); Closing → Closed (when the input interface is fully released, the transition to Closed occurs, and the current local input lifecycle identifier is cleared, awaiting the next opening). Invalid state transitions (such as Opening → Closed, Inputtable → Opening, Closing → Inputtable, etc.) are rejected, the current input state is not updated, and an illegal transition log is recorded. The state transition validity check ensures that the input state machine operates according to the predefined lifecycle path and will not cause state inconsistencies due to abnormal events.

[0051] When the identifier matches and the state transition is valid, the current input state is updated based on the state event. For example: when an input interface display completion event (carrying the current identifier) ​​is received and the current state is "on," the current input state is updated to "inputable," indicating that the input interface is ready. Subsequent input events that pass triple validation can then be injected into the remote session. When an input interface focus loss event is received and the current state is "inputable," a strategy can be used to decide whether to transition the state (e.g., brief focus loss does not change the state, while continuous focus loss exceeding a threshold transitions to "closing"). After the state update, relevant modules (input injection module, remote desktop client interface, etc.) are notified of the change in the current input state, and the interface display is updated (e.g., keyboard button highlighting, input ready prompts, etc.).

[0052] Disable command validation and release the input interface: For the close command, extract the expected local input lifecycle identifier carried by the close command. The close command is generated by the user clicking the close button, the user switching to another application, the user pressing the close shortcut key, or the system triggering the close due to resource reclamation, etc. When it is generated, the local input lifecycle identifier of the input interface to be closed is attached (i.e., the identifier of the currently active input interface when the command is generated).

[0053] The expected local input lifecycle identifier carried by the close command is compared with the current local input lifecycle identifier. Comparison result: If they match: the close command is for the currently active input interface and is a valid command; the close process is executed. If they don't match: the close command belongs to the old input interface (the user closes the old interface and immediately opens the new interface; the old interface's close command arrives with a delay, and the current identifier is now the new interface's identifier); the close command is ignored, the current input interface is not closed, and an ignore log is recorded. Expected identifier verification is a key mechanism to prevent old close commands from accidentally closing new input interfaces: without verification, when the old interface's close command arrives, it will close the newly opened interface, and the user will see the keyboard suddenly disappear and need to reopen it.

[0054] When the expected identifier matches, the current input state is set to "closing" and the current input interface instance is released. The release process includes: stopping the reception of new input events (the input interface instance no longer processes new text changes or key events); hiding the input interface (sending a hide request to the system input management service and disabling the soft keyboard); releasing the input interface window and control resources (destroying the window, unregistering the listener, disconnecting the input connection, and releasing memory); clearing the input event queue (discarding pending events that have not yet been injected); after the release is complete, the current input state is set to "closed", the current local input lifecycle identifier is set to an invalid value (such as 0 or empty), and the binding pair corresponding to the identifier is removed from the binding table of the session isolation verification module. After the release is complete, the system returns to the initial state of having no active input interface, and the user can reopen the input interface (a new current local input lifecycle identifier is generated, and step S101 is executed again).

[0055] After step S102 is completed, the system can correctly handle asynchronous events: state events update the state only when the identifier is consistent and the state transition is legal, and the close command closes the interface only when the expected identifier is consistent. This mechanism avoids the problems of old interface late events correcting the wrong state and old close commands accidentally closing the new interface. The input state machine runs stably on the predefined life cycle path.

[0056] Step S103. For an input event carrying a local input lifecycle identifier and a remote session identifier, simultaneously determine whether the local input lifecycle identifier carried by the input event is consistent with the current local input lifecycle identifier, whether the remote session identifier carried by the input event is consistent with the current remote session identifier, and whether the current input state is an input-available state. If all conditions are met, the input event is injected into the current remote session. If any condition is not met, the input event is discarded. When a remote control connection is detected to be disconnected, reconnected, or switched, the current remote session identifier is updated, making the input event carrying the old remote session identifier invalid.

[0057] Specifically, the core function of step S103 is to perform triple verification on the input events generated by the user through the input interface (consistent local input lifecycle identifier, consistent remote session identifier, and current input state). Only if all conditions are met is the input event injected into the current remote session; if any condition is not met, the input event is discarded. This ensures that the input event is injected only in the correct input lifecycle, the correct remote session, and the correct input state. At the same time, when the remote control connection is disconnected, reconnected, or switched, the current remote session identifier is updated, so that residual input events carrying the old remote session identifier are automatically invalidated, preventing input from the old connection from being injected into the new connection's remote session.

[0058] Triple validation of input events: Users perform input operations on the input interface (soft keyboard, physical keyboard, voice input, handwriting input, etc.), generating input events. Input events include confirmation text events (the displayed text content such as text, numbers, and symbols entered by the user) and control operation key events (keys that perform control functions, such as Enter, Backspace, Tab, arrow keys, and combination keys). Each input event is appended with two identifiers by the input interface instance when it is generated: a local input lifecycle identifier (the identifier of the input interface instance that generated the event) and a remote session identifier (the remote session identifier bound when the input interface is opened, i.e., the target remote session to which the event is expected to be injected). Input events are transmitted through an asynchronous communication link (input interface → input management service → input injection module), which may result in a delay.

[0059] After receiving an input event, the input injection module performs triple validation: First layer of verification: Local input lifecycle identifier consistency: Extract the local input lifecycle identifier carried by the input event and compare it with the current local input lifecycle identifier maintained by the session isolation verification module. Consistent: The input event was generated by the currently active input interface and belongs to the current input lifecycle; verification passes. Inconsistent: The input event was generated by a closed old input interface (residual event), or by a new interface that is not yet ready; verification fails. This verification ensures that only events generated by the currently active input interface are injected; residual events that are still propagating in the asynchronous link after the old interface is closed are discarded.

[0060] Second verification: Remote session identifier consistency: Extract the remote session identifier carried by the input event and compare it with the current remote session identifier. If they match: The target remote session of the input event is the currently active remote control connection, and the verification passes; if they don't match: The target remote session of the input event is a disconnected old connection or a different remote computer that has been switched to, and the verification fails. This verification ensures that input events are only injected into the currently active remote session. When a user switches from the first remote computer to the second or reconnects after a disconnection, residual input events from the old connection are discarded due to the mismatch in remote session identifiers and will not be injected into the new remote session, preventing commands, passwords, or codes from being entered into the wrong computer or window.

[0061] The third layer of verification: The current input state is set to be inputtable. This checks whether the current input state maintained by the session isolation verification module is set to be inputtable. If it is inputtable: the input interface is fully displayed and ready, allowing input event injection, and the verification passes. If it is not inputtable (opening, closing, or closed): the input interface is not yet ready or has been closed; injection at this time will cause input loss or errors, and the verification will fail. This verification ensures that input events are only injected when the input interface is ready, avoiding anomalies caused by injection during the opening or closing process.

[0062] Input event injection and discarding: When all three checks are satisfied, the input event is injected into the current remote session. The injection process is handled according to the event type: For confirmation text events: the text content is converted to a character encoding supported by the remote desktop protocol (such as UTF-16) and sent to the remote computer through the remote desktop protocol's text injection channel or keyboard event channel. The remote computer's currently active window receives the text and inserts it at the cursor position. For control operation key events: local key codes are mapped to remote desktop protocol scan codes or virtual key codes, modifier key states are set, and key press events, short delays (10ms to 50ms simulating real key press duration), and key release events are sent sequentially. Combination keys are sent in the sequence of "modifier key press → main key press and release → modifier key release." The remote computer receives the keyboard events and distributes them to the currently active window to execute the corresponding control function. After injection, an injection log is recorded (event type, content summary, injection time, local identifier, remote session identifier), and the injection result (success or failure) is fed back to the session isolation verification module.

[0063] Input events are discarded if any condition is not met, and the reason for discarding is recorded based on the condition: Inconsistent local input lifecycle identifier: the input event is considered to originate from an old input interface instance and is discarded; Inconsistent remote session identifier: the input event is considered to belong to an old remote session and is discarded; Current input state is not an inputtable state: the arrival time of the input event is considered invalid and is discarded. The system records the event type, the local input lifecycle identifier, the current local input lifecycle identifier, the remote session identifier, the current remote session identifier, the current input state, and the reason for discarding the input event for debugging and troubleshooting. Discarded events do not enter the injection queue and have no impact on the remote desktop session. The discarding operation is idempotent; discarding the same event multiple times does not produce side effects. If multiple consecutive events are discarded for the same reason (e.g., persistently mismatched remote session identifiers), the input injection module can trigger an alarm, notifying the session isolation verification module to check if the current state is abnormal (e.g., the remote connection has been disconnected but the input interface is still generating events), facilitating timely recovery.

[0064] Remote control connection status monitoring and session identifier update: The session isolation verification module monitors the remote control connection status in real time. Monitoring methods include: listening for callbacks indicating changes in the remote desktop client's connection status (triggered when events such as connection loss, successful reconnection, or connection switching occur); listening for changes in network status (remote connections typically disconnect when the network is down); and periodically sending heartbeat packets to check connection activity; if no response is received within a timeout period, the connection is considered broken.

[0065] When a remote control connection is detected to be disconnected, reconnected, or switched, the remote session identifier update process is triggered: When the remote control connection is lost: The current remote control connection is interrupted, and the connection corresponding to the current remote session identifier no longer exists. At this time, you can choose to: immediately update the current remote session identifier to an invalid value (making all input events carrying the old remote session identifier invalid), and close the current input interface (because the remote connection has been lost, the input has lost its target); or keep the input interface but disable input (set the current input state to a non-inputable state, and wait for reconnection to restore it).

[0066] After a successful remote control connection reconnection: A new current remote session identifier is generated for the newly established remote control connection, and this new identifier is bound and stored with the reconnected remote control connection. If the reconnection is to the same remote computer, the new identifier will be different from the old identifier (because it is a new connection session). If the user chooses to restore the input interface after reconnection, the current local input lifecycle identifier is rebound with the new remote session identifier (updating the remote session identifier field in the lifecycle-session binding pair), so that new events generated by the current input interface carry the new remote session identifier and can be injected into the reconnected remote session through the second layer of verification.

[0067] When the remote control connection switches to another remote computer: the connection with the first remote computer is lost, a new connection is established with the second, a new current remote session identifier is generated and bound to the new connection. The current input interface can be closed (because it has switched to a different remote computer, the user may need to reopen the input interface) or retained but rebound to the new remote session identifier. After the switch, input events carrying the old remote session identifier (the session on the first computer) are discarded due to a second-level validation mismatch and will not be injected into the second remote computer, completely avoiding the risk of inputting to the wrong computer.

[0068] After updating the current remote session identifier, all input events carrying the old remote session identifier are discarded during triple validation due to the mismatch of the remote session identifier, thus invalidating the old input events. This is one of the core mechanisms of this application: it eliminates the need to actively track and cancel old input events transmitted in the asynchronous link; simply updating the current remote session identifier automatically filters out old events during validation, making it simple and reliable, and avoiding complex asynchronous event tracking and cancellation logic.

[0069] After step S103 is completed, the system possesses complete input event session isolation capabilities: input events are injected only after triple verification; residual events from old input interfaces, residual events from old remote connections, and events arriving at invalid times are all discarded; when a remote connection is disconnected, reconnected, or switched, the old events are automatically invalidated by updating the remote session identifier. This entire mechanism ensures that in complex operation scenarios such as quickly switching the keyboard, switching remote computers, and reconnecting after a disconnection, the input content is always accurately injected into the correct remote session, preventing issues such as input errors, sudden keyboard disappearance, or commands being entered into the wrong computer.

[0070] In some embodiments, establishing a remote control connection and obtaining the current remote session identifier includes: initiating a remote control connection request and establishing a remote control connection with a remote computer; after the remote control connection is successfully established, generating a unique current remote session identifier for this remote control connection; and binding and storing the current remote session identifier with the remote control connection.

[0071] Initiating a remote control connection request establishes a remote control connection with the remote computer. The user selects a saved remote computer configuration or manually enters connection information on the remote desktop client's connection interface, including the remote computer's network address (Internet Protocol address or hostname), port number, authentication information (username, password or private key, token, biometrics), and session parameters (display resolution such as 1920×1080, color depth such as 24-bit, audio redirection switch, clipboard redirection switch, drive redirection switch, etc.). After the user clicks the connect button, the remote desktop client initiates a remote control connection request. The connection establishment process proceeds sequentially: domain name resolution (converting the hostname to an Internet Protocol address), a Transmission Control Protocol (TCP) three-way handshake to establish a reliable transmission connection, a Transport Layer Security (TLS) handshake to establish an encrypted channel (all subsequent data transmission is encrypted), user authentication (the remote computer verifies the username and password or other credentials), session parameter negotiation (the client and server negotiate display resolution, color depth, supported virtual channels, etc.), and the remote computer creating a session and returning a success notification. The entire connection establishment process typically takes 1 to 10 seconds, depending on network latency and the remote computer's performance. After the connection is successfully established, the screen of the remote computer is transmitted to the client through a virtual channel after being compressed by video encoding (H.264, H.265 / high efficiency video encoding, etc.). The client decodes the video and displays the remote desktop screen in full screen on the first display screen.

[0072] After a successful remote control connection is established, a unique current remote session identifier is generated for this connection. The current remote session identifier can be generated in one of the following ways: using the session identifier assigned by the remote desktop protocol itself (many remote desktop protocols assign a unique integer identifier to each session during session establishment, which can be directly used as the current remote session identifier without additional generation); or generating a unique identifier locally on the client side (if the protocol does not assign an identifier or requires more global uniqueness, the client uses an auto-incrementing sequence number (maintaining a 32-bit unsigned integer global counter, atomically incrementing, ranging from 0 to 4294967295), a universally unique identifier (128-bit UUID, with extremely strong global uniqueness), or a combination of a timestamp and a random number (the lower 32 bits of a millisecond-level timestamp plus a 16-bit random number, balancing time order and avoiding conflicts within the same millisecond). The current remote session identifier remains unchanged throughout the entire lifecycle of the remote control connection, uniquely identifying this connection session.

[0073] The current remote session identifier is bound to the remote control connection and stored. The session management module maintains a remote session information table, using the current remote session identifier as the key and remote session information objects as values. This table includes: remote session identifier, remote computer identifier (address, name, operating system type and version), user information (login username, domain, permission level), connection information (establishment time, connection type: direct / relay / VPN, network protocol, encryption protocol and cipher suite, current bandwidth estimate, round-trip time), session parameters (negotiated display resolution, color depth, dots per inch, list of enabled redirection functions), session status (connecting / connected / disconnected / reconnecting, last active time, idle duration), and a list of associated local input lifecycle identifiers (local identifiers of all input interfaces opened during this remote session, used for tracking and cleanup). After binding and storage, all subsequent operations requiring access to the remote control connection (input event injection, screen data reception, connection status monitoring, etc.) will find the corresponding connection instance and session information through the current remote session identifier. When the remote control connection is disconnected, reconnected, or switched, a new current remote session identifier is generated and a new binding entry is created. The old entry is marked as disconnected and retained for a period of time for logging and debugging, and can then be cleaned up.

[0074] In some embodiments, the step of responding to the input interface opening operation and generating a current local input lifecycle identifier includes: responding to the input interface opening operation when the user triggers the input interface opening operation; generating a current local input lifecycle identifier that is not repeated within a predetermined range, wherein the current local input lifecycle identifier adopts a monotonically increasing sequence number or a globally unique identifier; and associating the current local input lifecycle identifier with the current input interface opening operation.

[0075] When a user triggers an input interface opening operation, the system responds by initiating the operation. The input interface opening operation can be triggered in several ways: by user-initiated actions (clicking the floating keyboard icon on the remote desktop client interface; this button is typically semi-transparent and located in a corner of the screen, not obstructing the remote view; clicking an input area in the remote desktop view, such as a text box, address bar, or terminal window; pressing a hardware keyboard shortcut key; triggering via voice assistant commands such as "open keyboard"; or triggering via custom gestures such as three-finger swipes or swipes); or by application-initiated actions (the remote desktop client receives information about the currently active window from the remote computer via the remote desktop protocol virtual channel; when the focused control is a text editing control, a prompt appears asking "Text input area detected, open keyboard?", which is triggered after user confirmation; or a prompt appears after detecting a blinking cursor or the outline of an input box through remote screen image recognition). After the input interface opening operation is triggered, the remote desktop client's input management module responds by executing the input interface creation and initialization process, including creating the input interface window, initializing native editable controls, registering event listeners, and setting the input type (the specific structure and creation process of the input interface are detailed in other embodiments; this embodiment focuses on the generation and association of lifecycle identifiers).

[0076] Generate a unique current local input lifecycle identifier within a predetermined range. This identifier uniquely identifies the opening, use, and closing lifecycle of an input interface and is one of the core identifiers for session isolation verification. The generation methods include: a monotonically increasing sequence number (the input management module maintains a 32-bit unsigned integer global counter, initially set to 0. Each time the input interface is opened, an atomic increment operation is performed, and the incremented value is returned as the current local input lifecycle identifier. The advantages of a monotonically increasing sequence number are its simplicity and efficiency, and the size of the sequence number can reflect the order of opening (a larger sequence number indicates a later opening). The 32-bit unsigned integer range is from 0 to 4294967295, which will not be exhausted within one running cycle of the terminal device (usually a few hours to a few days, with a maximum of a few opening operations per second). Even if it is exhausted and wraps back to 0, the input interface corresponding to the old identifier has already been closed, so there will be no conflict); and a globally unique identifier (calling the operating system's general unique identifier generation interface to generate a 128-bit UUIDv4 (based on random numbers), in the format "xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx". It has extremely strong global uniqueness, and the probability of collision is negligible. It is suitable for scenarios that require unique identifiers across processes or devices, but the string is relatively long (36 characters), and the storage and transmission overhead is slightly large). In this embodiment, a monotonically increasing sequence number is preferred to balance simplicity and efficiency; a globally unique identifier is used when cross-process uniqueness is required. Generation must be an atomic operation to ensure that duplicate identifiers are not generated in a multi-threaded environment (such as when users quickly and continuously click the start button or multiple remote sessions are running simultaneously). Thread safety is guaranteed using atomic integers, mutexes, or single-threaded serialization generation.

[0077] The current local input lifecycle identifier is associated with the current input interface opening operation. The association method includes: assigning the current local input lifecycle identifier to a member variable of the newly created input interface instance (the input interface instance holds this identifier throughout its entire lifecycle, and all asynchronous events it generates (status events, close commands, input events) are appended with this identifier, allowing each event to be traced back to the lifecycle of the input interface that generated it); creating a binding entry with the current local input lifecycle identifier as the key in the lifecycle-session binding table of the session isolation verification module, recording the associated remote session identifier, input interface instance reference, current input status, opening time, etc.; adding a mapping between this identifier and the input interface instance to the active input interface list of the input management module, facilitating quick retrieval of the input interface instance by identifier. After association, the current local input lifecycle identifier becomes the unique identifier for the current input interface lifecycle, persisting throughout the opening, use, and closing process, used for asynchronous event attribution judgment and session isolation verification. When the input interface is closed and released, this identifier is removed from the activity list and binding table, and the identifier is no longer associated with any active input interface, but the global counter does not wrap around (monotonically increasing), ensuring that newly generated identifiers for subsequent openings do not duplicate the old identifier.

[0078] In some embodiments, binding the current local input lifecycle identifier with the current remote session identifier and setting the current input state to "ongoing" includes: establishing a binding relationship between the current local input lifecycle identifier and the current remote session identifier to form a lifecycle-session binding pair; setting the current input state to "ongoing", and disallowing input events from being injected in the "ongoing" state; and storing the lifecycle-session binding pair and the current input state in the session isolation verification module.

[0079] Establish a binding relationship between the current local input lifecycle identifier and the current remote session identifier, forming a lifecycle-session binding pair. The current local input lifecycle identifier identifies a single input interface lifecycle, and the current remote session identifier identifies a single remote control connection session. Binding these two together forms a lifecycle-session binding pair, indicating that "the input event generated by this input interface is expected to be injected into the remote session corresponding to this remote control connection." The binding pair is established after the current local input lifecycle identifier is generated but before the input interface is fully displayed, ensuring that the first event generated by the input interface can be found in the target remote session through the binding relationship. The binding pair includes the following fields: local input lifecycle identifier (key), remote session identifier (the target remote session to be bound), binding establishment time, input interface instance reference (the identifier allows quick access to the input interface instance to perform operations such as hiding or releasing), current input state (the current state of the state machine), state update history (records the time and reason for each state transition for debugging), and input event statistics (the number of input events received, validated, or discarded within this lifecycle for quality monitoring). The binding pair is stored in the binding table (hash table) of the session isolation validation module, using the local input lifecycle identifier as the key, supporting quick lookup of the binding pair by identifier. When there are multiple active input interfaces (such as multiple remote sessions each opening an input interface), there are multiple binding pairs in the binding table. The events of each input interface can find the corresponding binding pair and remote session identifier through its own local identifier, thus achieving parallel isolation of multiple input interfaces.

[0080] Set the current input state to "On". The current input state is the core state variable of the input state machine, which defines four states and legal transition paths for the input interface lifecycle: On (the input interface has been triggered to open but is not yet fully displayed; input events are not allowed in this state); Inputtable (the input interface is fully displayed and has focus; the user can input normally; input events that pass triple validation are allowed in this state); Closing (the input interface has been triggered to close but is not yet fully released; input events are not allowed in this state); Closed (the input interface has been fully released; there is no active input interface; injection is not allowed in this state, and the current local input lifecycle flag has been invalidated). Legal state transition paths: On → Inputtable (the input interface is fully displayed and has focus); On → Closing (the user triggers closure before display is complete); Inputtable → Closing (the user triggers closure or the system closes); Closing → Closed (the input interface is fully released). Invalid transitions (such as On → Closed, Inputtable → On, Closing → Inputtable) are rejected. When a binding is established, the input interface is just being created and has not yet been displayed. Therefore, the current input state is initialized to "Opening". Input events are not allowed to be injected in the "Opening" state because the input interface may not have completed window creation, focus acquisition, or input connection establishment at this time. The user's input operation may not have been captured correctly, and premature injection will lead to input loss or malfunction. At the same time, the "Opening" state also serves as a brief transitional state to ensure that the input interface is fully ready before accepting input, thereby improving input reliability.

[0081] The lifecycle-session binding pairs and the current input state are stored in the session isolation verification module. This module is the core functional module of this application, responsible for maintaining and verifying all session isolation-related states. Its internal data structure includes: the current local input lifecycle identifier (the identifier of the currently active input interface; invalid when there is no active interface), the current remote session identifier (the identifier of the currently active remote control connection), the current input state (the state machine state of the currently active input interface), the lifecycle-session binding table (a hash table of all active binding pairs), asynchronous event verification logic (processing logic for verifying the identifiers and states of state events, close commands, and input events), and remote connection monitoring logic (logic for monitoring the remote control connection state and triggering remote session identifier updates). The session isolation verification module can be implemented as an independent module or service within the remote desktop client application, running in an independent thread with its own message queue. All asynchronous events are first sent to the message queue of the session isolation verification module, which processes them serially (ensuring the atomicity and thread safety of state updates, avoiding race conditions caused by concurrent state modifications by multiple threads). After storage, the session isolation verification module enters an event waiting state, ready to receive and process asynchronous events.

[0082] In some embodiments, receiving asynchronous events carrying local input lifecycle identifiers, for status events, updating the current input state only when the local input lifecycle identifier carried by the status event matches the current local input lifecycle identifier and the current input state allows for state transition, includes: receiving asynchronous events, including status events, close commands, and input events, each asynchronous event carrying a local input lifecycle identifier; for status events, extracting the local input lifecycle identifier carried by the status event and comparing the local input lifecycle identifier carried by the status event with the current local input lifecycle identifier; if the local input lifecycle identifier carried by the status event matches the current local input lifecycle identifier and the current input state allows for target state transition, updating the current input state according to the status event; status events with mismatched identifiers are identified as late events and discarded.

[0083] The system receives asynchronous events, including status events, close commands, and input events. Each asynchronous event carries a local input lifecycle identifier. The session isolation verification module's message queue receives asynchronous events generated by various modules (input interface instances, system input management services, remote desktop clients, network modules, etc.). Asynchronous events refer to events whose generation and processing have a time difference, and events may arrive late. Due to asynchronous delays in input interface display, network transmission, and inter-process communication, when a user performs rapid, continuous operations (such as closing an old keyboard and immediately opening a new one), events from the old keyboard (such as displaying a completion notification) may only arrive after the new keyboard is opened. If the old events are not processed indiscriminately, it will cause the new keyboard's state to become disordered. Each asynchronous event is appended with a local input lifecycle identifier by the input interface instance that generated it (the current local input lifecycle identifier is assigned when the input interface instance is created, and all subsequent events generated by it carry this identifier), so that each event can be traced back to the lifecycle of the input interface that generated it. Asynchronous events are divided into three categories: state events (events that reflect changes in the state of the input interface, such as display complete, hide complete, focus gained, focus lost, etc., used to drive the state transition of the input state machine); close commands (commands initiated by the user or system to close the input interface, carrying the identifier of the input interface to be closed); and input events (text input or key operations generated by the user through the input interface, which will be handled in detail in subsequent embodiments).

[0084] For status events, the local input lifecycle identifier carried by the status event is extracted and compared with the current local input lifecycle identifier. The session isolation verification module retrieves an asynchronous event from the message queue, determines that the event type is a status event, and extracts the local input lifecycle identifier field from the event data structure. The current local input lifecycle identifier is the identifier of the currently active input interface maintained by the session isolation verification module (set when the input interface is opened, and set to an invalid value after being closed and released). The two are precisely matched and compared (integers or globally unique identifiers are equal). Comparison results: If consistent: the status event is generated by the currently active input interface, belongs to the current input lifecycle, is a valid event, and the state transition legality verification continues; if inconsistent: the status event is generated by a closed old input interface (late event, the completion notification of the old interface is delayed after it is closed) or by the input interface of another remote session (multi-session parallel scenario), is an invalid event. Identifier verification is the first gatekeeper in state event handling, ensuring that only state events generated by the currently active input interface can affect the current input state, and that late display notifications from the old interface will not change the state of the new interface incorrectly: this is the core mechanism for solving the problem of "the old keyboard has already displayed a notification that it will arrive later and then change the state of the new keyboard incorrectly".

[0085] If the local input lifecycle identifier carried by the state event is consistent with the current local input lifecycle identifier, and the current input state allows the target state transition, the current input state is updated according to the state event. After the identifier verification passes, the second gate is executed: state transition validity verification. The state event carries target state information (or infers the target state based on the event type, such as the target state corresponding to the display completion event being an inputtable state, and the target state corresponding to the focus loss event being either closing or remaining inputtable). It checks whether the transition from the current input state to the target state is within the valid transition path defined by the input state machine: current state is opening and target state is inputtable: valid (input interface display complete and focus acquired, transitioning from open to ready); current state is opening and target state is closing: valid (user triggers closing before display completion); current state is inputtable and target state is closing: valid (user triggers closing); current state is closing and target state is closed: valid (input interface release complete); other transition combinations: invalid, update rejected. State transition validity checks ensure that the input state machine runs according to the predefined lifecycle path and will not be corrupted by abnormal events (such as receiving a display completion event in an input-available state).

[0086] After both checks pass, the current input state is updated based on the status event: the current input state is transitioned from the current state to the target state; this transition (state before transition, state after transition, trigger event type, transition time) is recorded in the state update history of the bound pair; the relevant modules are notified of the state change (the input injection module decides whether to allow injection based on the new state, the remote desktop client interface updates the highlighted state of the keyboard buttons and the input ready prompt, and the input interface instance performs corresponding operations such as showing or hiding based on the new state). For example: when the input interface displays a completion event (carrying the current identifier) ​​and the current state is "on", the current input state is updated to an input-ready state. The input injection module then allows the injection of input events that have passed the triple checks, and the interface displays an "input ready" prompt that disappears after 2 seconds.

[0087] Status events with mismatched identifiers are identified as late events and discarded. When the local input lifecycle identifier carried by a status event is inconsistent with the current identifier, the event is identified as a late event (belonging to the lifecycle of an old, closed input interface) and discarded: the current input state is not updated, and no module is notified; the event type, carried identifier, current identifier, event arrival time, and reason for discarding (identifier mismatch, late event) are recorded in the discard log; after discarding, the next event in the message queue is processed. Discarding late events is idempotent, and discarding the same event multiple times does not produce side effects. If a large number of late events arrive in a short period of time (such as when a user quickly and continuously switches the keyboard multiple times), the session isolation verification module can count the number of late events for performance analysis and optimization (e.g., considering whether to actively cancel unfinished asynchronous operations when closing the input interface to reduce late events, but this application can already correctly handle late events through identifier verification, and active cancellation is an optional optimization).

[0088] In some embodiments, setting the current input state to "closing" and releasing the input interface instance only when the expected local input lifecycle identifier carried by the close command matches the current local input lifecycle identifier includes: for the close command, extracting the expected local input lifecycle identifier carried by the close command, comparing the expected local input lifecycle identifier carried by the close command with the current local input lifecycle identifier; when the expected local input lifecycle identifier carried by the close command matches the current local input lifecycle identifier, setting the current input state to "closing" and releasing the current input interface instance; when the expected local input lifecycle identifier carried by the close command does not match the current local input lifecycle identifier, ignoring the close command.

[0089] For the close command, the expected local input lifecycle identifier carried by the close command is extracted and compared with the current local input lifecycle identifier. The close command is generated in the following ways: the user clicks the close / collapse button on the input interface; the user clicks the keyboard icon button on the remote desktop client interface (toggle close); the user presses the hardware keyboard close shortcut key; the user switches to another application (the input interface loses its foreground state, triggering automatic close); the system triggers close due to resource reclamation (low memory); the remote control connection is disconnected, triggering associated close. The expected local input lifecycle identifier is appended when the close command is generated: this identifier is the identifier of the currently active input interface at the time the command is generated, indicating which input interface lifecycle the command expects to close. The timing of appending the expected identifier is crucial: the current local input lifecycle identifier is read and appended the identifier the moment the command is generated, and even if the current identifier changes due to the user opening a new interface thereafter, the expected identifier carried by the command remains unchanged. After retrieving the close command from the message queue, the session isolation verification module extracts the expected local input lifecycle identifier field from the command data structure and performs a precise match and comparison with the current local input lifecycle identifier maintained by the session isolation verification module.

[0090] If the expected local input lifecycle identifier carried by the close command matches the current local input lifecycle identifier, the current input state is set to "closing," and the current input interface instance is released. A match indicates that the close command is for the currently active input interface and is a valid command; the close process is then executed. The first step is state transition: Set the current input state to "Close". Input events are not allowed to be injected while the input is in the "Close" state (third-level validation will fail), ensuring that no new input events are injected during the closing process and avoiding exceptions caused by injection. Record this transition in the state update history of the bound pair (inputable state / Opening → Closing, trigger reason: closing command).

[0091] The second step is to stop receiving new input events: The input interface instance is notified to stop processing new text changes or key presses (the input interface enters a closed state; newly generated input events are directly discarded or marked as closed events by the input interface instance and are no longer forwarded to the session isolation verification module); the input event queue is cleared (uninjected pending events are discarded; for received but not injected confirmation text, injection is determined based on the reason for closing: if the user actively closes, injection is not performed (the user may not want to retain incomplete input); if the remote connection is disconnected, injection is not possible; by default, clearing the queue does not inject); all unfinished timers and asynchronous tasks (such as display timeout timers, focus loss timeout timers, etc.) are canceled.

[0092] The third step is to hide the input interface: a hide request is sent to the system input management service via the input connection, requesting the soft keyboard to be collapsed. The hide request is an asynchronous operation; the input method service executes a hide animation (such as swiping down or fading out) and destroys the interface. The input method is confirmed to be hidden via a display status listener callback; if no confirmation is received within a timeout, the input connection is forcibly disconnected to ensure closure.

[0093] Fourth step, release the input interface instance: clear the focus of the native editable controls; destroy the input interface window (release all view resources in the window view hierarchy, including native editable controls, all listeners, and all subviews; remove the window from the window manager, and the window token becomes invalid); mark the input delegate instance as destroyed (reject subsequent method calls); unregister all system-level listeners (display change listeners, network status listeners, etc., to avoid memory leaks); disconnect the input connection (end the combined text and notify the input method service to release connection resources); close the communication channel; release temporary data structures.

[0094] Step 5, State Cleanup: After the input interface is released, set the current input state to "closed"; set the current local input lifecycle flag to an invalid value (0 or empty); remove the binding pair corresponding to this flag from the lifecycle-session binding table; notify the remote desktop client to update the interface (restore the keyboard icon buttons to an inactive state and clear the input ready prompt); record the closing completion log (closing reason, release time, resource release result). After cleanup, the system returns to the initial state of having no active input interface, and the user can reopen the input interface (generate a new flag and re-execute the reopening process).

[0095] If the expected local input lifecycle identifier carried by the close command is inconsistent with the current local input lifecycle identifier, the close command is ignored. A mismatch indicates that the close command belongs to the old input interface (typical scenario: the user closes the old interface (old identifier such as 5) and immediately opens the new interface (new identifier such as 6). Due to asynchronous delay, the close command for the old interface arrives only after the new interface is opened. At this time, the command carries the expected identifier 5, while the current identifier is 6, resulting in a mismatch). If a close command is executed in this case, the newly opened interface will be incorrectly closed: this is precisely why users see "the keyboard suddenly disappears and requires repeated clicks." The expected identifier verification mechanism ensures that the close command for the old interface is ignored, not affecting the new interface, fundamentally solving the problem. When ignored, a log is recorded (command type, expected identifier, current identifier, reason for ignoring), no close operation is performed, and the next event in the message queue continues to be processed. The ignoring operation is idempotent; ignoring the same command multiple times does not produce side effects.

[0096] In some embodiments, the step of injecting the input event into the current remote session when all three conditions are met—that the local input lifecycle identifier carried by the input event matches the current local input lifecycle identifier, the remote session identifier carried by the input event matches the current remote session identifier, and the current input state is an input-enabled state—includes the following: for an input event, extracting the local input lifecycle identifier and the remote session identifier carried by the input event; simultaneously determining that the local input lifecycle identifier carried by the input event matches the current local input lifecycle identifier, the remote session identifier carried by the input event matches the current remote session identifier, and the current input state is an input-enabled state; when all three conditions are met, injecting the input event into the current remote session, and having the current remote session send the input event to the remote computer.

[0097] For input events, the local input lifecycle identifier and remote session identifier carried by the input event are extracted. Input events are generated when a user performs input operations on the input interface (soft keyboard, physical keyboard, voice input, handwriting input, etc.). Input events are divided into confirmation text events (text content that can be displayed, such as text, numbers, symbols, and emoticons entered by the user, generated by the input method's text submission callback) and control operation key events (keys that perform control functions, such as Enter, Backspace, Tab, arrow keys, Delete key, function keys, and combination keys, generated by the input method's key event callback). Each input event is appended with two identifiers by the input interface instance when it is generated: a local input lifecycle identifier (the identifier of the input interface instance that generated the event, assigned when the input interface is created and held throughout its lifecycle); and a remote session identifier (the remote session identifier bound when the input interface is opened, i.e., the target remote session for which the event is expected to be injected, obtained from the lifecycle-session binding pair). Input events are transmitted via an asynchronous communication link (input interface → system input management service → input injection module), which may result in delays (especially during rapid user operations or network fluctuations). After retrieving the input event from the event queue, the input injection module extracts two fields, the local input lifecycle identifier and the remote session identifier, from the event data structure for subsequent triple verification.

[0098] Simultaneously, three conditions are evaluated. The input injection module (or session isolation verification module) performs triple validation on the input event. The triple validation is a logical AND relationship, and all three conditions must be met for injection to proceed. First layer: Local input lifecycle identifier consistency: Compare the local input lifecycle identifier carried by the input event with the current local input lifecycle identifier. Consistency indicates that the input event was generated by the currently active input interface and belongs to the current input lifecycle; inconsistency indicates that the event was generated by a closed old input interface (residual event, an event still being transmitted in the asynchronous link after the old interface was closed) or by the input interface of another remote session (multi-session parallel scenario). This check ensures that only events generated by the currently active input interface are injected.

[0099] The second layer: Remote session identifier consistency: Compare the remote session identifier carried by the input event with the current remote session identifier. A match indicates that the target remote session of the event is the currently active remote control connection; a mismatch indicates that the target of the event is a disconnected old connection or a different remote computer that has been switched to. This verification ensures that input events are only injected into the currently active remote session. When the user switches remote computers or reconnects, residual events from the old connection are discarded due to identifier mismatch and will not be injected into the new remote session, preventing commands, passwords, or codes from being entered into the wrong computer or window.

[0100] The third layer: Current input state is input-ready: This checks whether the current input state maintained by the session isolation verification module is input-ready. An input-ready state indicates that the input interface is fully displayed and has focus, allowing the user to input normally; other states (opening, closing, closed) indicate that the input interface is not yet ready or has been closed, and injection in these states will cause input loss or errors. This verification ensures that input events are only injected when the input interface is ready.

[0101] The three conditions can be checked in parallel (reading three current state values ​​simultaneously and comparing them separately) or sequentially (in the order of first level → second level → third level, terminating the check and discarding the result if any condition is not met), and the final result will be consistent. Locking or atomic reading is required when reading the current state value during the check process to ensure that the read state value is a consistent snapshot (to prevent the state from being modified by other threads during the check process, which could lead to inaccurate results).

[0102] When all three conditions are met, the input event is injected into the current remote session, which then sends the input event to the remote computer. After all three checks pass, the input injection module performs the injection based on the event type. Confirmation text event injection: Convert the confirmation text content into a character encoding supported by the remote desktop protocol (such as UTF-16, ensuring correct transmission of Chinese characters, emoticons, and special symbols; pay attention to handling multi-byte characters of proxy pairs); Select the injection method according to the text length: Short text (single or a few characters) uses character sequence injection (converting the text character by character into a unified code point and sending it through the keyboard event channel of the remote desktop protocol, with good compatibility); Long text (a sentence or a paragraph) uses clipboard injection (writing the text to the remote clipboard, sending it through the clipboard virtual channel, and then sending the paste shortcut key, i.e., the control key plus V, the remote computer's currently active window executes the paste insertion, which is efficient and can correctly handle special characters); Send the injected data to the remote computer through the remote control connection corresponding to the current remote session; The operating system of the remote computer receives the text insertion operation, distributes it to the currently active window (the application with input focus), and inserts the text at the cursor position.

[0103] Control operation key event injection: Map local operating system key codes to scan codes or virtual key codes defined by the remote desktop protocol (key code definitions differ across systems; a mapping table is used for conversion, covering all commonly used keys); Set the modifier key flag bit for remote desktop protocol keyboard events based on the status of event modifier keys (whether the shift key, control key, alternate key, or function key is pressed); Sequentially send key press events, short delays (10ms to 50ms to simulate the actual key press duration; the original press duration can be used for actual physical keyboard events), and key release events; Send combination keys in the sequence of "modifier key pressed → main key pressed and released → modifier key released" to simulate the actual combination key operation sequence; Send keyboard events to the remote computer through the remote control connection corresponding to the current remote session; The remote computer operating system receives keyboard events and distributes them to the currently active window, executing the corresponding control functions (Enter to confirm / execute command, Backspace to delete the character before the cursor, Tab to switch focus / auto-completion, combination keys to execute copy / paste / undo, etc.).

[0104] After injection, an injection log is recorded (event type, content summary, injection time, local identifier, remote session identifier, injection method, and injection result of success or failure). The injection result is fed back to the session isolation verification module for quality monitoring. If injection fails (remote connection interruption, protocol error), a limited retry is performed (e.g., 2 times). If the retry still fails and the connection has been broken, the remote session identifier update process is triggered (detailed in Example 8).

[0105] In some embodiments, discarding an input event when any of the conditions is not met includes: if the local input lifecycle identifier carried by the input event is inconsistent with the current local input lifecycle identifier, the input event is determined to originate from an old input interface instance, and the input event is discarded; if the remote session identifier carried by the input event is inconsistent with the current remote session identifier, the input event is determined to belong to an old remote session, and the input event is discarded; if the current input state is not an input-available state, the arrival time of the input event is determined to be invalid, and the input event is discarded; the event type, the current local input lifecycle identifier, the current remote session identifier, and the reason for discarding the input event are recorded.

[0106] When the local input lifecycle identifier carried by an input event is inconsistent with the current local input lifecycle identifier, the input event is considered to originate from the old input interface instance and is discarded. If the first layer of the triple check fails, the local identifier carried by the input event differs from the current identifier, indicating that the event was generated by a closed old input interface instance. After the old interface is closed, its generated input events may still be transmitted in the asynchronous communication link (input interface → system input management service → input injection module), arriving at the input injection module with a delay. A typical scenario: A user enters text in the old interface, immediately closes the old interface, and opens a new interface. The input events for the last few characters in the old interface may arrive only after the new interface is opened. At this time, these events carry the old local identifier, which does not match the current new identifier, and are therefore considered residual events from the old input interface instance and discarded. If not discarded, the residual text from the old interface will be injected into the current remote session, potentially interfering with the content the user is editing in the new interface, causing input errors. Discarding the event does not enter the injection queue and has no impact on the remote desktop session.

[0107] When the remote session identifier carried by an input event does not match the current remote session identifier, the input event is considered to belong to an old remote session and is discarded. If the second check in the triple check fails, the remote session identifier carried by the input event differs from the current identifier, indicating that the target remote session of the event is a disconnected old connection or a different remote computer that has been switched over. Typical scenario: A user switches from a first remote computer (session identifier A) to a second remote computer (session identifier B). The last few characters entered on the first computer before the switch may arrive after the switch. These events carry remote session identifier A, which does not match the current identifier B, and are therefore considered remnants of the old remote session and discarded. If not discarded, the input from the first computer (which may contain commands, passwords, or codes) could be injected into the remote session of the second computer, entering the wrong computer or window, potentially causing serious consequences (such as executing dangerous commands on the wrong computer). Remote session identifier verification is the core mechanism to prevent input from entering the wrong computer.

[0108] If the current input state is not an input-ready state, the timing of the input event is considered invalid, and the input event is discarded. If the third check in the triple check fails, the current input state is either "opening," "closing," or "closed," not an input-ready state. In the "opening" state, the input interface is not yet fully displayed (the window may not have been created, focus may not have been acquired, and the input connection may not have been established). At this time, the user's input operation may not have been correctly captured by the input interface, and premature injection will lead to input loss or errors. In the "closing" state, the input interface has already triggered closure, and the user may have stopped inputting. Events arriving at this time may be residual events from before closure and should not be injected. In the "closed" state, the input interface has been released, there is no active input interface, and no input events should arrive (if any, they are abnormal residual events). Events arriving at invalid times are discarded, ensuring that input events are only injected when the input interface is fully ready, improving input reliability.

[0109] Record the event type, current local input lifecycle identifier, current remote session identifier, and reason for discarding input events. Each time an input event is discarded, the input injection module (or session isolation verification module) records a discard log. Log fields include: event type (confirmation text event or control operation key event); event content summary (the first few characters of the confirmation text or the key code of the control key, used for debugging to understand what content was discarded); local input lifecycle identifier carried by the event; current local input lifecycle identifier (used for comparison); remote session identifier carried by the event; current remote session identifier (used for comparison); current input status (status at the time of discard, used to determine if the timing is invalid); reason for discarding (local identifier mismatch - remnant of the old input interface, remote session identifier mismatch - remnant of the old remote session, invalid status - invalid arrival time); event arrival timestamp; event sequence number. Discard logs are stored in local log files or an in-memory log buffer for developers to use for debugging and troubleshooting. When users report abnormal input, developers can analyze the discard logs to identify which type of event was discarded and why, thus pinpointing the root cause of the problem (e.g., frequent mismatches in remote session identifiers indicate a large number of residual events during connection switching, allowing for optimization of the event queue cleanup logic). Discard logs can be configured with recording levels (e.g., only recording discard events with mismatched remote session identifiers, as these events may involve security risks and require focused monitoring) to prevent excessive log volume from impacting performance.

[0110] Idempotency and Exception Handling of Drop Operations: Drop operations are idempotent. Dropping the same event multiple times (e.g., the event is repeatedly delivered) does not produce side effects; simply recording the repeated drop in the log is sufficient. If an exception occurs during the drop process (e.g., log writing failure), it does not affect the drop operation itself (the event is still dropped and not injected), and the exception is recorded in the system error log. If multiple consecutive input events are dropped for the same reason (e.g., the remote session identifier continues to mismatch and exceeds a threshold), the input injection module triggers an alarm to notify the session isolation verification module to check if the current state is abnormal (e.g., the remote connection has been disconnected but the input interface is still generating events, the current remote session identifier has not been updated correctly, etc.). This facilitates timely detection and recovery of abnormal states, preventing prolonged and excessive dropouts that could lead to unresponsive user input.

[0111] In some embodiments, updating the current remote session identifier when a remote control connection is detected to be disconnected, reconnected, or switched, thereby invalidating input events carrying the old remote session identifier, includes: real-time monitoring of the remote control connection status; triggering a remote session identifier update process when a remote control connection is detected to be disconnected, reconnected, or switched; generating a new current remote session identifier after a successful reconnection or switch, and binding the new current remote session identifier to the reconnected or switched remote control connection; after updating the current remote session identifier, all input events carrying the old remote session identifier are discarded during the three-condition verification due to the mismatch of the remote session identifier, thus invalidating the old input events; the current input interface can be closed simultaneously, or the input interface can be retained but input can be disabled.

[0112] Real-time monitoring of remote control connection status triggers a remote session identifier update process when a remote control connection is detected to be disconnected, reconnected, or switched. The session isolation verification module (or the remote desktop client's connection management module) monitors the remote control connection status in real time through the following methods: listening for connection status change callbacks from the remote desktop client (the remote desktop protocol triggers callback notifications when events such as connection disconnection, successful reconnection, or connection switching occur; this is the most timely monitoring method); listening for network status changes (the operating system sends network status broadcasts when the network is disconnected or switched; the remote connection usually disconnects when the network is disconnected, which can be used as an auxiliary monitoring method); periodically sending heartbeat packets to check connection activity (sending heartbeat packets through the remote control connection at fixed intervals, such as 5 seconds; if no response is received after 10 seconds, the connection is considered disconnected; this is suitable for scenarios where the protocol does not provide status callbacks); and monitoring changes in the remote desktop screen (if the remote screen does not update for a long time and is not caused by user operation, it may indicate a connection disconnection, which can be used as an auxiliary judgment). The remote session identifier update process is triggered when any of the following conditions are detected: remote control connection is interrupted (due to network interruption, remote computer shutdown, user-initiated disconnection, etc.); remote control connection is reconnected (automatically or manually reconnecting to the same remote computer after disconnection, and the connection is restored); remote control connection is switched (switching from a connection to the first remote computer to a connection to the second remote computer, or switching between different sessions on the same computer).

[0113] After a successful reconnection or switchover of the remote control connection, a new current remote session identifier is generated and bound to the reconnected or switched remote control connection. Upon triggering the update process, the following actions are executed based on the connection change type: When the connection is lost: The current remote control connection is interrupted, and the connection corresponding to the current remote session identifier no longer exists. There are two handling strategies: Strategy 1: Immediately update the current remote session identifier to an invalid value (e.g., 0 or empty), making all input events carrying the old remote session identifier immediately invalid (secondary validation mismatch), and simultaneously close the current input interface (because the remote connection is broken, input loses its target, keeping the input interface is meaningless and may cause the user to continue inputting, generating more residual events); Strategy 2: Keep the current remote session identifier unchanged but set the current input state to a non-inputable state (e.g., closing), prohibiting input event injection, and waiting for reconnection: If reconnection is successful within a timeout period (e.g., 30 seconds), the input state is restored; if reconnection fails within the timeout period, Strategy 1 is executed, updating the identifier to invalid and closing the input interface. The advantage of Strategy 2 is that the user can continue inputting after reconnection without reopening the interface; the disadvantage is that user input is discarded during the disconnection period (because the state is non-inputable). The advantage of Strategy 1 is clear state; the disadvantage is that the input interface needs to be reopened after reconnection. The choice can be made based on user preference and application scenario; Strategy 1 is used by default.

[0114] After successful connection reconnection: The remote control connection is restored (on the same remote computer). A new current remote session identifier is generated for the re-established connection (even on the same computer, a reconnection is a new connection session, requiring a new identifier to distinguish residual events from the old connection). The new identifier is generated in the same way as the initial connection (protocol-assigned identifier or locally generated). The new current remote session identifier is bound to the reconnected remote control connection and stored in the session management module (creating a new remote session information entry, including the new identifier, reconnection time, connection parameters, etc.). If strategy two is used and the input interface is retained, the local input lifecycle identifier of the current input interface is rebound to the new remote session identifier (updating the remote session identifier field in the lifecycle-session binding pair), so that new input events generated by the current input interface carry the new remote session identifier and can be injected into the reconnected remote session through the second layer of verification. If strategy one is used and the input interface has been closed, the user needs to reopen the input interface (when reopening, the new local identifier is automatically bound to the current new remote session identifier).

[0115] After a successful connection switch: The user switches from the first remote computer to the second remote computer (or a different user session on the same computer). The connection to the first computer is broken, and a new connection is established with the second computer. A new current remote session identifier is generated for the new connection and bound to storage. The current input interface is typically left closed (because the user's input context has changed since switching to a different remote computer, events generated by the old input interface should not be injected into the new computer), but can also be retained by the user if they choose to rebind the new remote session identifier (e.g., if the user wants to quickly switch between the two computers and keep the input interface open). After the switch, input events carrying the old remote session identifier (the session on the first computer) are discarded due to a second-level check mismatch and will not be injected into the second remote computer, completely avoiding the risk of inputting to the wrong computer.

[0116] After updating the current remote session identifier, all input events carrying the old remote session identifier are discarded during the three-condition validation due to the mismatch of the remote session identifier, thus invalidating the old input events. This is one of the core mechanisms of this application: it eliminates the need to actively track and cancel old input events transmitted in the asynchronous link (which is very difficult in complex asynchronous communication architectures, requiring maintenance of the transmission state of each event and sending cancellation commands, making implementation complex and unreliable). Only the current remote session identifier needs to be updated. When old events arrive at the input injection module for triple validation, they are automatically filtered and discarded because the remote session identifier they carry does not match the current identifier. This mechanism is simple to implement (only one state variable needs to be updated), reliable (all old events are guaranteed to be validated without omission), and free of race conditions (identifier update is an atomic operation; events arriving after the update are all validated according to the new identifier), completely solving the problem of "old remote connection input remnants being injected into the new session."

[0117] The current input interface can be closed synchronously, or the input interface can be retained but input can be disabled. When the remote session identifier is updated, the processing method of the input interface is determined according to the connection change type and user policy: Synchronously close the current input interface: When the connection is disconnected or switched to a different remote computer, the current input interface is closed (execute the release process of Example 5), because the input has lost its target or the context has changed, and retaining the interface is meaningless; after closing, the current local input lifecycle identifier is invalidated, and the residual events of the old interface are also discarded due to the mismatch of local identifiers (double insurance). Retain the input interface but disable input: When the connection is briefly disconnected and expected to reconnect quickly, the input interface is retained but the current input state is set to a non-inputable state (such as closing or a custom "waiting for reconnection" state), and input event injection is disabled. The user's input operations on the interface are temporarily stored or discarded; after successful reconnection, the inputable state is restored, and the user can continue to input. The method of retaining but disabling input is suitable for scenarios with unstable networks and frequent brief disconnections, avoiding users repeatedly opening the input interface and improving the experience; however, a timeout (such as 30 seconds) needs to be set. If the connection is not reconnected within the timeout, the interface is closed and the identifier is updated to invalid to avoid infinite waiting. The two methods can be flexibly selected according to the application scenario and user preferences, or the default behavior can be configured by the user in the settings.

[0118] In some embodiments, a complete remote desktop use case is used to provide an end-to-end comprehensive description of all technical content.

[0119] This embodiment uses a typical use case: a user writes a document on an office computer via remote desktop control from a dual-screen tablet, experiencing operations such as quickly turning the keyboard on and off, disconnecting and reconnecting, and switching to another remote computer: a complete end-to-end comprehensive explanation of all technical content.

[0120] Scenario 1: Establishing a remote connection and opening the input interface: The user opens the remote desktop client on the dual-screen tablet and connects to the office computer (remote computer A). After the connection is successfully established, a current remote session identifier of RA-001 is generated and bound to connection A, stored in the session management module. The remote desktop screen is displayed full-screen on the first display (left screen). The user needs to enter text in the word processing software on the office computer and clicks the keyboard icon button on the remote desktop client interface to trigger the input interface to open. The input management module responds to the operation, generating a current local input lifecycle identifier of L-005 (a monotonically increasing sequence number, this is the 5th time it has been opened), binding L-005 with the current remote session identifier RA-001 to form a lifecycle-session binding pair, setting the current input status to "ongoing", and storing it in the session isolation verification module. At the same time, an input interface instance (soft keyboard window) is created on the second display (right screen), and the input interface instance holds the identifier L-005.

[0121] Scenario 2: State event-driven state transition: After the input interface window is created, focus is acquired, and the input method is displayed, the input interface instance generates a "Display Complete" status event, carrying the local identifier L-005. The session isolation verification module receives the status event, extracts the identifier L-005, compares it with the current local identifier L-005, checks that the current state transitioning from "On" to "Inputable" is valid, updates the current input state to "Inputable," notifies the input injection module to allow injection, and displays a "Input Ready" message. Subsequently, text events entered by the user on the soft keyboard, carrying the local identifier L-005 and the remote session identifier RA-001, pass triple verification (L-005 matches, RA-001 matches, inputable state is verified) and are injected into the remote session RA-001, i.e., office computer A, where the text appears in the word processing software.

[0122] Scenario 3: Quickly toggle the keyboard: Old state events are discarded because they are late. After a user enters text, they click the close button to close the keyboard. The expected identifier for the close command is L-005, which matches the current identifier L-005 in the session isolation verification module. Therefore, the status is set to "closing," the input interface instance is released, and the status is set to "closed" upon completion, while the current local identifier L-005 is set to "invalid." However, the user immediately (less than 1 second later) clicks the keyboard button to reopen it. At this time, the "hide complete" status event of the old input interface has not yet arrived due to asynchronous delay. The new reopening operation generates a new current local identifier L-006, binds it to the current remote session identifier RA-001, sets the status to "opening," and creates a new input interface instance holding L-006. Shortly after, the "hide complete" status event of the old interface arrives, carrying the old identifier L-005. The session isolation verification module extracts the identifier L-005 and compares it with the current identifier L-006; they do not match, which is considered a late event and discarded. The current status is not updated: the "opening" status of the new interface L-006 is unaffected by the old event. Subsequently, the "Display Complete" event of the new interface arrives, carrying L-006. The match is confirmed, and the state transition is valid, updating to an input-ready state, allowing the user to continue typing. The entire process is seamless for the user, with no keyboard state errors or sudden disappearances.

[0123] Scenario 4: The old close command is accidentally closed and the new interface is ignored: Another scenario similar to Scenario 3: The user closes the old interface (L-006) and immediately opens the new interface (L-007). The close command for the old interface arrives only after the new interface has opened due to asynchronous delay. The close command carries the expected identifier L-006. The session isolation verification module compares the expected identifier L-006 with the current identifier L-007; if they do not match, the close command is ignored. Therefore, the new interface L-007 will not be incorrectly closed by the old close command. The user sees the new keyboard displayed normally and does not suddenly disappear requiring a reopening. Without expected identifier verification, the old close command would close the newly opened interface upon arrival, resulting in a very poor user experience.

[0124] Scenario 5: Disconnection and Reconnection: Old Input Events Become Invalid During user input, the network on office computer A suddenly interrupts (e.g., Wi-Fi connection drops), and the remote control connection to A is lost. The session isolation verification module detects the connection loss and triggers the remote session identifier update process: updating the current remote session identifier from RA-001 to an invalid value (or keeping it but marking the status as disconnected), and simultaneously closing the current input interface (status set to Closing → Closed, local identifier L-007 set to invalid). Events from the last few characters entered by the user before the disconnection may still be propagating in the asynchronous link. These events carry the remote session identifier RA-001. When they reach the input injection module, the current remote session identifier is already invalid (or a new value after reconnection), the second verification fails, and the events are discarded: residual input from the old connection is not injected. After 30 seconds, the network is restored, and the remote desktop client automatically reconnects to office computer A. After a successful reconnection, a new current remote session identifier RA-002 is generated (same computer but new connection session), and bound to the reconnected connection. When the user presses the keyboard button again to open the input interface, a local identifier L-008 is generated and bound to the current remote session identifier RA-002. Subsequent user input events carry RA-002, and upon successful verification, are injected into the reconnected remote session. Throughout the entire disconnection and reconnection process, all residual events from the old connection RA-001 are discarded due to the mismatch in remote session identifiers and will not interfere with the new reconnected session RA-002.

[0125] Scenario 6: Switching to a remote computer: Old events are not injected into the new computer. After completing work on office computer A, a user needs to switch to another computer B (remote computer B) at home to handle other tasks. The user switches connections in the remote desktop client, disconnecting from computer A and establishing a new connection to computer B. The session isolation verification module detects the connection switch and triggers an update process: generating a new current remote session identifier RB-001 and binding it to connection B. The last few characters the user typed on computer A before the switch (carrying RA-002) may arrive after the switch. Since the current remote session identifier is already RB-001, the second layer of verification fails, and the event is discarded. Input from computer A (which may contain commands or sensitive information specific to computer A) will not be injected into computer B, completely avoiding the risk of inputting to the wrong computer. The user restarts keyboard input on computer B, the event carrying RB-001, and verification passes before being injected into computer B.

[0126] Scenario 8: Input isolation for multiple remote sessions in parallel: A user simultaneously connects to two remote computers (PC A session RA-003 and PC B session RB-002) and switches between the two remote desktop windows. When the user starts keyboard input in PC A's window, a local identifier L-009 is generated and bound to RA-003. The input event carries L-009 and RA-003, and the verification passes before being injected into PC A. When the user switches to PC B's window and starts keyboard input, a local identifier L-010 is generated and bound to RB-002. At this point, the current local identifier is L-010, and the current remote session identifier is RB-002. If the old input interface L-009 on PC A still generates residual events in the background (e.g., the last character entered before the user switched arrives late), the event carries L-009 and RA-003. The first verification (L-009 vs. the current L-010) does not match, and the event is discarded: input from PC A will not be injected into PC B when the user operates PC B. In multi-session parallel scenarios, dual verification using local and remote session identifiers achieves complete isolation of input events between different remote sessions.

[0127] Through the complete end-to-end description of the above eight scenarios, all the technical contents of the remote desktop input event session isolation method of this application are fully and practically described: remote connection establishment and remote session identifier generation, input interface opening and local input lifecycle identifier generation, dual identifier binding and state initialization, asynchronous event reception and classification, state event identifier verification and state transition legality verification, close command expectation identifier verification and input interface release, triple verification of input events (consistency of local identifier, consistency of remote session identifier, and inputtable state) and remote session injection, input event discarding and logging, remote connection status monitoring and remote session identifier updating, and old input event automatic expiration mechanism. These cover typical and complex operation scenarios such as quick keyboard switching, disconnection and reconnection, switching remote computers, and multiple sessions in parallel, ensuring that input content is always accurately injected into the correct remote session.

[0128] In some embodiments, an adaptive input quality monitoring and optimization method based on input event statistics is provided. By analyzing statistical data such as the reception, successful verification, discarding, successful injection, and failed injection of input events in real time, abnormal input quality is identified and the session isolation parameters and input interface behavior are adaptively adjusted to continuously optimize the reliability and user experience of remote desktop input.

[0129] Specifically, the session isolation verification module and the input injection module record the event processing results statistics when processing each input event, including: total number of events received (total number of input events received from the asynchronous link per unit time), number of verifications passed (number of events that passed all triple verifications), number of discards and the distribution of discard reasons (number of discards due to local identifier mismatch, remote session identifier mismatch, and invalid status), number of successful injections, number of failed injections, average input latency (average time from event occurrence to successful injection), and user backspace frequency (number of backspace key events per unit time, indirectly reflecting the input error rate). The statistical data is calculated by sliding across time windows (e.g., the most recent 1 minute, the most recent 5 minutes, and the most recent 1 hour) and stored in the input quality monitoring module.

[0130] The input quality monitoring module identifies input quality anomalies based on statistical data, including: abnormal drop rate (the drop rate for a certain type of drop exceeds a threshold, such as a drop rate exceeding 10% for remote session identifier mismatch, indicating frequent switching or disconnection of remote connections leading to a large number of residual events, which can optimize the event queue's proactive cleanup logic during connection switching); abnormal injection failure rate (the injection failure rate exceeds a threshold, indicating unstable remote connection or abnormal response from the remote computer, which can trigger connection quality detection and reconnection suggestions); abnormal input latency (the average input latency exceeds a threshold, such as 500ms, indicating asynchronous link congestion or slow input interface processing, which can optimize event processing priority or reduce unnecessary intermediate processing steps); and abnormal backspace frequency (a sudden increase in backspace frequency may indicate a high rate of accidental touches on the input interface or poor sorting of input method candidate words, which can trigger input interface layout optimization or candidate word reordering).

[0131] Upon detecting an anomalies, the input quality monitoring module adaptively adjusts session isolation parameters and input interface behavior, including: adjusting state transition timeout thresholds (e.g., the display timeout for the "on" state is dynamically adjusted based on device performance and historical display time; shorter timeouts are used for high-performance devices to reduce waiting time, while longer timeouts are used for low-performance devices to avoid false display failures); adjusting event queue cleanup strategies (actively clearing the queue of pending events corresponding to old remote session identifiers during connection switching to reduce the overhead of discarding residual events); adjusting input interface retry strategies (determining the number and interval of retries based on the cause of injection failure; increasing retries for network-related failures and reducing retries for protocol-related failures to avoid unnecessary overhead); and adjusting input interface layout parameters (dynamically adjusting the size and spacing of soft keyboard keys based on accidental touch hotspot statistics to reduce accidental touch rates). All adaptive adjustments are performed locally on the device, based on local statistical data, without uploading user input content to protect user privacy.

[0132] By using input event statistics and adaptive optimization, the remote desktop input session isolation system is equipped with self-monitoring and self-optimization capabilities. It can dynamically adjust parameters based on actual operating data to continuously improve input reliability and user experience, with particularly significant effects in scenarios with unstable networks, large differences in device performance, and diverse user operating habits.

[0133] In some embodiments, a critical input assurance method based on input event priority is provided. By setting priorities for different types of input events, high-priority critical input events (such as control commands, password input, and emergency operations) are processed first during session isolation verification and injection. This ensures that critical inputs can still be reliably injected into remote sessions under abnormal conditions such as network fluctuations and event congestion, and avoids the loss or delay of critical operations.

[0134] Specifically, when an input event occurs, the input interface instance assigns a priority based on the event type and content. Priorities are categorized as follows: High priority (key combinations such as control keys plus C / V / Z / A, control keys plus Alt plus Delete, Enter to execute commands, function keys such as F5 to refresh, Esc to cancel, etc.; confirmation text events in password input scenarios (the content entered by the user in the password box); user-marked urgent inputs); Medium priority (ordinary control keys such as backspace, tabs, and arrow keys; short text input such as words and phrases); Low priority (long text input such as paragraphs, long text recognition results from voice input; ordinary text in non-critical scenarios). The priority identifier is appended to the input event data structure and transmitted along with the event.

[0135] The session isolation verification module uses a priority queue instead of a regular first-in-first-out queue for its event queue, with high-priority events placed at the front of the queue for priority processing. During triple verification, high-priority events have priority access to verification resources (e.g., when the verification module is busy, high-priority events are processed first, while low-priority events can be briefly delayed). When injecting remote sessions, high-priority events have priority access to the injection channel, and if injection fails, they retry more times (e.g., high-priority events retry 3 times, medium-priority events 2 times, and low-priority events 1 time) with shorter retry intervals, ensuring that critical inputs are injected successfully as much as possible.

[0136] For sensitive and high-priority events such as password input, additional security measures are implemented: password input events are transmitted via asynchronous links using end-to-end encryption (even if the remote desktop protocol itself is encrypted, the password event is encrypted with an additional layer) to prevent leakage in intermediate links; password input events are not recorded in the discard log or injection log (only the event type and processing result are recorded, not the password content), protecting sensitive user information; after the password is entered (the user presses Enter or switches input boxes), the cached password text in the input interface is immediately cleared to prevent the password from remaining in memory.

[0137] When the remote control connection quality is poor (high latency, high packet loss rate), the input quality monitoring module can trigger a "critical input protection mode." In this mode, the injection rate of low-priority events is temporarily reduced (e.g., long text inputs are injected in batches to avoid congestion), prioritizing high-priority critical inputs with limited network bandwidth and processing resources. Simultaneously, a message "Poor network, critical inputs prioritized" is displayed on the input interface to inform the user of the current status. Once the connection quality recovers, the protection mode automatically exits, and the normal injection rate resumes.

[0138] By prioritizing input events and implementing a critical input protection mechanism, the system ensures that critical user operations (command execution, password input, and emergency control) are not lost or delayed in abnormal situations such as network fluctuations and event congestion, thereby improving the availability and reliability of the remote desktop in unstable network environments. Additional security measures for password input protect sensitive user information. The critical input protection mode intelligently adjusts resource allocation when the network is poor, balancing user experience and system stability.

[0139] In some embodiments, an abnormal input detection and security protection method based on input behavior fingerprinting is provided. By analyzing the characteristics of user input behavior (input speed, rhythm, backspace mode, commonly used words, etc.), a normal user input behavior fingerprint is established. Abnormal input that does not match the normal behavior fingerprint (such as automatic injection of malicious programs, input by attackers after remote session hijacking, batch input by automated scripts) is detected in real time and security protection measures are triggered to prevent malicious input from harming remote computers.

[0140] Specifically, the input quality monitoring module collects user input behavior characteristic data during normal remote desktop input to establish a fingerprint of normal user input behavior. These behavioral fingerprint features include: input speed distribution (normal range and distribution of characters input per minute, differences between different time periods such as work hours and rest periods); input rhythm characteristics (distribution of key press intervals, patterns of continuous input and pauses, and pause patterns between phrases); backspace patterns (backspace frequency, backspace-to-input ratio, and timing patterns of backspace occurrences, such as more backspaces after inputting long words); common vocabulary and command preferences (frequently entered words, commands, and shortcut key combinations reflecting user work habits); and input time period patterns (time periods when users typically use remote desktop input, differences between weekdays and weekends). The behavioral fingerprint is based on historical user input data (collecting at least one week to one month of data to ensure accuracy), using statistical modeling or lightweight machine learning algorithms (such as Isolation Forest and Gaussian Mixture Models) to construct a normal behavior model, which is stored locally on the device (not uploaded to the cloud to protect user privacy).

[0141] When processing each input event, the session isolation verification module, in addition to performing triple verification, also inputs the event characteristics into the abnormal input detection module for comparison with the user's normal behavior fingerprint, calculating an anomaly score. If the anomaly score exceeds a threshold, it is determined to be abnormal input, triggering security protection measures. Typical characteristics of abnormal input include: input speed far exceeding the normal range (e.g., input speed exceeding three times the user's normal speed per minute, possibly indicating automated script batch pasting or injection); overly regular input rhythm (key intervals are almost perfectly consistent; human input usually has natural fluctuations, excessive regularity may indicate automated input); abnormally low backspace frequency (human input usually has a certain backspace rate, almost zero backspace may indicate automated input of correct content); input content severely inconsistent with the user's commonly used vocabulary and command preferences (e.g., a user who usually inputs office documents suddenly inputs a large number of system commands, script code, and deletion operations, possibly indicating remote session hijacking); and abnormal input time (a user who usually doesn't input in the early morning suddenly inputs a large amount of data in the early morning, possibly indicating unauthorized access).

[0142] Upon detecting abnormal input, tiered security measures are implemented based on the anomaly level: Low-level anomalies (slight deviation in a single feature, possibly due to a change in user state, such as faster input due to time constraints): Log is recorded and observation continues without blocking input, while detection sensitivity is increased; Medium-level anomalies (deviation in multiple features or significant deviation in a single feature, indicating high suspicion): A prompt appears on the input interface: "Abnormal input pattern detected. Please confirm if this is your operation." If the user confirms it is their own operation, injection continues, and this behavior is included in the normal fingerprint model update (adapting to changes in user behavior); if the user does not confirm or confirms it is not their own operation, subsequent input events are paused until the user confirms it is their own operation. User authentication (such as entering answers to preset security questions, biometric verification) passes; High-level anomalies (severe deviation from normal behavior, such as entering dangerous commands like rm-rf, formatting commands, or numerous deletion operations, with an input speed and rhythm that is clearly non-human): Immediately block the injection of this input event, do not send it to the remote computer, and simultaneously display a strong security warning on the input interface and remote desktop screen: "High-risk abnormal input detected, automatically blocked, please confirm remote session security," and record a detailed security log (abnormal event summary, abnormal score, trigger time), and suggest that the user check the security of the remote computer (such as whether it has been hijacked or whether there are malicious programs).

[0143] The abnormal input detection model supports online incremental updates: Abnormal input confirmed by the user as their own is included in the normal behavior model, and the model gradually adapts to changes in user behavior (e.g., as users learn new skills and input more commands, the updated model no longer issues false alarms); abnormal input confirmed by the user as not being their own or that has been blocked is included in the abnormal sample library, improving the model's accuracy in identifying abnormal patterns. Model updates are performed on the local device; user input content and behavioral data are not uploaded to the cloud, protecting user privacy and data security.

[0144] By using user input behavior fingerprinting and abnormal input detection, an intelligent security layer is added to remote desktop input. It can identify security threats such as automatic injection of malicious programs, hijacking of remote sessions, and automated script attacks. The tiered protection measures ensure security while reducing interference with normal users (low-level does not block, medium-level requires confirmation, and high-level only blocks). The model is updated online to adapt to changes in user behavior and reduce false alarms. All data is processed locally to protect privacy, significantly improving the security of remote desktop input.

[0145] Please see Figure 4 As shown, Figure 4 This is a schematic diagram of the structure of a remote desktop input event session isolation system 200 provided in an embodiment of this application. The remote desktop input event session isolation system 200 is used to execute the steps of the remote desktop input event session isolation method shown in the above embodiments. The remote desktop input event session isolation system 200 can be a single server or a server cluster, or it can be a terminal, such as a handheld terminal, laptop computer, wearable device, or robot.

[0146] like Figure 4 As shown, the session isolation system 200 for remote desktop input events includes: The connection establishment unit 201 is used to establish a remote control connection, obtain the current remote session identifier, respond to the input interface opening operation, generate the current local input lifecycle identifier, bind the current local input lifecycle identifier with the current remote session identifier, and set the current input status to be on. The event receiving unit 202 is used to receive asynchronous events carrying local input lifecycle identifiers. For status events, the current input state is updated only when the local input lifecycle identifier carried by the status event is consistent with the current local input lifecycle identifier and the current input state allows state transition. For close commands, the current input state is set to closing and releasing the input interface instance only when the expected local input lifecycle identifier carried by the close command is consistent with the current local input lifecycle identifier. The event invalidation unit 203 is used to, for an input event carrying a local input lifecycle identifier and a remote session identifier, simultaneously determine whether the local input lifecycle identifier carried by the input event is consistent with the current local input lifecycle identifier, whether the remote session identifier carried by the input event is consistent with the current remote session identifier, and whether the current input state is an input-available state. If all conditions are met, the input event is injected into the current remote session; if any condition is not met, the input event is discarded. When a remote control connection is detected to be disconnected, reconnected, or switched, the current remote session identifier is updated, invalidating the input event carrying the old remote session identifier.

[0147] In some embodiments, establishing a remote control connection and obtaining the current remote session identifier includes: initiating a remote control connection request and establishing a remote control connection with a remote computer; after the remote control connection is successfully established, generating a unique current remote session identifier for this remote control connection; and binding and storing the current remote session identifier with the remote control connection.

[0148] In some embodiments, the step of responding to the input interface opening operation and generating a current local input lifecycle identifier includes: responding to the input interface opening operation when the user triggers the input interface opening operation; generating a current local input lifecycle identifier that is not repeated within a predetermined range, wherein the current local input lifecycle identifier adopts a monotonically increasing sequence number or a globally unique identifier; and associating the current local input lifecycle identifier with the current input interface opening operation.

[0149] In some embodiments, binding the current local input lifecycle identifier with the current remote session identifier and setting the current input state to "ongoing" includes: establishing a binding relationship between the current local input lifecycle identifier and the current remote session identifier to form a lifecycle-session binding pair; setting the current input state to "ongoing", and disallowing input events from being injected in the "ongoing" state; and storing the lifecycle-session binding pair and the current input state in the session isolation verification module.

[0150] In some embodiments, receiving asynchronous events carrying local input lifecycle identifiers, for status events, updating the current input state only when the local input lifecycle identifier carried by the status event matches the current local input lifecycle identifier and the current input state allows for state transition, includes: receiving asynchronous events, including status events, close commands, and input events, each asynchronous event carrying a local input lifecycle identifier; for status events, extracting the local input lifecycle identifier carried by the status event and comparing the local input lifecycle identifier carried by the status event with the current local input lifecycle identifier; if the local input lifecycle identifier carried by the status event matches the current local input lifecycle identifier and the current input state allows for target state transition, updating the current input state according to the status event; status events with mismatched identifiers are identified as late events and discarded.

[0151] In some embodiments, setting the current input state to "closing" and releasing the input interface instance only when the expected local input lifecycle identifier carried by the close command matches the current local input lifecycle identifier includes: for the close command, extracting the expected local input lifecycle identifier carried by the close command, comparing the expected local input lifecycle identifier carried by the close command with the current local input lifecycle identifier; when the expected local input lifecycle identifier carried by the close command matches the current local input lifecycle identifier, setting the current input state to "closing" and releasing the current input interface instance; when the expected local input lifecycle identifier carried by the close command does not match the current local input lifecycle identifier, ignoring the close command.

[0152] In some embodiments, the step of injecting the input event into the current remote session when all three conditions are met—that the local input lifecycle identifier carried by the input event matches the current local input lifecycle identifier, the remote session identifier carried by the input event matches the current remote session identifier, and the current input state is an input-enabled state—includes the following: for an input event, extracting the local input lifecycle identifier and the remote session identifier carried by the input event; simultaneously determining that the local input lifecycle identifier carried by the input event matches the current local input lifecycle identifier, the remote session identifier carried by the input event matches the current remote session identifier, and the current input state is an input-enabled state; when all three conditions are met, injecting the input event into the current remote session, and having the current remote session send the input event to the remote computer.

[0153] In some embodiments, discarding an input event when any of the conditions is not met includes: if the local input lifecycle identifier carried by the input event is inconsistent with the current local input lifecycle identifier, the input event is determined to originate from an old input interface instance, and the input event is discarded; if the remote session identifier carried by the input event is inconsistent with the current remote session identifier, the input event is determined to belong to an old remote session, and the input event is discarded; if the current input state is not an input-available state, the arrival time of the input event is determined to be invalid, and the input event is discarded; the event type, the current local input lifecycle identifier, the current remote session identifier, and the reason for discarding the input event are recorded.

[0154] In some embodiments, updating the current remote session identifier when a remote control connection is detected to be disconnected, reconnected, or switched, thereby invalidating input events carrying the old remote session identifier, includes: real-time monitoring of the remote control connection status; triggering a remote session identifier update process when a remote control connection is detected to be disconnected, reconnected, or switched; generating a new current remote session identifier after a successful reconnection or switch, and binding the new current remote session identifier to the reconnected or switched remote control connection; after updating the current remote session identifier, all input events carrying the old remote session identifier are discarded during the three-condition verification due to the mismatch of the remote session identifier, thus invalidating the old input events; the current input interface can be closed simultaneously, or the input interface can be retained but input can be disabled.

[0155] It should be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the remote desktop input event session isolation system and each module described above can be referred to the corresponding content in the various embodiments of the remote desktop input event session isolation method, and will not be repeated here.

[0156] The aforementioned session isolation method for remote desktop input events can be implemented as a computer program, which can, for example... Figure 4 It runs on the system shown.

[0157] Please see Figure 5 , Figure 5 This is a schematic block diagram of the structure of a terminal device provided in an embodiment of this application. The terminal device includes a processor, a memory, and a network interface connected via a device bus, wherein the memory may include a storage medium and internal memory.

[0158] The storage medium may store operating devices and computer programs. The computer program includes program instructions that, when executed, cause the processor to perform any session isolation method for remote desktop input events.

[0159] The processor provides computing and control capabilities to support the operation of the entire terminal device.

[0160] Internal memory provides an environment for the execution of computer programs in non-volatile storage media, which, when executed by a processor, enable the processor to perform any session isolation method for remote desktop input events.

[0161] This network interface is used for network communication, such as sending assigned tasks. Those skilled in the art will understand that... Figure 5The structure shown is merely a block diagram of a portion of the structure related to the solution of this application and does not constitute a limitation on the terminal to which the solution of this application is applied. Specific terminal devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0162] It should be understood that the processor can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among these, a general-purpose processor can be a microprocessor or any conventional processor.

[0163] In one embodiment, the processor is configured to run a computer program stored in memory to perform the following steps: Establish a remote control connection and obtain the current remote session identifier; respond to the input interface opening operation, generate the current local input lifecycle identifier, bind the current local input lifecycle identifier with the current remote session identifier, and set the current input status to "on". Receive asynchronous events carrying local input lifecycle identifiers. For status events, update the current input state only if the local input lifecycle identifier carried by the status event is consistent with the current local input lifecycle identifier and the current input state allows state transition. For close commands, set the current input state to "closing and releasing the input interface instance" only if the expected local input lifecycle identifier carried by the close command is consistent with the current local input lifecycle identifier. For input events carrying both a local input lifecycle identifier and a remote session identifier, the system simultaneously determines whether the local input lifecycle identifier carried by the input event matches the current local input lifecycle identifier, whether the remote session identifier carried by the input event matches the current remote session identifier, and whether the current input state is an input-available state. If all conditions are met, the input event is injected into the current remote session; if any condition is not met, the input event is discarded. When a remote control connection is detected to be disconnected, reconnected, or switched, the system updates the current remote session identifier, invalidating input events carrying the old remote session identifier.

[0164] In some embodiments, establishing a remote control connection and obtaining the current remote session identifier includes: initiating a remote control connection request and establishing a remote control connection with a remote computer; after the remote control connection is successfully established, generating a unique current remote session identifier for this remote control connection; and binding and storing the current remote session identifier with the remote control connection.

[0165] In some embodiments, the step of responding to the input interface opening operation and generating a current local input lifecycle identifier includes: responding to the input interface opening operation when the user triggers the input interface opening operation; generating a current local input lifecycle identifier that is not repeated within a predetermined range, wherein the current local input lifecycle identifier adopts a monotonically increasing sequence number or a globally unique identifier; and associating the current local input lifecycle identifier with the current input interface opening operation.

[0166] In some embodiments, binding the current local input lifecycle identifier with the current remote session identifier and setting the current input state to "ongoing" includes: establishing a binding relationship between the current local input lifecycle identifier and the current remote session identifier to form a lifecycle-session binding pair; setting the current input state to "ongoing", and disallowing input events from being injected in the "ongoing" state; and storing the lifecycle-session binding pair and the current input state in the session isolation verification module.

[0167] In some embodiments, receiving asynchronous events carrying local input lifecycle identifiers, for status events, updating the current input state only when the local input lifecycle identifier carried by the status event matches the current local input lifecycle identifier and the current input state allows for state transition, includes: receiving asynchronous events, including status events, close commands, and input events, each asynchronous event carrying a local input lifecycle identifier; for status events, extracting the local input lifecycle identifier carried by the status event and comparing the local input lifecycle identifier carried by the status event with the current local input lifecycle identifier; if the local input lifecycle identifier carried by the status event matches the current local input lifecycle identifier and the current input state allows for target state transition, updating the current input state according to the status event; status events with mismatched identifiers are identified as late events and discarded.

[0168] In some embodiments, setting the current input state to "closing" and releasing the input interface instance only when the expected local input lifecycle identifier carried by the close command matches the current local input lifecycle identifier includes: for the close command, extracting the expected local input lifecycle identifier carried by the close command, comparing the expected local input lifecycle identifier carried by the close command with the current local input lifecycle identifier; when the expected local input lifecycle identifier carried by the close command matches the current local input lifecycle identifier, setting the current input state to "closing" and releasing the current input interface instance; when the expected local input lifecycle identifier carried by the close command does not match the current local input lifecycle identifier, ignoring the close command.

[0169] In some embodiments, the step of injecting the input event into the current remote session when all three conditions are met—that the local input lifecycle identifier carried by the input event matches the current local input lifecycle identifier, the remote session identifier carried by the input event matches the current remote session identifier, and the current input state is an input-enabled state—includes the following: for an input event, extracting the local input lifecycle identifier and the remote session identifier carried by the input event; simultaneously determining that the local input lifecycle identifier carried by the input event matches the current local input lifecycle identifier, the remote session identifier carried by the input event matches the current remote session identifier, and the current input state is an input-enabled state; when all three conditions are met, injecting the input event into the current remote session, and having the current remote session send the input event to the remote computer.

[0170] In some embodiments, discarding an input event when any of the conditions is not met includes: if the local input lifecycle identifier carried by the input event is inconsistent with the current local input lifecycle identifier, the input event is determined to originate from an old input interface instance, and the input event is discarded; if the remote session identifier carried by the input event is inconsistent with the current remote session identifier, the input event is determined to belong to an old remote session, and the input event is discarded; if the current input state is not an input-available state, the arrival time of the input event is determined to be invalid, and the input event is discarded; the event type, the current local input lifecycle identifier, the current remote session identifier, and the reason for discarding the input event are recorded.

[0171] In some embodiments, updating the current remote session identifier when a remote control connection is detected to be disconnected, reconnected, or switched, thereby invalidating input events carrying the old remote session identifier, includes: real-time monitoring of the remote control connection status; triggering a remote session identifier update process when a remote control connection is detected to be disconnected, reconnected, or switched; generating a new current remote session identifier after a successful reconnection or switch, and binding the new current remote session identifier to the reconnected or switched remote control connection; after updating the current remote session identifier, all input events carrying the old remote session identifier are discarded during the three-condition verification due to the mismatch of the remote session identifier, thus invalidating the old input events; the current input interface can be closed simultaneously, or the input interface can be retained but input can be disabled.

[0172] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to implement the steps of the session isolation method for remote desktop input events as provided in any embodiment of this application.

[0173] The computer-readable storage medium can be an internal storage unit of the terminal device described in the foregoing embodiments, such as the hard disk or memory of the terminal device. Alternatively, the computer-readable storage medium can be an external storage device of the terminal device, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc., provided on the terminal device.

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

Claims

1. A session isolation method for remote desktop input events, characterized in that, include: Establish a remote control connection and obtain the current remote session identifier; respond to the input interface opening operation, generate the current local input lifecycle identifier, bind the current local input lifecycle identifier with the current remote session identifier, and set the current input status to "on". Receive asynchronous events carrying local input lifecycle identifiers. For status events, update the current input state only if the local input lifecycle identifier carried by the status event is consistent with the current local input lifecycle identifier and the current input state allows state transition. For close commands, set the current input state to "closing and releasing the input interface instance" only if the expected local input lifecycle identifier carried by the close command is consistent with the current local input lifecycle identifier. For an input event carrying a local input lifecycle identifier and a remote session identifier, the system simultaneously determines whether the local input lifecycle identifier carried by the input event matches the current local input lifecycle identifier, whether the remote session identifier carried by the input event matches the current remote session identifier, and whether the current input state is an input-available state. If all conditions are met, the input event is injected into the current remote session; if any condition is not met, the input event is discarded. When a remote control connection is detected to be disconnected, reconnected, or switched, the current remote session identifier is updated, invalidating input events that carry the old remote session identifier.

2. The method according to claim 1, characterized in that, The establishment of a remote control connection and acquisition of the current remote session identifier include: Initiate a remote control connection request to establish a remote control connection with the remote computer; After a remote control connection is successfully established, a unique current remote session identifier is generated for this remote control connection. The current remote session identifier is bound and stored with the remote control connection.

3. The method according to claim 1, characterized in that, The response input interface opening operation generates a current local input lifecycle identifier, including: When a user triggers an action to open the input interface, the system will respond to the action to open the input interface. Generate a unique current local input lifecycle identifier within a predetermined range. The current local input lifecycle identifier uses a monotonically increasing sequence number or a globally unique identifier. Associate the current local input lifecycle identifier with the current input interface opening operation.

4. The method according to claim 3, characterized in that, The step of binding the current local input lifecycle identifier with the current remote session identifier and setting the current input status to "on" includes: Establish a binding relationship between the current local input lifecycle identifier and the current remote session identifier, forming a lifecycle-session binding pair; Set the current input state to "On", and do not allow input events to be injected while the input state is on. The lifecycle-session binding pair and the current input state are stored in the session isolation verification module.

5. The method according to claim 1, characterized in that, The receipt of asynchronous events carrying local input lifecycle identifiers, for status events, updates the current input state only if the local input lifecycle identifier carried by the status event matches the current local input lifecycle identifier and the current input state allows state transitions, including: Receive asynchronous events, including status events, close commands, and input events. Each asynchronous event carries a local input lifecycle identifier. For status events, extract the local input lifecycle identifier carried by the status event and compare it with the current local input lifecycle identifier. If the local input lifecycle identifier carried by the status event is consistent with the current local input lifecycle identifier, and the current input state allows the target state to transition, the current input state is updated according to the status event; status events with mismatched identifiers are identified as late events and discarded.

6. The method according to claim 5, characterized in that, For the close command, the current input state is set to "closing and releasing the input interface instance" only if the expected local input lifecycle identifier carried by the close command matches the current local input lifecycle identifier, including: For the close command, extract the expected local input lifecycle identifier carried by the close command, and compare the expected local input lifecycle identifier carried by the close command with the current local input lifecycle identifier; When the expected local input lifecycle identifier carried by the close command matches the current local input lifecycle identifier, the current input state is set to closing and the current input interface instance is released. If the expected local input lifecycle identifier carried by the close command is inconsistent with the current local input lifecycle identifier, the close command is ignored.

7. The method according to claim 1, characterized in that, For an input event carrying a local input lifecycle identifier and a remote session identifier, if the local input lifecycle identifier carried by the input event matches the current local input lifecycle identifier, the remote session identifier carried by the input event matches the current remote session identifier, and the current input state is an input-available state, the input event is injected into the current remote session, including: For input events, extract the local input lifecycle identifier and remote session identifier carried by the input event; At the same time, it is determined that the local input lifecycle identifier carried by the input event is consistent with the current local input lifecycle identifier, the remote session identifier carried by the input event is consistent with the current remote session identifier, and the current input state is an input-available state; When all three conditions are met, the input event is injected into the current remote session, and the current remote session sends the input event to the remote computer.

8. The method according to claim 7, characterized in that, The input event is discarded when any of the conditions are not met, including: If the local input lifecycle identifier carried by the input event is inconsistent with the current local input lifecycle identifier, the input event is determined to come from an old input interface instance and the input event is discarded. If the remote session identifier carried by the input event is inconsistent with the current remote session identifier, the input event is considered to belong to an old remote session and the input event is discarded. If the current input state is not an input-available state, the timing of the input event is deemed invalid, and the input event is discarded; the event type, current local input lifecycle identifier, current remote session identifier, and reason for discarding the input event are recorded.

9. The method according to claim 8, characterized in that, When a remote control connection is detected to be disconnected, reconnected, or switched, the current remote session identifier is updated to invalidate input events carrying the old remote session identifier, including: Real-time monitoring of remote control connection status; when a remote control connection is detected to be disconnected, reconnected, or switched, a remote session identifier update process is triggered. After a successful reconnection or switch of the remote control connection, a new current remote session identifier is generated and bound to the reconnected or switched remote control connection. After updating the current remote session identifier, all input events carrying the old remote session identifier will be discarded during the three-condition validation due to the mismatch of the remote session identifier, thus invalidating the old input events; the current input interface can be closed synchronously, or the input interface can be kept open but input can be disabled.

10. A session isolation system for remote desktop input events, used to implement the method as described in any one of claims 1-9, characterized in that, include: The connection establishment unit is used to establish a remote control connection and obtain the current remote session identifier; respond to the input interface opening operation, generate the current local input lifecycle identifier, bind the current local input lifecycle identifier with the current remote session identifier, and set the current input status to "opening"; The event receiving unit is used to receive asynchronous events carrying local input lifecycle identifiers. For status events, the current input state is updated only if the local input lifecycle identifier carried by the status event is consistent with the current local input lifecycle identifier and the current input state allows state transition. For close commands, the current input state is set to "closing and releasing the input interface instance" only if the expected local input lifecycle identifier carried by the close command is consistent with the current local input lifecycle identifier. The event invalidation unit is used to determine whether the local input lifecycle identifier carried by the input event is consistent with the current local input lifecycle identifier, whether the remote session identifier carried by the input event is consistent with the current remote session identifier, and whether the current input state is an input-available state. If all conditions are met, the input event is injected into the current remote session. If any condition is not met, the input event is discarded. When a remote control connection is detected to be disconnected, reconnected, or switched, the current remote session identifier is updated, invalidating input events that carry the old remote session identifier.

Images