Remote debugging method and device
By managing a port pool to dynamically allocate and reuse public network ports, the problems of low resource utilization and poor security in remote debugging are solved, thus improving debugging efficiency and security. This approach is suitable for remote debugging scenarios involving a large number of devices.
Patent Information
- Application Number
- CN202511784451.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-01
- Publication Date
- 2026-03-03
AI Technical Summary
In existing remote debugging solutions, devices occupy public network ports, resulting in low resource utilization. Especially when the number of devices is large, there is a risk of port resource exhaustion. In addition, the configuration is complex, the security is poor, and dynamic management and reuse are not possible.
By managing the port pool, dynamic allocation and reuse of public network ports can be achieved. This includes responding to debugging requests to identify target devices, allocating ports, establishing debugging channels, and releasing ports under certain conditions. Combined with device registration, encrypted channels, and user authentication, security and resource utilization are ensured.
It improves the efficiency and security of remote debugging, realizes dynamic management and reuse of ports, solves the problems of resource waste and complex configuration, and is suitable for remote debugging scenarios with a large number of devices.
Smart Images
Figure CN121597548A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of remote control technology, and in particular to remote debugging methods and devices. Background Technology
[0002] Remote debugging is a crucial technology in software development and testing. It allows developers to debug code deployed on remote servers from their local environment, thereby effectively locating and resolving problems.
[0003] However, existing remote debugging solutions typically rely on fixed public network ports. This means each device must occupy a dedicated public network port. Such solutions lead to low resource utilization, especially when dealing with a large number of devices, frequently facing the risk of port exhaustion. Summary of the Invention
[0004] To address or partially address the problems existing in related technologies, this application provides a remote debugging method and apparatus. This solution enables remote debugging and, during the remote debugging process, manages public network ports in the port pool, thereby achieving dynamic allocation and reuse of ports, which in turn helps improve debugging efficiency.
[0005] The first aspect of this application provides a remote debugging method, comprising: in response to receiving a debugging request from a client, determining a target remote device based on the debugging request, and sending the debugging request to the target remote device; in response to receiving a port request from the target remote device, determining a target port from a port pool based on the port request, and sending allocation proposal information matching the target port to the target remote device; in response to receiving port confirmation information from the target remote device, establishing a debugging channel between the target port and the target remote device, and conducting a remote debugging session for the target remote device; and, if it is determined that the target triggering condition is met, releasing the target port and updating the port pool.
[0006] In some embodiments, before responding to receiving a debugging request from a client, determining the target remote device based on the debugging request, and sending the debugging request to the target remote device, the method further includes: responding to receiving registration information from the remote device, storing the registration information, and obtaining stored data; wherein the registration information includes device identifier and device capability description information.
[0007] In some embodiments, the port request includes the device identifier of the target remote device; determining the target port from the port pool according to the port request and sending allocation proposal information matching the target port to the target remote device includes: matching the stored registration information with the device identifier of the target remote device to obtain storage data corresponding to the target remote device; determining allocation proposal information according to the storage data corresponding to the target remote device, the allocation proposal information including the port lease time and heartbeat detection cycle.
[0008] In some embodiments, the target triggering condition is met, including at least one of the following: the remote debugging session for the target remote device is detected to have ended; the remote debugging session times out based on the port lease time.
[0009] In some embodiments, the method further includes: after receiving port confirmation information from the target remote device, allocating a session identifier for the target port in a port pool, the session identifier being used to track the remote debugging connection status.
[0010] In some embodiments, the method further includes: establishing an encrypted channel and performing communication data encryption, wherein the encrypted channel includes: a first encrypted channel between the client and the server, and / or, a second encrypted channel between any remote device and the server.
[0011] In some embodiments, the method further includes: performing user authentication on the debug request to determine whether the debug request was initiated by an authorized user.
[0012] A second aspect of this application provides a remote debugging device, comprising: a first processing module, configured to, in response to receiving a debugging request from a client, determine a target remote device based on the debugging request and send the debugging request to the target remote device; a second processing module, configured to, in response to receiving a port request from the target remote device, determine a target port from a port pool based on the port request and send allocation proposal information matching the target port to the target remote device; a third processing module, configured to, in response to receiving port confirmation information from the target remote device, establish a debugging channel between the target port and the target remote device and conduct a remote debugging session for the target remote device; and a fourth processing module, configured to, upon determining that a target triggering condition is met, release the target port and update the port pool.
[0013] A third aspect of this application provides an electronic device, comprising: Processor; and A memory that stores executable code, which, when executed by the processor, causes the processor to perform the method described above.
[0014] A fourth aspect of this application provides a computer-readable storage medium having executable code stored thereon, which, when executed by a processor of an electronic device, causes the processor to perform the method described above.
[0015] The technical solution provided in this application, in response to receiving a debugging request from a client, determines the target remote device based on the debugging request and sends the debugging request to the target remote device; in response to receiving a port request from the target remote device, determines the target port from the port pool based on the port request and sends allocation proposal information matching the target port to the target remote device; in response to receiving port confirmation information from the target remote device, establishes a debugging channel between the target port and the target remote device and initiates a remote debugging session for the target remote device; and, if the target triggering conditions are met, releases the target port and updates the port pool. This can include the following beneficial effects: enabling remote debugging, and during remote debugging, managing public network ports in the port pool, thereby achieving dynamic port allocation and reuse, and thus improving debugging efficiency.
[0016] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description
[0017] The above and other objects, features and advantages of this application will become more apparent from the more detailed description of exemplary embodiments thereof in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments thereof.
[0018] Figure 1 This is a flowchart illustrating the remote debugging method shown in the embodiments of this application; Figure 2 This is a schematic diagram of the structure of the remote debugging device shown in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application. Detailed Implementation
[0019] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to make this application more thorough and complete, and to fully convey the scope of this application to those skilled in the art.
[0020] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.
[0021] It should be understood that although the terms "first," "second," "third," etc., may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.
[0022] Remote debugging of embedded devices is typically achieved using a fixed public network port. Each device is pre-assigned a public network port number during deployment and connects to a remote debugging server via NAT (Network Address Translation) or port forwarding. Developers use local debugging tools to access the device through this port for remote debugging. However, this approach has several drawbacks: Firstly, it wastes port resources, as each device must occupy a fixed public network port, leading to low resource utilization, especially with a large number of devices, which risks port exhaustion. Secondly, the configuration is complex and static, with ports bound to each device, preventing dynamic changes or reuse and resulting in high deployment and maintenance costs. Thirdly, the debugging channel lacks security control and dynamic management, with ports exposed to the public network for extended periods, posing security risks and making unified monitoring and reclaiming impossible.
[0023] To address the aforementioned issues, this application provides a remote debugging method. Upon receiving a debugging request from a client, the method determines the target remote device based on the request and sends the debugging request to the target remote device. Upon receiving a port request from the target remote device, the method determines the target port from the port pool based on the port request and sends allocation proposal information matching the target port to the target remote device. Upon receiving port confirmation information from the target remote device, the method establishes a debugging channel between the target port and the target remote device and initiates a remote debugging session for the target remote device. If the target triggering conditions are met, the method releases the target port and updates the port pool. This solution enables remote debugging and manages public network ports in the port pool during the remote debugging process, thereby achieving dynamic port allocation and reuse, which improves debugging efficiency.
[0024] The technical solutions of the embodiments of this application are described in detail below with reference to the accompanying drawings.
[0025] Figure 1 This is a flowchart illustrating the remote debugging method shown in the embodiments of this application.
[0026] See Figure 1 A remote debugging method, the method comprising: Step 101: In response to receiving a debug request from the client, determine the target remote device based on the debug request, and send the debug request to the target remote device.
[0027] Step 102: In response to receiving a port request from the target remote device, determine the target port from the port pool according to the port request, and send allocation proposal information matching the target port to the target remote device.
[0028] Step 103: In response to receiving port confirmation information from the target remote device, establish a debugging channel between the target port and the target remote device, and conduct a remote debugging session for the target remote device.
[0029] Step 104: If the target triggering conditions are met, release the target port and update the port pool.
[0030] The remote debugging method in this embodiment can be applied to servers. Application scenarios can include systems involving servers, remote devices, and clients.
[0031] Users can initiate debugging requests to the server through the client's debugging platform. For example, by selecting a device (i.e., the target remote device) through the debugging platform, the platform sends a debugging request to the management server via a REST API; the REST API is a REST-style HTTP interface. The server then forwards this debugging request to the target remote device.
[0032] In some embodiments, before responding to receiving a debugging request from a client, determining the target remote device based on the debugging request, and sending the debugging request to the target remote device, the remote debugging method further includes: responding to receiving registration information from the remote device, storing the registration information, and obtaining stored data; wherein the registration information includes device identifier and device capability description information.
[0033] For example, a server may include a device registration module. A remote device actively connects to the server to register the device.
[0034] For example, after an embedded device is powered on or started, it actively connects to a remote debug management server, establishes a control channel, and uploads device identification information. For instance, after an embedded device starts up, it uses an MQTT control channel to connect to the management server and periodically sends heartbeats.
[0035] In some embodiments, in addition to the device's unique identifier (i.e., device identification information, such as device ID, MAC address, SN number), the device registration information may also include device capability description information, such as supported debugging protocol types (e.g., GDB, JTAG, remote shell, etc.), the currently running firmware version, network performance characteristics (e.g., bandwidth, latency evaluation results, etc.).
[0036] It should be noted that the capability description information can be used by the remote debugging and management server to perform policy matching during the scheduling phase, including selecting the appropriate communication tunnel type (such as prioritizing the QUIC protocol in a high-latency network environment), allocating public network port resources with bandwidth guarantee or latency tolerance characteristics, and setting the appropriate port lease time and heartbeat detection cycle accordingly, thereby achieving dynamic policy adaptation and service quality assurance.
[0037] It is understandable that after the target remote device receives the debugging request, it requests the server to allocate a public network debugging port. As a result, the server receives the port request from the target remote device and dynamically allocates an available port from the port pool.
[0038] It is understandable that the server can maintain a port pool structure, as shown in Table 1.
[0039] Table 1
[0040] In some embodiments, the server maintains a port pool with a maximum concurrency limit. When port resources are nearing exhaustion, the system can perform scheduling based on a multi-dimensional priority strategy, including rejecting new session requests or forcibly releasing port resources that have been inactive for a long time, to ensure the timely processing of high-priority debugging requests.
[0041] For example, in scenarios where port resources are scarce, the system can prioritize debugging sessions for "advanced debugging users" or "emergency fault handling devices" and queue or delay responses to low-priority background diagnostic tasks to achieve flexible resource scheduling strategies and business awareness.
[0042] For example, a target remote device sends a Port Discover message requesting a public network debugging port, i.e., a port request. The server selects an available port from the port pool to determine the target port and returns a Port Offer message, i.e., sending allocation proposal information matching the target port to the target remote device.
[0043] The target remote device confirms whether it accepts the target port. If yes, it sends a Port Request to the server. The server then establishes a debugging channel between the port and the device, and notifies the target remote device that debugging is ready by replying with a Port ACK. Debugging tools can then access the target remote device's debugging services through the target port, such as notifying clients and initiating remote debugging sessions for the target device.
[0044] For example, based on WebSocket, QUIC, or reverse TCP tunneling technology, a reverse tunnel can be established between the device and the server, completing public network port binding and obtaining a bidirectional communication channel (control channel + debug channel), allowing debug data to be forwarded through temporary ports. Reverse TCP tunneling technology can be used to establish a debug communication link between the public network and the device, supporting NAT traversal. Reverse TCP tunneling technology can be used in the communication framework for remote debugging devices.
[0045] Furthermore, regarding the release of ports in use, the target port can be released and the port pool updated if the target triggering conditions are met.
[0046] In some embodiments, the target triggering condition is met, including at least one of the following: the remote debugging session for the target remote device is detected to have ended; the remote debugging session times out based on the port lease time.
[0047] It is understandable that after debugging is completed (i.e., the remote debugging session ends), the remote device or server can actively initiate a release operation or, after a timeout, the server will reclaim the port and update the port pool, thereby releasing the port resources for other devices to reuse.
[0048] The remote debugging method of this embodiment can realize remote debugging through the above communication protocol. During the remote debugging process, it manages the public network ports in the port pool, thereby realizing the dynamic allocation and reuse of ports, overcoming the problems of fixed ports, resource waste and complex configuration, and thus improving debugging efficiency. That is, it realizes the efficient, dynamic, controllable and secure reuse of resources for remote debugging of embedded devices, and improves the debugging efficiency and scalability of the system.
[0049] In some embodiments, the port request includes the device identifier of the target remote device; determining the target port from the port pool according to the port request and sending allocation proposal information matching the target port to the target remote device includes: matching the stored registration information with the device identifier of the target remote device to obtain storage data corresponding to the target remote device; determining allocation proposal information according to the storage data corresponding to the target remote device, the allocation proposal information including the port lease time and heartbeat detection cycle.
[0050] It is understandable that the port request includes the device identifier of the target remote device, which can be a unique device identifier.
[0051] Since the server stores data including device identifiers and device capability descriptions, when determining the target port, a suitable target port can be selected for matching, and appropriate allocation proposal information can be set.
[0052] For example, a device sends a port allocation request to the management server via a control channel, including the device's unique ID, local debugging port, and protocol type. The server selects a port P from the available port pool and returns an allocation proposal, which may include information such as the session ID and port validity period.
[0053] In some embodiments, after receiving port confirmation information from the target remote device, a session identifier can be assigned to the target port in the port pool. The session identifier is used to track the remote debugging connection status.
[0054] It is understandable that each dynamic port is assigned a unique Session ID, which can be used to identify and track the connection status during debugging.
[0055] It is understandable that designing a port pool resource management model that supports concurrent debugging, combined with a session ID binding mechanism, can improve resource reuse and debugging stability.
[0056] In some embodiments, the server can clean up expired ports every N seconds, and unacknowledged offers will be automatically reclaimed. That is, the target remote device confirms whether it accepts the target port, and if not, it is reclaimed.
[0057] In some embodiments, the remote debugging method further includes: establishing an encrypted channel and performing communication data encryption, wherein the encrypted channel includes: a first encrypted channel between the client and the server, and / or, a second encrypted channel between any remote device and the server.
[0058] It is understandable that by establishing encrypted channels and encrypting communication data, the entire communication process can be conducted in encryption, such as through a TLS encrypted channel, to ensure the security of data transmission and resistance to man-in-the-middle attacks.
[0059] In some embodiments, the remote debugging method further includes: performing user authentication on the debugging request to determine whether the debugging request was initiated by an authorized user.
[0060] It is understood that this embodiment supports an identity authentication mechanism based on a token or digital certificate, which can ensure that debugging operations are initiated by authorized users.
[0061] In some embodiments, the remote debugging method further includes a port renewal mechanism for automatically extending the lease of long-term debugging sessions, while also having an abnormal disconnection detection and recycling mechanism to ensure timely release of resources.
[0062] It is understood that this embodiment integrates TLS encryption, two-way authentication, token mechanism, and session renewal and timeout recovery strategies at the protocol layer to ensure the debugging process is safe and reliable.
[0063] To better understand the dynamic port allocation process of the present invention, the following embodiments further illustrate the content of the present invention, but the present invention is not limited to the following embodiments.
[0064] S1, Port Discover The device sends a port allocation request to the management server via the control channel, which includes the device's unique ID, local debugging port, protocol type, etc.
[0065] S2, Port Offer The server selects a port P from the available port pool and returns an allocation proposal, which includes the session ID, port validity period, etc.
[0066] S3, Port Request The device acknowledges acceptance via port P and sends a request confirmation message.
[0067] S4, Port Ack (Port Confirmation) S5. The server records the binding relationship, establishes a debugging channel between the port and the device, and notifies the device that debugging is ready.
[0068] The device requests a public network debugging port from the management server via the control channel and establishes a dynamic mapping relationship.
[0069] S6, Port Release After debugging is complete, the device or server can initiate a release operation, and the server will reclaim the port.
[0070] This embodiment provides a port allocation communication protocol based on Discover→Offer→Request→Ack→Release for remote debugging of embedded devices. It borrows the allocation mechanism of the DHCP protocol and constructs a standardized and scalable debugging port management process, thereby achieving dynamic management of the entire Discover, Offer, Request, Ack, and Release process for remote debugging ports.
[0071] The working principle of the DHCP protocol includes protocol understanding, message format, message types, and working process. Using Wireshark to capture DHCP packets, we can analyze the four stages of dynamically obtaining an IP address: discovery, offer, selection, and acknowledgment.
[0072] This embodiment supports dynamic online debugging of a large number of embedded devices without the need for pre-configured ports, and has automated scheduling and elasticity capabilities.
[0073] This embodiment can also introduce mechanisms such as TLS security authentication, reverse communication tunnel, session renewal and timeout recycling, which can significantly improve system resource utilization and debugging and deployment efficiency while ensuring security. It is suitable for port multiplexing and scheduling in remote debugging environments of embedded devices behind NAT / firewall.
[0074] This embodiment can be used in a wide range of embedded system platforms, and has broad application prospects and industrial value, especially in industrial control, smart terminal, and Internet of Things device scenarios with large-scale device deployment, sensitive operation and maintenance costs, and complex remote connection.
[0075] Corresponding to the aforementioned application function implementation method embodiments, this application also provides a remote debugging device, an electronic device, and corresponding embodiments.
[0076] Figure 2 This is a schematic diagram of the structure of the remote debugging device shown in the embodiments of this application.
[0077] See Figure 2 The remote debugging 200 in this embodiment includes a first processing module 210, a second processing module 220, a third processing module 230 and a fourth processing module 240.
[0078] The first processing module 210 is used to respond to receiving a debugging request from the client, determine the target remote device based on the debugging request, and send the debugging request to the target remote device.
[0079] The second processing module 220 is used to respond to receiving a port request from a target remote device, determine a target port from the port pool according to the port request, and send allocation proposal information matching the target port to the target remote device.
[0080] The third processing module 230 is used to establish a debugging channel between the target port and the target remote device in response to receiving port confirmation information from the target remote device, and to conduct a remote debugging session for the target remote device.
[0081] The fourth processing module 240 is used to release the target port and update the port pool when the target triggering conditions are met.
[0082] According to embodiments of this application, any plurality of modules among the first processing module 210, the second processing module 220, the third processing module 230, and the fourth processing module 240 may be combined into one module, or any one of these modules may be split into multiple modules. Alternatively, at least a portion of the functionality of one or more of these modules may be combined with at least a portion of the functionality of other modules and implemented in one module. According to embodiments of this disclosure, at least one of the first processing module 210, the second processing module 220, the third processing module 230, and the fourth processing module 240 may be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in any one of the three implementation methods of software, hardware, and firmware, or in a suitable combination of any of these. Alternatively, at least one of the first processing module 210, the second processing module 220, the third processing module 230, and the fourth processing module 240 may be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.
[0083] Figure 3 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application.
[0084] See Figure 3 The electronic device 300 includes a memory 310 and a processor 320.
[0085] The processor 320 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.
[0086] Memory 310 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage devices. ROM may store static data or instructions required by processor 320 or other modules of the computer. Permanent storage devices may be read-write storage devices. Permanent storage devices may be non-volatile storage devices that retain stored instructions and data even when the computer is powered off. In some embodiments, permanent storage devices use mass storage devices (e.g., magnetic or optical disks, flash memory) as permanent storage devices. In other embodiments, permanent storage devices may be removable storage devices (e.g., floppy disks, optical drives). System memory may be a read-write storage device or a volatile read-write storage device, such as dynamic random access memory. System memory may store some or all of the instructions and data required by the processor during operation. Furthermore, memory 310 may include any combination of computer-readable storage media, including various types of semiconductor memory chips (e.g., DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), and disks and / or optical disks may also be used. In some embodiments, memory 310 may include a removable storage device that is readable and / or writable, such as a laser disc (CD), a read-only digital multifunction optical disc (e.g., DVD-ROM, dual-layer DVD-ROM), a read-only Blu-ray disc, an ultra-high density optical disc, a flash memory card (e.g., SD card, mini SD card, Micro-SD card, etc.), a magnetic floppy disk, etc. Computer-readable storage media do not contain carrier waves or transient electronic signals transmitted wirelessly or via wired connections.
[0087] The memory 310 stores executable code, which, when processed by the processor 320, can cause the processor 320 to execute part or all of the methods described above.
[0088] Furthermore, the method according to this application can also be implemented as a computer program or computer program product, which includes computer program code instructions for performing some or all of the steps in the method described above.
[0089] Alternatively, this application may be implemented as a computer-readable storage medium (or a non-transitory machine-readable storage medium or a machine-readable storage medium) storing executable code (or computer program or computer instruction code) thereon, which, when executed by a processor of an electronic device (or server, etc.), causes the processor to perform part or all of the steps of the methods described above according to this application.
[0090] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.
Claims
1. A remote debugging method, characterized in that, include: In response to receiving a debug request from a client, the system determines the target remote device based on the debug request and sends the debug request to the target remote device. In response to receiving a port request from the target remote device, a target port is determined from the port pool according to the port request, and allocation proposal information matching the target port is sent to the target remote device; In response to receiving port confirmation information from the target remote device, a debugging channel is established between the target port and the target remote device, and a remote debugging session is initiated for the target remote device; If the target triggering conditions are met, the target port is released and the port pool is updated.
2. The method according to claim 1, characterized in that, Before responding to receiving a debug request from a client, determining the target remote device based on the debug request, and sending the debug request to the target remote device, the method further includes: In response to receiving registration information from a remote device, the registration information is stored to obtain stored data; wherein, the registration information includes device identifier and device capability description information.
3. The method according to claim 2, characterized in that, The port request includes the device identifier of the target remote device; determining the target port from the port pool based on the port request, and sending allocation proposal information matching the target port to the target remote device, includes: By matching the device identifier of the target remote device with the stored registration information, the stored data corresponding to the target remote device can be obtained; The allocation proposal information is determined based on the storage data corresponding to the target remote device, and the allocation proposal information includes the port lease time and heartbeat detection cycle.
4. The method according to claim 1 or 3, characterized in that, The target trigger condition must be met, including at least one of the following: The remote debugging session for the target remote device was detected to have ended; Based on the port lease time, a remote debugging session timeout was detected.
5. The method according to claim 1, characterized in that, The method further includes: After receiving port confirmation information from the target remote device, a session identifier is assigned to the target port in the port pool. The session identifier is used to track the remote debugging connection status.
6. The method according to claim 1, characterized in that, The method further includes: Establish an encrypted channel and perform encryption of communication data, wherein the encrypted channel includes: a first encrypted channel between the client and the server, and / or a second encrypted channel between any remote device and the server.
7. The method according to claim 1, characterized in that, The method further includes: User authentication is performed on the debugging request to determine whether the debugging request was initiated by an authorized user.
8. A remote debugging device, characterized in that, include: The first processing module is configured to respond to receiving a debugging request from a client, determine the target remote device based on the debugging request, and send the debugging request to the target remote device; The second processing module is configured to, in response to receiving a port request from the target remote device, determine a target port from the port pool according to the port request, and send allocation proposal information matching the target port to the target remote device; The third processing module is used to establish a debugging channel between the target port and the target remote device in response to receiving port confirmation information from the target remote device, and to conduct a remote debugging session for the target remote device. The fourth processing module is used to release the target port and update the port pool when it is determined that the target triggering conditions are met.
9. An electronic device, characterized in that, include: processor; as well as A memory having executable code stored thereon, which, when executed by the processor, causes the processor to perform the method as described in any one of claims 1-7.
10. A computer-readable storage medium having executable code stored thereon, which, when executed by a processor of an electronic device, causes the processor to perform the method as described in any one of claims 1-7.