Cloud mobile phone monitoring method and device

By using private protocols to register and monitor cloud mobile nodes in cloud gaming scenarios, the problem of insufficient stability and efficiency of cloud gaming services in the existing technology is solved, efficient and secure cloud mobile node management is achieved, and the real-time and reliability of cloud gaming is improved.

CN120343081APending Publication Date: 2025-07-18BEIJING BAIDU NETCOM SCI & TECH CO LTD +1
View PDF 7 Cites 0 Cited by

Patent Information

Application Number
CN202510630323.7
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-05-15
Publication Date
2025-07-18

AI Technical Summary

Technical Problem

In the existing cloud gaming scenario, the registration and monitoring of cloud mobile phone nodes rely on third-party tools, and the lack of efficient, secure and flexible monitoring mechanisms, resulting in insufficient stability and efficiency of cloud gaming services.

Method used

Private protocols are used to report the registration and operation status of cloud mobile phone nodes, receive registration requests through the central management server and regularly monitor the node status to achieve efficient and secure cloud mobile phone node management.

Benefits of technology

It provides more efficient data storage and processing capabilities, improves the real-time and reliability of cloud gaming services, improves fault detection and recovery efficiency, and ensures the stable operation of cloud gaming.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120343081A_ABST
    Figure CN120343081A_ABST
Patent Text Reader

Abstract

The invention provides a cloud mobile phone monitoring method and device, and relates to the technical field of cloud computing, in particular to the technical field of cloud games. A specific embodiment of the method comprises the following steps: receiving a registration request sent by a cloud mobile phone node when the cloud mobile phone node is started, the registration request comprising node information; registering the cloud mobile phone node based on the registration request; receiving a running state periodically reported by the cloud mobile phone node by using a private protocol; and monitoring the cloud mobile phone node based on the operation state.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present disclosure relates to the field of cloud computing technology, and particularly to the field of cloud game technology. Background Art

[0002] Cloud game is a game mode based on cloud computing. In the operation mode of cloud game, all games are run on cloud phones on the server side, and the rendered game screens are compressed and transmitted to users through the network. On the client side, the user's game device does not require any high-end processor and graphics card, only basic video decompression ability.

[0003] The server side may include a large number of cloud phones to run cloud games. The running states of these cloud phones need to be monitored to ensure the stable operation of cloud games. Currently, it is usually dependent on third-party tools to implement the registration and monitoring of multi-cloud phone nodes in the cloud game scenario. Summary of the Invention

[0004] Embodiments of the present disclosure propose a cloud phone monitoring method, device, equipment, storage medium, and program product.

[0005] In a first aspect, embodiments of the present disclosure propose a cloud phone monitoring method, including: receiving a registration request sent by a cloud phone node when starting up, where the registration request includes node information; registering the cloud phone node based on the registration request; receiving the running state regularly reported by the cloud phone node using a private protocol; and monitoring the cloud phone node based on the running state.

[0006] In a second aspect, embodiments of the present disclosure propose a cloud phone monitoring device, including: a first module configured to receive a registration request sent by a cloud phone node when starting up, where the registration request includes node information; a registration module configured to register the cloud phone node based on the registration request; a second receiving module configured to receive the running state regularly reported by the cloud phone node using a private protocol; and a monitoring module configured to monitor the cloud phone node based on the running state.

[0007] In a third aspect, embodiments of the present disclosure propose an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; where the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the method described in the first aspect.

[0008] In a fourth aspect, embodiments of the present disclosure propose a non-transitory computer-readable storage medium storing computer instructions for causing a computer to execute the method described in the first aspect.

[0009] Fifth aspect, an embodiment of the present disclosure provides a computer program product, including a computer program which, when executed by a processor, implements the method described in the first aspect.

[0010] The key or important features of the embodiments of the present disclosure are not used to limit the scope of the present disclosure either. Other features of the present disclosure will become easily understandable through the following description. Description of the Drawings

[0011] By reading the detailed description of the non-limiting embodiments with reference to the following drawings, other features, objectives, and advantages of the present disclosure will become more obvious. The drawings are used to better understand the solution and do not constitute a limitation to the present disclosure. Among them: Figure 1 is a flowchart of an embodiment of the cloud mobile phone monitoring method according to the present disclosure; Figure 2 is a flowchart of another embodiment of the cloud mobile phone monitoring method according to the present disclosure; Figure 3 is a flowchart of another embodiment of the cloud mobile phone monitoring method according to the present disclosure; Figure 4 is a system block diagram of cloud mobile phone monitoring; Figure 5 is a schematic structural diagram of an embodiment of the cloud mobile phone monitoring device according to the present disclosure; Figure 6 is a block diagram of an electronic device for implementing the cloud mobile phone monitoring method of the embodiments of the present disclosure. Detailed Embodiments

[0012] The following describes exemplary embodiments of the present disclosure in conjunction with the drawings. Various details of the embodiments of the present disclosure are included to facilitate understanding, and they should be considered merely exemplary. Therefore, those of ordinary skill in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present disclosure. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0013] It should be noted that, without conflict, the embodiments in the present disclosure and the features in the embodiments can be combined with each other. The present disclosure will be described in detail below with reference to the drawings and in conjunction with the embodiments.

[0014] Figure 1 Flow 100 of an embodiment of the cloud mobile phone monitoring method according to the present disclosure is shown. The cloud mobile phone monitoring method includes the following steps: Step 101, receiving a registration request sent by a cloud mobile phone node at startup.

[0015] In this embodiment, the Centralized Management Service (CMS) can receive the registration requests sent by the cloud mobile phone nodes when they start up.

[0016] Each cloud mobile phone node can register with the central management server when it starts up. Among them, the central management server is a core control module in a distributed system or platform architecture, responsible for uniformly managing, coordinating, and monitoring the operating status and task scheduling of multiple components, nodes, users, or devices.

[0017] When each cloud mobile phone node registers with the central management server, it can send a registration request. Among them, the registration request can include node information. The node information can include an identifier and an operating status. The identifier can be used to uniquely identify the cloud mobile phone node. The operating status can be the node dimension status, including but not limited to at least one of the following: online or offline status, CPU (Central Processing Unit) or GPU occupancy rate, memory usage, network status, and number of active sessions, etc. The online or offline status can be used to determine whether the cloud mobile phone node is running and whether it is healthy. The CPU or GPU occupancy rate can be used to determine whether there is overloading and whether capacity expansion is required. The memory usage can be used to determine whether there is memory leakage or resource tension. The network status can include but not limited to: current egress bandwidth, packet loss rate, number of connections, etc. The number of active sessions can be used to represent the number of user connections carried by the current service node.

[0018] In some embodiments, before the cloud mobile phone node sends a registration request, a session connection needs to be established between the central management server and the cloud mobile phone. Usually, each cloud mobile phone node can send a connection request to the central management server when it starts up. The connection request can include information about the cloud mobile phone node. The central management server can perform session verification based on the information of the cloud mobile phone node, establish a session connection with the cloud mobile phone node that passes the session verification, and at the same time allocate a session identifier. Among them, the session identifier can be used to uniquely identify the session.

[0019] In some embodiments, the connection types between the cloud mobile phone node and the central management server can include TCP (Transmission Control Protocol) connections and UDP (User Datagram Protocol) connections. Among them, for network types with higher stability, TCP connections can be established to continuously track the operating status. For network types with lower stability, UDP connections can be established to report the operating status non-strongly in real time and accept occasional loss of the operating status.

[0020] In some embodiments, after establishing a session connection between the cloud mobile phone node and the central management server, the cloud mobile phone node can periodically send heartbeat packets to the central management server (for example, send a heartbeat packet every 30 seconds). For the situation where the central management server fails to receive the heartbeat packets sent by the cloud mobile phone node for a preset consecutive number of times (such as 6 consecutive times), the central management server can re - establish the session connection with the cloud mobile phone node.

[0021] Step 102: Register the cloud mobile phone node based on the registration request.

[0022] In this embodiment, the central management server can register the cloud mobile phone node based on the registration request.

[0023] Step 103: Receive the operation status reported regularly by the cloud mobile phone node using the private protocol.

[0024] In this embodiment, the central management server can receive the operation status reported regularly by the cloud mobile phone node using the private protocol.

[0025] Adopting the private protocol, each cloud mobile phone node can regularly report its own operation status to the central management server. Among them, the private protocol can be a communication rule and data interaction specification. By regularly reporting the operation status to the central management server through the private protocol, unified scheduling and multi - point monitoring can be achieved.

[0026] The private protocol can be used for efficient, secure, and stable data exchange between devices and servers. Its core idea is to design a set of customized data structures and transmission rules based on specific business requirements, so as to maximize data transmission efficiency, compress performance overhead, and enhance the security and controllability during the communication process.

[0027] The private protocol can be divided into three - layer structures, including the message header (Header) layer, the message body (Payload) layer, and the additional control (Optional Control) layer. Among them, the message header layer can be used to identify at least one of the message type, version, length, and checksum, etc. The message body layer can contain business data or instruction content. The additional control layer can be used to expand fields, security signatures, timestamps, etc., to enhance extensibility and data consistency guarantee.

[0028] The fields of the private protocol may include, but are not limited to, at least one of the following: protocol identifier (Magic Number), protocol version number (Version), message type (Message Type), message body length (Payload Length), session identifier (Session ID), control flag bits (Flags), checksum field (Checksum or CRC), message body (Payload), etc. Among them, the protocol identifier may occupy 2 bytes and is used to quickly identify private protocol packets. The protocol version number may occupy 1 byte and is used to identify the private protocol version. The message type may occupy 1 byte and includes, but is not limited to, heartbeat, data, command, response, etc. The message body length may occupy 2 bytes and is used to identify the length of the message body of the private protocol. The session identifier may occupy 4 bytes and is used to support concurrency and status tracking. The control flag bits may occupy 1 byte and are used to define whether to encrypt, compress, etc. The checksum field may occupy 2 bytes and is used to verify data integrity. The message body may occupy N (N is a positive integer) bytes and represents the actual business data content.

[0029] The connection methods of the private protocol may include TCP connection and / or UDP connection. After the initialization of the private protocol connection, information such as the protocol version and supported capabilities can be confirmed through a handshake.

[0030] The message sending and receiving methods of the private protocol may include, but are not limited to, at least one of the following: each message carries a session identifier for tracking responses and asynchronous processing, a heartbeat packet is used to maintain communication in the long connection state, and an ACK (Acknowledge) mechanism and retransmission strategy are adopted to ensure reliability.

[0031] The compression and throttling methods of the private protocol may include, but are not limited to, at least one of the following: large data packets are transmitted after being compressed by GZIP, a sliding window is used to control the bandwidth peak, and the heartbeat or reporting period is dynamically adjusted to save resources.

[0032] The advantages of each cloud mobile phone node reporting its operating status to the central management server using the private protocol mainly include the following four: First, high performance: The streamlined field design is suitable for embedded devices and high-frequency scenarios.

[0033] Second, high security: Built-in encryption and authentication mechanisms to prevent data tampering and unauthorized access.

[0034] Third, strong scalability: Reserved extension fields and flag bits to support future protocol upgrades.

[0035] Fourth, good compatibility: Support docking with third-party API (Application Programming Interface) gateways or cloud platforms.

[0036] In some embodiments, the cloud phone node can transmit compressed binary data streams through a socket network. Among them, the cloud phone node encapsulates the collected operating status into the message body of a private protocol, encapsulates the message body into a binary data stream, and compresses the binary data stream through the flatbuffers protocol to obtain a compressed binary data stream.

[0037] Step 104, monitor the cloud phone node based on the operating status.

[0038] In this embodiment, the central management server can monitor the cloud phone node based on the operating status.

[0039] The central management server can store and process the information of all cloud phone nodes, and provide real-time monitoring, anomaly detection, and alarm mechanisms. Among them, anomaly detection can be performed through rules such as heartbeat loss, resource overload, and network problems. If an anomaly is detected (such as heartbeat loss, registration failure, network instability, etc.), the system will trigger alarms at different levels and take corresponding recovery measures (such as migrating users, restarting nodes, or adjusting the load, etc.).

[0040] The embodiments of the present disclosure provide a cloud phone monitoring method, which is based on the timed status reporting of a private protocol, has better flexibility and convenience, and reduces the dependence on external component libraries; supports centralized management of different cloud phone nodes, supports unified management of multi-node information, and provides more efficient data storage and processing capabilities; provides the real-time and reliability of the system. Through a custom protocol, the status update can be made real-time, and at the same time, the efficiency of node fault detection and recovery is improved.

[0041] Continue to refer to Figure 2 , which shows the flow 200 of another embodiment of the cloud phone monitoring method according to the present disclosure. The cloud phone monitoring method includes the following steps: Step 201, receive the registration request sent by the cloud phone node when starting up.

[0042] Step 202, register the cloud phone node based on the registration request.

[0043] Step 203, receive the operating status regularly reported by the cloud phone node using the private protocol.

[0044] In this embodiment, the specific operations of steps 201-203 have been described in Figure 1In the embodiments shown, steps 101-103 are introduced in detail and will not be elaborated here.

[0045] Step 204, in response to determining that the cloud mobile phone node fails based on the running state, automatically restart the cloud mobile phone node.

[0046] In this embodiment, the central management server can determine whether the cloud mobile phone node fails based on the running state. If the cloud mobile phone node fails, the cloud mobile phone node can be automatically restarted.

[0047] After the cloud mobile phone node is automatically restarted, it usually re-registers with the central management server to ensure system state synchronization and node validity verification.

[0048] After the cloud mobile phone node is automatically restarted, the following operations can be performed: First step, initialize the configuration and perform status detection (read information such as node ID, version, network, etc.).

[0049] Second step, actively register with the central management server through a private protocol, indicating "I am online".

[0050] Third step, the central management server records the information of the cloud mobile phone node and incorporates it into the scheduling system.

[0051] Fourth step, if there is a cloud mobile phone node with the same name, the central management server can choose to update or replace its status to prevent zombie nodes.

[0052] Fifth step, the cloud mobile phone node enters a periodic status reporting and heartbeat detection process.

[0053] The embodiments of the present disclosure provide a cloud mobile phone monitoring method, which automatically restarts the cloud mobile phone node when the cloud mobile phone node fails, ensuring that the central management server masters the latest available node pool; avoiding the situation where the cloud mobile phone node continues to serve after restart but is not perceived by the central management server, resulting in scheduling anomalies; and triggering task reallocation or container hot standby mechanisms.

[0054] Further referring to Figure 3 , it shows the flow 300 of another embodiment of the cloud mobile phone monitoring method according to the present disclosure. The cloud mobile phone monitoring method includes the following steps: Step 301, receive the registration request sent by the cloud mobile phone node when starting up.

[0055] Step 302, register the cloud mobile phone node based on the registration request.

[0056] Step 303, receive the running state regularly reported by the cloud mobile phone node using the private protocol.

[0057] In this embodiment, the specific operations of steps 301-303 have been Figure 1 introduced in detail in steps 101-103 of the embodiment shown, and will not be elaborated here.

[0058] Step 304, in response to determining that a cloud mobile phone node fails based on the running state, perform scheduling adjustment on the cloud mobile phone node.

[0059] In this embodiment, the central management server can determine whether a cloud mobile phone node fails based on the running state. If the cloud mobile phone node fails, scheduling adjustment can be performed on the cloud mobile phone node. The scheduling adjustment result can be updated to the system status table and notify the client to make a connection or adjust the image quality, so as to realize the stable and efficient operation of the cloud game service.

[0060] In some embodiments, based on the running state, the central management server can determine the load condition of the cloud mobile phone node; in response to determining that the resource utilization rate of the cloud mobile phone node is higher than the preset resource utilization rate threshold based on the load condition, the central management server can allocate at least part of the load of the cloud mobile phone node to other cloud mobile phone nodes (preferably allocated to healthy cloud mobile phone nodes) to achieve load balancing.

[0061] In some embodiments, based on the running state, the central management server can determine the network condition of the cloud mobile phone node; in response to determining that the network of the cloud mobile phone node is abnormal based on the network condition, the central management server can reconnect to other cloud mobile phone nodes (reconnect to other available cloud mobile phone nodes) to achieve fault migration.

[0062] In some embodiments, based on the running state, the central management server can determine the performance condition of the cloud mobile phone node; in response to determining that the performance of the cloud mobile phone decreases based on the performance condition, the central management server can perform image quality adaptation on the cloud mobile phone node to reduce the bit rate to cope with network fluctuations.

[0063] The embodiments of the present disclosure provide a cloud mobile phone monitoring method, which can perform scheduling adjustment on the cloud mobile phone node when the cloud mobile phone node fails, and can realize the stable and efficient operation of the cloud game service.

[0064] Figure 4 shows a block diagram of cloud mobile phone monitoring. As Figure 4As shown in the figure, cloud mobile phone nodes 402, 403, and 404 can register with the central management server 401 when starting up, providing information such as their unique identifiers and operating status. Then, using a private protocol, cloud mobile phone nodes 402, 403, and 404 can regularly report their operating status to the central management server 401, including CPU load, memory usage, network status, etc. The central management server 401 can store and process the information of cloud mobile phone nodes 402, 403, and 404, providing real-time monitoring, anomaly detection, and alarm mechanisms. When a certain node among cloud mobile phone nodes 402, 403, and 404 fails or goes offline, the system can quickly identify and perform automatic restart or scheduling adjustment.

[0065] Further referring to Figure 5 , as an implementation of the methods shown in the above figures, the present disclosure provides an embodiment of a cloud mobile phone monitoring device. This device embodiment corresponds to Figure 1 the method embodiment shown in the figure, and this device can be specifically applied to various electronic devices.

[0066] As Figure 5 shown, the cloud mobile phone monitoring device 500 of this embodiment may include: a first receiving module 501, a registration module 502, a second receiving module 503, and a monitoring module 504. Among them, the first receiving module 501 is configured to receive a registration request sent by a cloud mobile phone node when starting up, where the registration request includes node information; the registration module 502 is configured to register the cloud mobile phone node based on the registration request; the second receiving module 503 is configured to receive the operating status regularly reported by the cloud mobile phone node using a private protocol; the monitoring module 504 is configured to monitor the cloud mobile phone node based on the operating status.

[0067] In this embodiment, in the cloud mobile phone monitoring device 500: the specific processing of the first receiving module 501, the registration module 502, the second receiving module 503, and the monitoring module 504 and the technical effects brought by them can respectively refer to Figure 1 the relevant descriptions of steps 101 - 104 in the corresponding embodiment, which will not be elaborated here.

[0068] In some optional implementation manners of this embodiment, the node information includes an identifier and an operating status, and the operating status includes at least one of the following: online or offline status, central processing unit (CPU) or graphics processing unit (GPU) occupancy rate, memory usage, network status, and number of active sessions.

[0069] In some alternative implementation manners of this embodiment, the private protocol is divided into a three-layer structure, including a message header layer, a message body layer, and an additional control layer. The message header layer is used to identify at least one of a message type, a version, a length, and a checksum. The message body layer contains service data or instruction content. The additional control layer is used to implement at least one of an extended field, a security signature, and a timestamp.

[0070] In some alternative implementation manners of this embodiment, the fields of the private protocol include at least one of the following: a protocol identifier, a protocol version number, a message type, a message body length, a session identifier, a control flag bit, a checksum field, and a message body.

[0071] In some alternative implementation manners of this embodiment, the connection mode of the private protocol includes a Transmission Control Protocol (TCP) long connection and / or a User Datagram Protocol (UDP) short connection; the message sending and receiving mode of the private protocol includes at least one of the following: each message carries a session identifier, a heartbeat packet is used to maintain communication in the long connection state, an Acknowledgment (ACK) mechanism and a retransmission strategy are adopted; the compression and throttling mode of the private protocol includes at least one of the following: large data packets are transmitted after being compressed by GZIP, a sliding window is used to control the bandwidth peak value, and the heartbeat or reporting period is dynamically adjusted.

[0072] In some alternative implementation manners of this embodiment, the cloud phone monitoring device 500 further includes: a third receiving module, configured to receive a connection request sent by a cloud phone node when starting up, where the connection request includes information of the cloud phone node; a verification module, configured to perform session verification based on the information of the cloud phone node; a first establishment module, configured to establish a session connection with the cloud phone node and allocate a session identifier in response to passing the session verification.

[0073] In some alternative implementation manners of this embodiment, the first establishment module is further configured to: determine a connection type based on the network type of the cloud phone node, where the connection type is a TCP connection or a UDP connection; establish a session connection with the cloud phone node based on the connection type.

[0074] In some alternative implementation manners of this embodiment, the cloud phone monitoring device 500 further includes: a fourth receiving module, configured to receive a heartbeat packet periodically sent by a cloud phone node; a second establishment module, configured to re-establish a session connection with the cloud phone node in response to not receiving the heartbeat packet sent by the cloud phone node for a preset number of consecutive times.

[0075] In some alternative implementation manners of this embodiment, the second receiving module 503 is further configured to: receive a compressed binary data stream transmitted by a cloud mobile phone node through a socket network, where the cloud mobile phone node encapsulates the running state into a message body of a private protocol, encapsulates the message body into a binary data stream, and performs data compression on the binary data stream through a variable buffer protocol to obtain a compressed binary data stream.

[0076] In some alternative implementation manners of this embodiment, the monitoring module 504 is further configured to: automatically restart the cloud mobile phone node in response to determining that the cloud mobile phone node fails based on the running state.

[0077] In some alternative implementation manners of this embodiment, the monitoring module 504 is further configured to: perform scheduling adjustment on the cloud mobile phone node in response to determining that the cloud mobile phone node fails based on the running state.

[0078] In some alternative implementation manners of this embodiment, the monitoring module 504 is further configured to: determine the load condition of the cloud mobile phone node based on the running state; and in response to determining that the resource utilization rate of the cloud mobile phone node is higher than a preset resource utilization rate threshold based on the load condition, allocate at least part of the load of the cloud mobile phone node to other cloud mobile phone nodes.

[0079] In some alternative implementation manners of this embodiment, the monitoring module 504 is further configured to: determine the network condition of the cloud mobile phone node based on the running state; and in response to determining that the network of the cloud mobile phone node is abnormal based on the network condition, reconnect to other cloud mobile phone nodes.

[0080] In some alternative implementation manners of this embodiment, the monitoring module 504 is further configured to: determine the performance condition of the cloud mobile phone node based on the running state; and in response to determining that the performance of the cloud mobile phone has decreased based on the performance condition, perform image quality adaptation on the cloud mobile phone node.

[0081] In the technical solution of the present disclosure, the acquisition, storage, and application of the user's personal information involved all comply with the provisions of relevant laws and regulations and do not violate public order and good customs.

[0082] According to an embodiment of the present disclosure, the present disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0083] Figure 6FIG. 0 is a schematic block diagram of an example electronic device 600 that can be used to implement embodiments of the present disclosure. The electronic device is intended to represent various forms of digital computers, such as, for example, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as, for example, personal digital processors, cellular telephones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely exemplary and are not intended to limit the implementations of the present disclosure described and / or claimed herein.

[0084] As Figure 6 shown, the device 600 includes a computing unit 601 that can perform various appropriate actions and processes in accordance with a computer program stored in a read only memory (ROM) 602 or a computer program loaded from a storage unit 608 into a random access memory (RAM) 603. In the RAM 603, various programs and data required for the operation of the device 600 can also be stored. The computing unit 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0085] A plurality of components in the device 600 are connected to the I / O interface 605, including: an input unit 606, such as, for example, a keyboard, a mouse, etc.; an output unit 607, such as, for example, various types of displays, speakers, etc.; a storage unit 608, such as, for example, a magnetic disk, an optical disk, etc.; and a communication unit 609, such as, for example, a network card, a modem, a wireless communication transceiver, etc. The communication unit 609 allows the device 600 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0086] The computing unit 601 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 executes the various methods and processes described above, such as the cloud mobile phone monitoring method. For example, in some embodiments, the cloud mobile phone monitoring method can be implemented as a computer software program tangibly embodied in a machine-readable medium, such as the storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed onto the device 600 via the ROM 602 and / or the communication unit 609. When the computer program is loaded into the RAM 603 and executed by the computing unit 601, one or more steps of the cloud mobile phone monitoring method described above can be executed. Alternatively, in other embodiments, the computing unit 601 can be configured to execute the cloud mobile phone monitoring method in any other suitable manner (e.g., by means of firmware).

[0087] Various embodiments of the systems and techniques described above in this document can be implemented in digital electronic circuitry, integrated circuit systems, field-programmable gate arrays (FPGA), application-specific integrated circuits (ASIC), application-specific standard products (ASSP), systems-on-a-chip (SOC), complex programmable logic devices (CPLD), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include: implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a dedicated or general-purpose programmable processor, and can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit the data and instructions to the storage system, the at least one input device, and the at least one output device.

[0088] The program code for implementing the methods of the present disclosure can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when the program codes are executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program codes can be executed entirely on the machine, partially on the machine, as an independent software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0089] In the context of this disclosure, a machine-readable medium can be a tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0090] In order to provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, speech input, or tactile input).

[0091] The systems and techniques described herein can be implemented in a computing system that includes backend components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes frontend components (e.g., a user computer having a graphical user interface or a web browser through which the user can interact with an implementation of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or frontend components. The components of the system can be interconnected to each other by any form or medium of digital data communication (e.g., a communication network). Examples of a communication network include: a local area network (LAN), a wide area network (WAN), and the Internet.

[0092] A computer system can include a client and a server. The client and the server are generally remote from each other and typically interact through a communication network. The client-server relationship is generated by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, a server of a distributed system, or a server incorporating a blockchain.

[0093] It should be understood that the various forms of processes shown above can be used, with steps reordered, added or deleted. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in a different order, as long as the desired results of the technical solution provided in this disclosure can be achieved, and no limitations are imposed herein.

[0094] The above specific embodiments do not constitute a limitation on the protection scope of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub - combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure shall be included within the protection scope of this disclosure.

Claims

1. A cloud mobile phone monitoring method, comprising: Receiving a registration request sent by a cloud mobile phone node at startup, where the registration request includes node information; Registering the cloud mobile phone node based on the registration request; Receiving the operating status regularly reported by the cloud mobile phone node using a private protocol; Monitoring the cloud mobile phone node based on the operating status.

2. The method according to claim 1, wherein The node information includes an identifier and an operating status, and the operating status includes at least one of the following: online or offline status, central processing unit (CPU) or graphics processing unit (GPU) occupancy rate, memory usage, network status, and number of active sessions.

3. The method according to claim 1, wherein, The private protocol is divided into a three-layer structure, including a message header layer, a message body layer, and an additional control layer. The message header layer is used to identify at least one of message type, version, length, and checksum. The message body layer contains service data or instruction content. The additional control layer is used to extend fields, security signatures, and timestamps, etc.

4. The method according to claim 1, wherein The fields of the private protocol include at least one of the following: protocol identifier, protocol version number, message type, message body length, session identifier, control flag bit, checksum field, message body.

5. The method according to claim 1, wherein The connection method of the private protocol includes Transmission Control Protocol (TCP) connection and / or User Datagram Protocol (UDP) connection; the message sending and receiving methods of the private protocol include at least one of the following: each message carries a session identifier, maintaining communication using heartbeat packets in the long connection state, using an Acknowledgment (ACK) mechanism and a retransmission strategy; the compression and throttling methods of the private protocol include at least one of the following: large data packets are compressed using GZIP before transmission, using a sliding window to control the bandwidth peak, dynamically adjusting the heartbeat or reporting period.

6. The method according to claim 1, wherein Before receiving the registration request sent by the cloud mobile phone node at startup, it further includes: Receiving a connection request sent by the cloud mobile phone node at startup, where the connection request includes the information of the cloud mobile phone node; Performing session verification based on the information of the cloud mobile phone node; In response to passing the session verification, establishing a session connection with the cloud mobile phone node and allocating a session identifier.

7. The method according to claim 6, wherein The establishing of the session connection with the cloud mobile phone node includes: Determining a connection type based on the network type of the cloud mobile phone node, where the connection type is a TCP connection or a UDP connection; Establishing a session connection with the cloud mobile phone node based on the connection type.

8. The method according to claim 6, wherein, After establishing the session connection with the cloud mobile phone node, it further includes: Receiving the heartbeat packets periodically sent by the cloud mobile phone node; In response to not receiving the heartbeat packets sent by the cloud mobile phone node for a preset number of consecutive times, re-establishing a session connection with the cloud mobile phone node.

9. The method according to claim 1, wherein The receiving of the operating status regularly reported by the cloud mobile phone node using a private protocol includes: Receiving the compressed binary data stream transmitted by the cloud mobile phone node through a socket network, where the cloud mobile phone node encapsulates the operating status into the message body of the private protocol, encapsulates the message body into a binary data stream, and performs data compression on the binary data stream through a variable buffer protocol to obtain the compressed binary data stream.

10. The method according to claim 1, wherein Monitoring the cloud phone node based on the operating state includes: In response to determining that the cloud phone node fails based on the operating state, automatically restarting the cloud phone node.

11. The method according to claim 1, wherein, Monitoring the cloud phone node based on the operating state includes: In response to determining that the cloud phone node fails based on the operating state, performing scheduling adjustment on the cloud phone node.

12. The method according to claim 11, wherein, The performing scheduling adjustment on the cloud phone node in response to determining that the cloud phone node fails based on the operating state includes: Based on the operating state, determining the load condition of the cloud phone node; In response to determining that the resource utilization rate of the cloud phone node is higher than a preset resource utilization rate threshold based on the load condition, allocating at least part of the load of the cloud phone node to other cloud phone nodes.

13. The method according to claim 11, wherein, The performing scheduling adjustment on the cloud phone node in response to determining that the cloud phone node fails based on the operating state includes: Based on the operating state, determining the network condition of the cloud phone node; In response to determining that the network of the cloud phone node is abnormal based on the network condition, reconnecting to other cloud phone nodes.

14. The method according to claim 11, wherein, The performing scheduling adjustment on the cloud phone node in response to determining that the cloud phone node fails based on the operating state includes: Based on the operating state, determining the performance condition of the cloud phone node; In response to determining that the performance of the cloud phone decreases based on the performance condition, performing image quality adaptation on the cloud phone node.

15. A cloud phone monitoring device includes: A first receiving module configured to receive a registration request sent by a cloud phone node during startup, where the registration request includes node information; A registration module configured to register the cloud phone node based on the registration request; A second receiving module configured to receive the operating state regularly reported by the cloud phone node using a private protocol; A monitoring module configured to monitor the cloud phone node based on the operating state.

16. An electronic device includes: At least one processor; And A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the method according to any one of claims 1-14.

17. A non-transitory computer-readable storage medium storing computer instructions for causing a computer to execute the method according to any one of claims 1-14.

18. A computer program product includes a computer program which, when executed by a processor, implements the method according to any one of claims 1-14.

Citation Information

Patent Citations

  • Cloud mobile phone fault monitoring method and system

    CN110149653A

  • Cloud mobile phone monitoring system and method

    CN111143170A

  • Basic deployment service fault monitoring processing method and system of cloud mobile phone

    CN114884930A

  • Cloud mobile phone system, cloud mobile phone creating method and cloud mobile phone resource scheduling method

    CN116192854A

  • Cloud mobile phone group control grading limiting method

    CN117938919A