Multi-device cooperative control method and device, computer device and storage medium

Abstract

The invention relates to the technical field of equipment collaboration, and discloses a multi-equipment collaboration control method and device, computer equipment and a storage medium, and the method comprises the steps: building a session channel with collaboration equipment according to the authentication information of main control equipment; acquiring operation state parameters of the collaborative devices based on the session channels, and generating a permission allocation matrix according to the operation state parameters of the collaborative devices; and processing task requirements of the main control equipment by utilizing the permission allocation matrix, generating a differential instruction set, and executing synchronous control on the collaborative equipment according to the differential instruction set. According to the invention, the problems of authority conflict, inflexible task allocation and incapability of fast and automatic switching after the main control equipment fails when multiple devices cooperatively control the cloud mobile phone instance in the prior art are solved.

Description

Technical Field

[0001] The present invention relates to the technical field of device collaboration, and specifically to a multi-device collaborative control method, device, computer device, and storage medium. Background Art

[0002] In the technical fields of cloud computing and distributed collaborative control, the application scenarios of multi-device collaborative control of cloud mobile phone instances are becoming increasingly widespread, such as enterprise team collaboration, home multi-user sharing, cross-device task distribution, etc. By operating the same cloud mobile phone instance through multi-device collaboration, the resource utilization efficiency and user operation convenience can be improved, but this technology still faces many challenges in aspects such as permission management, task allocation, and device switching.

[0003] In the prior art, there are significant deficiencies in multi-device collaborative control of cloud mobile phone instances. For example, the permission management mechanism lacks the ability of dynamic adjustment, is difficult to adapt to the performance differences of different devices and the changes of user roles, and is prone to permission conflicts; the task allocation mode is fixed and cannot perform intelligent scheduling according to the real-time operating status of devices (such as CPU performance, network latency, etc.), affecting the task execution efficiency; when the master device fails, there is no automated control right migration mechanism, and manual intervention is required to complete device switching, resulting in operation interruption and a long recovery time. In addition, traditional solutions also have limitations in aspects such as ensuring cross-device operation consistency and security protection, and are difficult to meet the collaborative control requirements in complex scenarios. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a multi-device collaborative control method, device, computer device, and storage medium to solve the problems of permission conflicts, inflexible task allocation, and inability to quickly and automatically switch after the master device fails in multi-device collaborative control of cloud mobile phone instances in the prior art.

[0005] In a first aspect, an embodiment of the present invention provides a multi-device collaborative control method, and the method includes:

[0006] Establish a session channel with a collaborative device according to the authentication information of the master device;

[0007] Obtain the operating state parameters of the collaborative device based on the session channel, and generate a permission allocation matrix according to the operating state parameters of each collaborative device;

[0008] Process the task requirements of the master device by using the permission allocation matrix, generate a set of differentiated instructions, and perform synchronous control on the collaborative device according to the set of differentiated instructions.

[0009] Further, the establishing a session channel with a collaborative device according to the authentication information of the master device includes:

[0010] Verify the identity information of the master device through the authentication information;

[0011] If the verification is passed, generate a session identifier associated with the master device, and establish a two-way encrypted session channel between the master device and each collaborative device based on the session identifier.

[0012] Further, the generating a permission allocation matrix according to the operating state parameters of each of the collaborative devices includes:

[0013] Extract the hardware performance index, network connection index, and historical task execution index from each of the operating state parameters;

[0014] Input the hardware performance index, the network connection index, and the historical task execution index into a device capability evaluation model to obtain the performance scores of each of the collaborative devices;

[0015] Allocate corresponding function permissions to each of the collaborative devices according to the performance scores to obtain a permission allocation matrix.

[0016] Further, the processing the task requirements of the master device by using the permission allocation matrix to obtain a set of differential instructions includes:

[0017] Parse the task requirements of the master device based on the permission allocation matrix to obtain the device permission range;

[0018] Extract the operation fields in the task requirements according to the device permission range;

[0019] Generate a set of differential instructions that match the function permissions of each of the collaborative devices based on the operation fields.

[0020] Further, the performing synchronous control on the collaborative devices according to the set of differential instructions includes:

[0021] Send the set of differential instructions to the corresponding collaborative device through the session channel;

[0022] Receive the instruction execution progress returned by each of the collaborative devices;

[0023] Judge whether there is an execution exception according to the execution progress. If there is an execution exception, perform a reconnection operation on the collaborative device corresponding to the execution exception.

[0024] Further, after performing synchronous control on the collaborative devices according to the set of differential instructions, the method further includes:

[0025] Obtain the operation results of each of the collaborative devices;

[0026] Verify the operation results of each of the collaborative devices to obtain a verification result;

[0027] If the verification result is inconsistent, trigger a conflict resolution mechanism to generate a corresponding correction instruction, and send the correction instruction to the corresponding collaborative device.

[0028] Further, the method further includes:

[0029] Monitor the heartbeat signal of the master device on the session channel;

[0030] Determine the device status of the master device according to the heartbeat signal;

[0031] When the device status is in a failure state, based on the permission allocation matrix, screen candidate devices with the corresponding function permissions of the master device, and determine a target master device from the candidate devices.

[0032] In a second aspect, an embodiment of the present invention provides a multi-device collaborative control device, where the device includes:

[0033] A establishment module, configured to establish a session channel with a collaborative device according to the authentication information of the master device;

[0034] An acquisition module, configured to obtain the operating state parameters of the collaborative device based on the session channel, and generate a permission allocation matrix according to the operating state parameters of each of the collaborative devices;

[0035] A processing module, configured to process the task requirements of the master device by using the permission allocation matrix, generate a set of differentiated instructions, and perform synchronous control on the collaborative device according to the set of differentiated instructions.

[0036] In a third aspect, an embodiment of the present invention provides a computer device, including: a memory and a processor, which are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to execute the method according to the first aspect or any corresponding embodiment thereof.

[0037] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, on which computer instructions are stored, and the computer instructions are used to cause a computer to execute the method according to the first aspect or any corresponding embodiment thereof.

[0038] The method provided by the embodiments of the present application has the following beneficial effects:

[0039] The method provided by the embodiments of the present application establishes a session channel based on the authentication information of the master device, ensuring the security and reliability of device connection; obtaining the operating state parameters of the collaborative device based on the session channel and generating a permission allocation matrix, realizing dynamic and precise permission management, and effectively avoiding permission conflicts; using the permission allocation matrix to process task requirements and generate a differentiated instruction set, enabling intelligent task allocation according to device performance and improving task execution efficiency; performing synchronous control on the collaborative device according to the differentiated instruction set, ensuring the consistency and coordination of multi-device operations, thereby significantly improving the flexibility, efficiency, and security of multi-device collaborative control, and providing a better collaborative control solution for scenarios such as enterprise team collaboration and multi-user sharing in families. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for use in the description of the specific embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0041] Figure 1 is a flowchart of a multi-device collaborative control method according to an embodiment of the present invention;

[0042] Figure 2 is a flowchart of another multi-device collaborative control method according to an embodiment of the present invention;

[0043] Figure 3 is a flowchart of yet another multi-device collaborative control method according to an embodiment of the present invention;

[0044] Figure 4 is a flowchart of still another multi-device collaborative control method according to an embodiment of the present invention;

[0045] Figure 5 is a structural block diagram of a multi-device collaborative control device according to an embodiment of the present invention;

[0046] Figure 6 is a schematic hardware structure diagram of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0047] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Apparently, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0048] According to an embodiment of the present invention, there are provided a multi-device collaborative control method, apparatus, computer device, and storage medium. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0049] In this embodiment, a multi-device collaborative control method is provided. Figure 1 It is a flowchart of the multi-device collaborative control method according to an embodiment of the present invention, as Figure 1 shown, and the process includes the following steps:

[0050] Step S11: Establish a session channel with the collaborative device according to the authentication information of the master device.

[0051] In the embodiment of the present application, first, the master device submits authentication information including device identification, user credentials (such as digital certificates, dynamic tokens), etc. to the system, and the system verifies the legitimacy of its identity through a preset verification mechanism (such as hash verification, CA certificate comparison). If the verification passes, the system generates a unique session identifier (such as UUID), and based on this identifier, a two-way encrypted session channel based on the MQTT protocol is established between the master device and each collaborative device (such as mobile phones, PCs, tablets, etc.), and the AES-256-GCM algorithm is used to encrypt the transmission instructions end to end to ensure the security of the communication link. After the session channel is established, the master device can send control instructions to the collaborative device through this channel and simultaneously receive device status feedback to form a real-time interaction link.

[0052] Step S12: Obtain the operating state parameters of the collaborative device based on the session channel, and generate a permission allocation matrix according to the operating state parameters of each collaborative device.

[0053] In the embodiments of the present application, first, the master device requests the operating status parameters from the collaborative device through the session channel, including indicators such as CPU occupancy rate, available memory, network latency (such as RTT value), and historical task success rate (such as task completion rate in the past 5 minutes). The system extracts the hardware performance indicators (CPU, memory), network connection indicators (latency, bandwidth), and historical task execution indicators (success rate, response time) from these parameters and inputs them into the device capability evaluation model. The model calculates the performance scores of each device according to the preset formula. Among them, the CPU score is inversely converted based on the occupancy rate (the lower the occupancy rate, the higher the score), and the network score is normalized based on the latency value (for example, a full score is obtained when the latency ≤ 100 ms). Subsequently, the system assigns permission levels to the devices according to the scoring results: the top 20% of the scored devices are granted "master-level" permissions (full-function control), the middle 60% are granted "functional-level" permissions (specific module operations), and the bottom 20% are granted "observation-level" permissions (read-only access). Finally, a permission allocation matrix containing device IDs, permission levels, and function scopes is generated and stored in the permission management engine in a tabular form, for example.

[0054] Step S13: Process the task requirements of the master device using the permission allocation matrix to generate a set of differentiated instructions, and perform synchronous control on the collaborative device according to the set of differentiated instructions.

[0055] In the embodiments of the present application, first, the system analyzes the task requirements of the master device (such as "edit a document and make a call") based on the permission allocation matrix. According to the permission scopes of each device in the matrix (for example, the PC has the permission to edit documents, and the mobile phone has the permission to make calls), the operation fields in the task ("edit a document", "make a call") are extracted. Then, the system matches the operation fields with the device permissions to generate a set of differentiated instructions: send a document editing instruction (accompanied by the document path and editing permission token) to the PC, and send a call instruction (accompanied by the number and call permission token) to the mobile phone. After the instructions are sent to the corresponding devices through the session channel, the system receives the execution progress returned by the devices in real time (such as "document loading completed", "call in progress"), and ensures the consistency of multi-device operations through instruction-level differential synchronization technology. If an abnormal execution of a certain device is detected (such as a call failure due to a mobile phone network interruption), the system immediately triggers a reconnection mechanism, attempts to re-establish a connection through an alternative network (such as switching from Wi-Fi to mobile data). If the reconnection fails, the task is migrated to an alternative device with the same permissions (such as a smart watch taking over the call function), and an exception log is recorded at the same time.

[0056] As an example, such as Figure 2As shown in the figure, first, task type recognition is performed to determine that the task belongs to specific categories such as document editing and data transmission. Then, based on the task requirements and device status, available devices that meet the conditions are filtered out, such as devices with corresponding software and qualified hardware performance. Next, the weights of each available device in processing this task are calculated, comprehensively considering factors such as CPU performance and memory size. Then, according to the weights, the task is bound to the most suitable device. Finally, the device executes the bound task to complete the entire process.

[0057] It should be noted that, as Figure 3 shown, there are three system device states: the master control state, the function state, and the observation state. In the initial state, the device is in the master control state. When the device goes offline or the master control fails, the device switches to the function state; in the function state, if due to security policy requirements or manual adjustment, the device will change to the observation state; a device in the observation state can return to the function state through manual adjustment. If the master control fails when the device is in the function state or the observation state, the device can directly return to the master control state, realizing flexible conversion between different states and ensuring the stable operation and security control of the system.

[0058] In the embodiment of the present application, a session channel is established with the collaborative device according to the authentication information of the master control device, including: verifying the identity information of the master control device through the authentication information; if the verification is passed, a session identifier associated with the master control device is generated, and a two-way encrypted session channel is established between the master control device and each collaborative device based on the session identifier.

[0059] Specifically, the process of establishing a session channel with the collaborative device according to the authentication information of the master control device can be decomposed into three closely related links: identity verification, session identifier generation, and session channel establishment:

[0060] First, when the master control device starts the collaborative control process, it will submit authentication information including the device hardware feature code (such as MAC address, CPU serial number), user identity credentials (dynamic token, biometric data), and digital certificate to the system. After receiving the information, the system verifies the integrity of the device identifier through the hash check algorithm, decrypts and verifies the digital certificate using the public key of the certificate authority (CA), and at the same time combines the multi-factor authentication mechanism (such as secondary confirmation of the SMS verification code) to verify the identity legality of the master control device from multiple dimensions. If information mismatch or security risks (such as expired certificate, invalid token) are found during the verification process, the connection establishment is rejected and the security audit process is triggered.

[0061] Secondly, when the identity of the master device is successfully verified, the system generates a globally unique session identifier (such as a UUID-formatted string) based on the timestamp, random number, and device unique identifier through an encrypted hash function. This identifier not only serves as the exclusive "digital identity" for this session but is also associated with the permission information and device status data of the master device, forming a dynamic session record. The generation of the session identifier follows strict cryptographic security standards to ensure that it cannot be reverse-engineered or forged during network transmission and storage, providing a reliable identity anchor for subsequent session management and data interaction.

[0062] Finally, with the generated session identifier as the core, the system constructs a communication link between the master device and the collaborative devices based on the MQTT protocol. During this process, the AES-256-GCM end-to-end encryption algorithm is used to strongly encrypt the transmitted instruction data, and a secure connection is established through the TLS protocol to prevent man-in-the-middle attacks. When the channel is established, the master device and the collaborative devices perform key negotiation to dynamically generate a symmetric encryption key for subsequent data encryption and decryption operations. At the same time, the channel has a heartbeat detection mechanism that periodically sends probe packets to ensure the continuity of the connection. Once a link interruption is detected, the reconnection process will be automatically triggered to ensure the communication stability and data transmission security during the multi-device collaborative control process.

[0063] In the embodiment of this application, generating a permission allocation matrix according to the operating state parameters of each collaborative device includes the following steps A1 - A3:

[0064] Step A1, extract the hardware performance indicators, network connection indicators, and historical task execution indicators from each of the operating state parameters.

[0065] Specifically, after the master device establishes a session channel with the collaborative devices, the system starts to actively collect the operating status parameters of each collaborative device. For hardware performance metrics, the system monitors in real time data such as the CPU occupancy rate, number of processing cores, memory capacity and free rate, and GPU computing power of the device. For example, the real-time status of the CPU and memory is obtained by reading the system monitoring interfaces provided by the device operating system (such as the / proc file system of the Linux system and the performance counters of Windows). In terms of network connection metrics, the system collects information such as network latency, bandwidth utilization rate, and packet loss rate through the network protocol stack. For example, the round-trip time (RTT) is measured using the ping command of the ICMP protocol to evaluate network latency, and the packet loss rate is calculated by counting the ACK response situation during the TCP protocol transmission process. For historical task execution metrics, relying on the system log database, data such as the task completion rate, average response time, and task failure reasons of the device in the past period (such as the most recent 24 hours) are analyzed. For example, the ratio of the number of successfully processed document editing tasks to the total number of tasks of the device is counted, and the average time taken from task assignment to completion is calculated. Finally, the system integrates these metrics scattered in different data sources to form a set of status parameters for each collaborative device.

[0066] Step A2: Input the hardware performance metrics, network connection metrics, and historical task execution metrics into the device capability evaluation model to obtain the performance scores of each collaborative device.

[0067] Specifically, the system inputs the three types of extracted metrics into a pre-constructed device capability evaluation model. Inside the model, first, standardization processing is performed on each metric to eliminate the influence of dimensional differences. For example, the network latency is converted from milliseconds to a score value between 0 and 1 (the lower the latency, the closer the score is to 1), and the CPU occupancy rate is inversely mapped to a score (the lower the occupancy rate, the higher the score). Subsequently, according to the preset weight allocation scheme, weighted calculation is performed on the standardized metrics. The weight of the hardware performance metrics is 0.6, and the weight of the network connection metrics is 0.4 (the historical task execution metrics are implicitly included in the calculation logic. For example, the historical task success rate will affect the credibility weights of the hardware and network metrics). Taking a certain collaborative device as an example, if its standardized CPU score is 0.8 and the network latency score is 0.7, according to the device score function (performance score = 0.6 × CPU score + 0.4 × network score), the performance score of this device can be calculated as 0.6 × 0.8 + 0.4 × 0.7 = 0.76. By performing the same calculation process on all collaborative devices, the system finally obtains the performance scores corresponding to each device, providing a quantitative basis for subsequent permission allocation.

[0068] Step A3: Allocate corresponding functional permissions to each collaborative device according to the performance scores to obtain a permission allocation matrix.

[0069] Specifically, the system assigns functional permissions to collaborative devices based on the calculated performance score according to the preset permission classification strategy. Specifically, the top 20% of the performance-scoring devices are classified as "master control level" and given full-function control permissions, such as the team administrator device can perform operations such as parameter configuration of cloud phone instances and secondary permission allocation; the middle 60% of the scoring devices are classified as "functional level" and are assigned specific module operation permissions according to their functional areas of expertise (such as PC is suitable for document editing, mobile phone is suitable for call functions); the remaining 20% of the devices are classified as "observation level", which only opens read-only access and operation audit permissions, and is suitable for temporary visitor devices. The system stores the information such as the ID, performance score, permission level and operable function range of each device in the permission management engine in the form of a matrix to form a permission allocation matrix. For example, a row of data in the matrix may be [device ID_001, 0.85, master control level, full-function control permission]. Through this matrix, the system can quickly query and manage the permission status of each device, and realize dynamic permission management in the scenario of multi-device collaborative control.

[0070] In the embodiment of the present application, the task requirements of the master control device are processed using the authority allocation matrix to obtain a differentiated instruction set, including the following steps B1-B3:

[0071] Step B1, analyzing the task requirements of the master control device based on the authority allocation matrix to obtain the device authority range.

[0072] Specifically, when the master device initiates a task requirement (such as "complete project document editing and send meeting invitations"), the system first retrieves the generated permission allocation matrix, which records the permission level of each collaborative device (master level, functional level, observation level) and the corresponding operable function range. Based on the matrix information, the system sorts out the operations that each collaborative device can perform. For example, if the permission allocation matrix shows that the PC device is "functional level" and has document editing permissions, the mobile phone device is also "functional level" and has communication function permissions, while the smart watch is at the "observation level" and only supports operation auditing. At this time, the system determines the permission range of the PC device as "document editing related operations", the permission range of the mobile phone device as "communication module operations", and the smart watch has no actual operation permissions and can only view the task execution status. Through this parsing process, the permission boundaries of each device in the current task scenario are clarified, providing a basis for subsequent task decomposition.

[0073] Step B2: extracting the operation fields in the task requirements according to the device authority range.

[0074] Specifically, after clarifying the scope of permissions for each collaborative device, the system performs semantic analysis and field decomposition on the task requirements of the master device. Taking the task requirement of "completing project document editing and sending a meeting invitation" as an example, the system uses natural language processing technology (NLP) or a predefined task keyword library to identify the core operation fields, namely "document editing" and "sending a meeting invitation". Subsequently, the system matches these operation fields with the determined device permission scope to determine the executable devices corresponding to each operation field. For example, the "document editing" operation matches the "document editing related operations" permission scope of the PC device, and the "sending a meeting invitation" operation fits the "communication module operations" permission scope of the mobile device. In this way, the task requirements are decomposed into specific operation units that can be assigned to the corresponding devices, realizing the transformation of the task from the overall requirement to the refined operation.

[0075] Step B3: Generate a set of differential instructions that match the functional permissions of each collaborative device based on the operation fields.

[0076] Specifically, the system generates differential instructions for different collaborative devices according to the extracted operation fields and the matched devices. For the PC device, the system converts the "document editing" operation field into specific instructions, such as "open the project document path

[000] , perform format typesetting and content modification operations", and attaches a document editing permission token to verify the legality of the operation; for the mobile device, the "sending a meeting invitation" operation field is converted into "call the address book to obtain the list of participants, and send a meeting notice via email or instant messaging tool, with the content including [meeting time, location, agenda]", and at the same time carry a communication function permission certificate. These instructions are customized according to the functional characteristics and permission scope of each device to ensure that the instruction content is within the executable range of the device. Finally, the system integrates the instructions generated for different devices to form a set of differential instructions, such as {PC device instruction: [instruction content for editing document], mobile device instruction: [instruction content for sending invitation]}, and this set will be sent to the corresponding collaborative device through the session channel to drive the device to execute the corresponding task, achieving the goal of multi-device collaboration to complete the task requirements of the master device.

[0077] In the embodiment of the present application, synchronous control of the collaborative devices is performed according to the set of differential instructions, including the following steps C1 - C3:

[0078] Step C1: Send the set of differential instructions to the corresponding collaborative device through the session channel.

[0079] Specifically, after generating the differentiated instruction set, based on the established two-way encrypted session channel, the instructions are routed and distributed according to the device type. First, each instruction is encapsulated into structured data (such as JSON format) containing the device ID, operation type (such as editing a document), parameters (such as document path, call number), and permission token (JWT), and encrypted through the AES-256-GCM algorithm to ensure that the instructions cannot be tampered with or stolen during transmission. For example, as Figure 4 shown, the client sends the JWT token to the cloud server, and the cloud server parses the token after receiving it. If the parsed token is determined to be valid, the cloud server allows the client to perform the relevant operation and returns the operation result to the client; if the parsed token is determined to be invalid, the cloud server rejects the client's operation request and prompts an error message to the client.

[0080] Secondly, using the topic subscription mechanism of the MQTT protocol (such as [device / {device number} / instruction]), the encapsulated instructions are pushed to the target collaborative device. For example, the document editing instruction is sent to the PC device through the topic / device / PC001 / instruction, and the call instruction is sent to the mobile phone device through / device / Phone002 / instruction. Enable the QoS (Quality of Service) mechanism of MQTT (such as QoS1 to ensure at least one delivery). If the device does not respond in time, the system automatically retransmits the instruction until an acknowledgment receipt is received, avoiding instruction loss due to network fluctuations.

[0081] Step C2, receive the instruction execution progress returned by each collaborative device.

[0082] Specifically, the progress information returned by the device includes the task ID, current status (such as "received", "executing", "completed"), timestamp, real-time parameters (such as the cursor position of document editing, call connection status), etc. For example, when the mobile phone executes a call instruction, it will return statuses such as "calling, the other party has not answered" or "call established". The system continuously listens to the progress messages of all collaborative devices through the MQTT subscription topic, and uses the message queue to cache the unprocessed progress data to ensure that information is not lost in high-concurrency scenarios. The management interface of the master device visualizes the execution progress of each device. For example, the completion degree of document editing is displayed as a progress bar, and the execution status of the call instruction is identified by status icons (such as a green tick, a yellow exclamation mark), facilitating the administrator to monitor the task progress in real time.

[0083] Step C3, determine whether there is an execution exception based on the execution progress. If there is an execution exception, perform a reconnection operation on the collaborative device corresponding to the execution exception.

[0084] Specifically, the system performs anomaly detection and recovery based on real-time progress data. The specific logic is as follows: First, anomalies are identified according to anomaly determination rules, including timeout anomalies where the device fails to update the progress within a preset time (such as 30 seconds), security anomalies where the device returns a status conflicting with the permission allocation matrix (such as an observation-level device attempting to perform a write operation), and permission anomalies where the device returns a "permission denied" error due to insufficient permissions (such as a security anomaly). If an anomaly is detected, the reconnection operation process is entered. First, the device network connection is detected by sending a heartbeat packet (such as an Internet Control Message Protocol echo request). When the heartbeat is lost continuously for 3 times (the default threshold), it is confirmed that the device is offline or the link is interrupted. Subsequently, the authentication process is called, and the original session identifier is used to attempt to reconstruct the connection. If the authentication is successful, the unfinished instruction transmission is resumed. If it fails, the task migration mechanism is triggered (such as transferring the document editing task to a standby tablet device). At the same time, information such as the anomaly type, occurrence time, and device number is stored in the blockchain log (such as the blockchain evidence storage mechanism) for subsequent inspection and fault analysis. And during the reconnection or task migration process, through instruction-level differential synchronization technology (such as Message Queuing Telemetry Transport protocol breakpoint resumption), it is ensured that the unfinished operations continue from the breakpoint, avoiding repeated execution or loss. For example, the document editing progress can continue from the breakpoint, and the call task can be automatically switched to the standby device for continuation.

[0085] In the embodiment of the present application, after performing synchronous control on the collaborative devices according to the differentiated instruction set, the method further includes: obtaining the operation results of each collaborative device; verifying the operation results of each collaborative device to obtain a verification result; if the verification result is inconsistent, triggering a conflict resolution mechanism to generate corresponding correction instructions, and sending the correction instructions to the corresponding collaborative devices.

[0086] Specifically, when performing synchronous control on the collaborative devices according to the differentiated instruction set, the system will first obtain the operation results returned by each collaborative device, such as the version content after document editing, the status information of call records, etc. Then, the consistency verification of these operation results is performed through preset verification rules, and the verification rules can include data format verification, verification of the correctness of operation logic, comparison of multi-device results, etc. For example, when collaborating in a team to edit the same document, the system will compare whether there are conflicts or logical contradictions in the editing content submitted by different devices. If the verification result shows that the operation results are inconsistent (such as there are conflicts in the modification of the same data item by different devices), the conflict resolution mechanism is triggered. This mechanism will generate correction instructions according to the preset priority rules (such as the master device has priority, the latest operation overwrites the old operation, etc.), such as merging the conflicting content or rolling back to the nearest correct version. Finally, the system sends the correction instructions to the corresponding collaborative devices through the session channel. After receiving the instructions, the devices perform the correction operations to ensure the consistency of the results of multi-device collaborative operations, thereby ensuring the data integrity and operation accuracy of the cloud phone instance in the multi-device control scenario.

[0087] In the embodiments of the present application, the method further includes the following steps D1 - D3:

[0088] Step D1, monitor the heartbeat signal of the master device on the session channel.

[0089] Specifically, the system continuously monitors the operating state of the master device through the session channel, specifically implemented by periodically sending heartbeat signals. For example, every fixed time (such as 5 seconds), the system sends a probe packet containing information such as a timestamp and device identifier to the master device. After receiving the signal, the master device needs to return response data in a timely manner to indicate that it is in a normal online state. The transmission of this heartbeat signal is based on an established two-way encrypted session channel to ensure the security and reliability of the signal. If the master device fails to return a response on time due to reasons such as network interruption or hardware failure, the system will record the number of lost heartbeat signals, providing a basis for subsequent device status determination.

[0090] Step D2, determine the device status of the master device according to the heartbeat signal.

[0091] Specifically, the system performs real-time analysis and determination of the status of the master device based on the heartbeat signal. If the master device returns a normal heartbeat response on time for multiple consecutive times (such as 3 times), and the response time is within a reasonable range (such as less than 100 milliseconds), it is determined to be in the "online and normal" state; if the number of lost heartbeat signals exceeds a preset threshold (such as not receiving a response for 3 consecutive times), or the response data contains an abnormal status code (such as device overload, permission exception, etc.), it is determined that the master device is in a "failure state", including situations such as offline, faulty, or unable to perform control tasks normally. This status determination process provides a key basis for the system to trigger the master device switching mechanism.

[0092] Step D3, when the device status is in a failure state, screen candidate devices with the corresponding functional permissions of the master device based on the permission allocation matrix, and determine the target master device from the candidate devices.

[0093] Specifically, when the master device is determined to be in a failure state, the system immediately starts the automatic switching process: First, the permission allocation matrix is retrieved, and the collaborative devices with the "master control level" function permissions are screened out as candidate devices (for example, devices such as PCs and tablets that have been granted full-function control permissions). Then, the system ranks the candidate devices according to the performance scores calculated by the device capability evaluation model (such as comprehensive CPU performance, network quality, etc.), and preferentially selects the device with the highest score as the target master device. For example, if the performance score of a tablet device among the candidate devices is 0.9, which is higher than 0.85 of other candidate devices, a master control right takeover request will be sent to it preferentially. After receiving the request, if the candidate device confirms the response within the specified time (such as 5 seconds), the system will immediately update the control right ownership of the session channel, set it as the new master device, and synchronously migrate the task status and permission configuration of the original master device to ensure seamless connection in the multi-device collaborative control process and avoid task interruption caused by master failure.

[0094] In this embodiment, a multi-device collaborative control device is also provided. This device is used to implement the above embodiments and preferred implementation manners, and those that have been described will not be repeated. As used hereinafter, the term "module" can be a combination of software and / or hardware that can achieve a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0095] This embodiment provides a multi-device collaborative control device, as Figure 5 shown, including:

[0096] A establishment module 51, configured to establish a session channel with a collaborative device according to the authentication information of the master device;

[0097] An acquisition module 52, configured to obtain the operating state parameters of the collaborative device based on the session channel, and generate a permission allocation matrix according to the operating state parameters of each collaborative device;

[0098] A processing module 53, configured to process the task requirements of the master device by using the permission allocation matrix, generate a differential instruction set, and perform synchronous control on the collaborative device according to the differential instruction set.

[0099] Further, the establishment module 51 is configured to verify the identity information of the master device through the authentication information; if the verification is passed, a session identifier associated with the master device is generated, and a two-way encrypted session channel is established between the master device and each collaborative device based on the session identifier.

[0100] Further, an acquisition module 52 is configured to extract hardware performance metrics, network connection metrics, and historical task execution metrics from each operation status parameter; input the hardware performance metrics, network connection metrics, and historical task execution metrics into a device capability evaluation model to obtain performance scores of each collaborative device; and allocate corresponding function permissions to each collaborative device according to the performance scores to obtain a permission allocation matrix.

[0101] Further, a processing module 53 is configured to analyze the task requirements of the master device based on the permission allocation matrix to obtain a device permission range; extract an operation field from the task requirements according to the device permission range; and generate a set of differential instructions that match the function permissions of each collaborative device based on the operation field.

[0102] Further, the processing module 53 is configured to send the set of differential instructions to the corresponding collaborative device through a session channel; receive the instruction execution progress returned by each collaborative device; determine whether there is an execution exception according to the execution progress, and if there is an execution exception, perform a reconnection operation on the collaborative device corresponding to the execution exception.

[0103] Further, the apparatus further includes: a verification module, configured to obtain the operation results of each collaborative device; verify the operation results of each collaborative device to obtain a verification result; if the verification result is inconsistent, trigger a conflict resolution mechanism to generate a corresponding correction instruction, and send the correction instruction to the corresponding collaborative device.

[0104] Further, the apparatus further includes: a monitoring module, configured to monitor the heartbeat signal of the master device in the session channel; determine the device status of the master device according to the heartbeat signal; when the device status is in a failure state, screen candidate devices with the corresponding function permissions of the master device based on the permission allocation matrix, and determine a target master device from the candidate devices.

[0105] Please refer to Figure 6 , Figure 6 which is a schematic structural diagram of a computer device provided by an optional embodiment of the present invention, as Figure 6As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting the components, including a high-speed interface and a low-speed interface. Each component communicates with each other using different buses and can be installed on a common motherboard or installed in other ways as needed. The processor can process instructions executed within the computer device, including instructions stored in the memory or on the memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some alternative embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a set of blade servers, or a multi-processor system).

[0106] The processor 10 can be a central processing unit, a network processor, or a combination thereof. Among them, the processor 10 can further include a hardware chip. The above hardware chip can be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The above programmable logic device can be a complex programmable logic device, a field programmable gate array, a generic array logic, or any combination thereof.

[0107] Among them, the memory 20 stores instructions executable by at least one processor 10, so that at least one processor 10 executes the method shown in the above embodiments.

[0108] The memory 20 can include a program storage area and a data storage area. Among them, the program storage area can store an operating system and application programs required for at least one function; the data storage area can store data created according to the use of the computer device presented by a kind of landing page of a small program, etc. In addition, the memory 20 can include a high-speed random access memory, and can also include a non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some alternative embodiments, the memory 20 can optionally include a memory remotely set relative to the processor 10, and these remote memories can be connected to the computer device through a network. Examples of the above network include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0109] The memory 20 can include a volatile memory, such as a random access memory; the memory can also include a non-volatile memory, such as a flash memory, a hard disk, or a solid-state drive; the memory 20 can also include a combination of the above types of memories.

[0110] The computer device further includes a communication interface 30 for the computer device to communicate with other devices or communication networks.

[0111] Embodiments of the present invention also provide a computer-readable storage medium. The methods according to the embodiments of the present invention can be implemented in hardware, firmware, or be implemented as computer code that can be recorded on a storage medium, or be implemented by downloading over a network and originally stored in a remote storage medium or a non-transitory machine-readable storage medium and to be stored in a local storage medium, so that the methods described herein can be stored as such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only memory, a random access memory, a flash memory, a hard disk, or a solid-state drive, etc.; further, the storage medium can also include a combination of the above-mentioned types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code, and when the software or computer code is accessed and executed by the computer, the processor, or the hardware, the methods shown in the above embodiments are implemented.

[0112] Although embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A multi-device collaborative control method, characterized in that, The method includes: Establishing a session channel with the collaborative device according to the authentication information of the master device; Obtaining the operating state parameters of the collaborative device based on the session channel, and generating a permission allocation matrix according to the operating state parameters of each collaborative device; Processing the task requirements of the master device by using the permission allocation matrix, generating a set of differentiated instructions, and performing synchronous control on the collaborative device according to the set of differentiated instructions.

2. The method according to claim 1, wherein The establishing a session channel with the collaborative device according to the authentication information of the master device includes: Verifying the identity information of the master device through the authentication information; If the verification is passed, generating a session identifier associated with the master device, and establishing a two-way encrypted session channel between the master device and each collaborative device based on the session identifier.

3. The method according to claim 1, wherein The generating a permission allocation matrix according to the operating state parameters of each collaborative device includes: Extracting the hardware performance index, network connection index and historical task execution index from each of the operating state parameters; Inputting the hardware performance index, the network connection index and the historical task execution index into a device capability evaluation model to obtain the performance scores of each collaborative device; Allocating corresponding function permissions to each collaborative device according to the performance scores to obtain a permission allocation matrix.

4. The method according to claim 1, wherein The processing the task requirements of the master device by using the permission allocation matrix to obtain a set of differentiated instructions includes: Analyzing the task requirements of the master device based on the permission allocation matrix to obtain the device permission range; Extracting the operation fields in the task requirements according to the device permission range; Generating a set of differential instructions that match the function permissions of each collaborative device based on the operation fields.

5. The method according to claim 1, wherein The performing synchronous control on the collaborative device according to the set of differentiated instructions includes: Sending the set of differentiated instructions to the corresponding collaborative device through the session channel; Receiving the instruction execution progress returned by each collaborative device; Judging whether there is an execution exception according to the execution progress. If there is an execution exception, performing a reconnection operation on the collaborative device corresponding to the execution exception.

6. The method according to claim 5, characterized in that After performing synchronous control on the collaborative device according to the set of differentiated instructions, the method further includes: Obtaining the operation results of each collaborative device; Verifying the operation results of each collaborative device to obtain a verification result; If the verification result is inconsistent, triggering a conflict resolution mechanism to generate corresponding correction instructions, and sending the correction instructions to the corresponding collaborative device.

7. The method according to claim 1, characterized in that, The method further includes: Monitoring the heartbeat signal of the master device in the session channel; Determining the device state of the master device according to the heartbeat signal; When the device state is in a failure state, screening candidate devices with the corresponding function permissions of the master device based on the permission allocation matrix, and determining a target master device from the candidate devices.

8. A multi-device collaborative control device, characterized in that, The device includes: A establishing module, configured to establish a session channel with the collaborative device according to the authentication information of the master device; An acquisition module, configured to acquire the operating state parameters of the collaborative device based on the session channel, and generate a permission allocation matrix according to the operating state parameters of each collaborative device; A processing module, configured to process the task requirements of the master device by using the permission allocation matrix, generate a set of differentiated instructions, and perform synchronous control on the collaborative device according to the set of differentiated instructions.

9. A computer device, characterized in that, It includes: A memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Computer instructions are stored on the computer-readable storage medium, and the computer instructions are used to cause a computer to execute the method according to any one of claims 1 to 7.

Images