A DHCP-based node detection method, system, device and medium

Abstract

The application provides a DHCP-based node detection method, system, device and medium, and belongs to the technical field of cloud computing node automatic discovery management. The method comprises the following steps: after the server is started, the proxy end obtains an IP through DHCP and parses the address of the service end; the service end is actively detected to check whether the service exists; the service end responds and returns a registration address; the proxy end checks the validity of the response, and if the checking is successful, the address is persisted, and if the checking fails, the IP is released and the retry is performed; finally, the hardware information is collected and reported to complete node registration. The method realizes the discovery and registration of nodes, reduces the manual configuration cost and error rate, improves the adaptability and system reliability of the heterogeneous network environment through retry and address persistence, supports the active collection and reporting of hardware information, and provides accurate and real-time data for the system.

Description

Technical Field

[0001] This invention belongs to the field of management technology for automatic discovery of cloud computing nodes, specifically relating to a node detection method, system, device and medium based on DHCP. Background Technology

[0002] In large-scale distributed computing environments and data center infrastructures, the automated discovery and registration of nodes is a core technical aspect for achieving system scalability, high availability, and operational efficiency.

[0003] During the cloud platform setup process, the discovery function for a large number of deployed server nodes requires logging into the system or loading the ramdisk system via PXE. This necessitates logging into each server system individually to execute commands, resulting in a long processing time.

[0004] Furthermore, if the agent directly sends a registration request to the preset headquarters server address, and the branch center's network fluctuates, it will continuously send invalid requests, consuming the branch center's egress bandwidth. When obtaining the registration address, it is necessary to first send a server existence probe request, and then send a registration address retrieval request. If the network latency is 50ms in these two rounds of interaction, the total time consumed by 100 agents will increase, and any failure in any step requires re-initiation, resulting in low efficiency. If the branch center's network is interrupted and then restored, the agent may not release the IP address before the interruption, which may lead to IP conflicts. After restoration, the agent will still use the original IP address, making normal communication impossible. Summary of the Invention

[0005] This invention provides a DHCP-based node detection method. By designing server-side functions such as node registration management, DHCP service, and address query, and node agent-side functions such as active address detection, failure retry, hardware data collection, and node reporting, it achieves unified management of automatic node discovery in a large number of mixed systems.

[0006] The methods include:

[0007] S101: After the server boots up, it starts the agent on the node. The agent obtains the Internet Protocol address (IP) through dhclient and resolves it to the server IP address of the Host Configuration Protocol (HMAC).

[0008] S102: The agent accesses a preset network address containing the ServerIP to detect whether the host management service on the server exists;

[0009] S103: When the server receives a probe request from the proxy, it returns a response to the proxy. The message body of the response contains the address information used by the server for node registration.

[0010] S104: The agent determines whether the response is a preset success status and carries address information for node registration;

[0011] If so, the proxy will persistently save the address information used for node registration to the proxy's metadata file;

[0012] If not, the proxy releases the currently acquired IP and returns to step S101 to re-execute;

[0013] S105: After the detection is successful, the agent collects the host hardware information and reports the collected host hardware information to the address used for node registration in order to complete the registration of node information and realize node discovery.

[0014] Preferably, step S101 specifically includes the following steps:

[0015] After the agent starts, it collects at least two independent hardware feature information of the local machine, and associates and combines the hardware feature information to generate a unique node identifier;

[0016] The agent detects multi-segment information in the network environment, including the subnet mask, gateway address and historical connection records of each segment, and sets the segment priority for DHCP requests based on the information.

[0017] The agent sends a DHCP request via dhclient, the request carrying the unique node identifier and preset network segment priority information;

[0018] After receiving the IP allocation response from the DHCP server, the agent checks whether the network segment to which the IP belongs is in the preset list of abnormal network segments. If it is, the agent rejects the IP and sends a reassignment request to the DHCP server.

[0019] After the proxy confirms that it has received a legitimate IP address, it associates and stores the IP address with the unique node identifier and network environment parameters, and marks the timestamp of the IP address acquisition and the expected validity period in the stored information.

[0020] Preferably, step S103 specifically includes the following steps:

[0021] After receiving the probe request from the proxy, the server extracts the hardware feature information carried in the request, performs hash matching verification with the locally stored legitimate hardware feature library, and determines whether the request source is an authorized hardware node.

[0022] If the hardware feature verification is successful, the server generates a dynamic registration address based on the current timestamp, the server instance identifier, and a random number.

[0023] The server encapsulates the dynamically registered address, current timestamp, and temporary session identifier in the probe request into a response message body, hashes the message body using the server's private key, encrypts it to generate a digital signature, and appends it to the response message.

[0024] The server queries the local node information database based on the hardware feature code. If a historical registration record of the hardware exists, the historical configuration parameters are appended to the response message body; otherwise, the default configuration parameters are appended.

[0025] The server returns the encapsulated response message to the proxy using the original protocol type of the probe request. At the same time, it records the hardware characteristics, dynamic port, timestamp, response status, and digital signature verification results of this probe in the local audit log, forming a session trace.

[0026] Preferably, step S102 further includes the following steps:

[0027] After obtaining the ServerIP, the proxy verifies the ServerIP based on the format characteristics of the ServerIP and the pre-defined IP address range rules.

[0028] After the ServerIP passes verification, the proxy constructs a probe request packet containing preset identification information;

[0029] The proxy selects the appropriate network transmission protocol to send probe request packets based on the dynamic changes in the network environment.

[0030] After receiving the probe request packet sent by the proxy, the server verifies the specific identification information in the probe request packet;

[0031] The server parses and verifies the composite identifier in the probe request packet based on the pre-stored relationship between the server hardware identifier and the composite identifier generation rules; when the composite identifier is verified, the server continues to process the probe request and returns a response to the proxy.

[0032] After sending the probe request packet, the proxy starts a timer; the timer is dynamically adjusted according to the real-time network conditions.

[0033] The proxy calculates the waiting time based on the previously monitored network latency parameters. If the proxy receives a response from the server before the waiting timer expires, it processes the response normally. If no response is received after the waiting timer expires, the proxy reconstructs the probe request packet and sends it again.

[0034] Preferably, step S104 further includes the following steps:

[0035] The proxy parses the response message returned by the server, extracts the status code, address information and extended fields in the message body; and classifies the failure type into network timeout, server error, invalid address and forged response according to preset rules, and records them to the proxy's temporary log respectively.

[0036] Classify the failure types, adjust the retry policy parameters, and before releasing the current IP, the proxy will encrypt and cache the temporary state of this probe to local storage;

[0037] Before releasing the current IP, the proxy uses the server's public key to verify the digital signature of the response message. If the signature is invalid, it is determined to be a forged response, and the attack source IP is recorded in the security log. If the signature is valid but still fails, it is confirmed that the server actively rejected the request, and the server instance is marked as untrusted.

[0038] If the number of consecutive retries exceeds the preset maximum or the number of retries in a single day exceeds the limit, the agent will stop retries and generate a comprehensive alarm log. The alarm log will be uploaded to the server management platform, the current IP will be released and the temporary cache will be cleared. The process will then return to step S101 to obtain the IP again and start the probe.

[0039] Preferably, step S105 further includes the following steps:

[0040] The agent adjusts the triggering conditions for hardware information collection based on the hardware feature hashes recorded during the probing phase.

[0041] When collecting hardware information, a multi-source verification method is used for key hardware; the currently collected hardware information is compared with the historical configuration parameters recorded in the detection phase to generate an incremental change list;

[0042] The incremental change list is encrypted using the server's public key, and a temporary session identifier generated during the probing phase and the current timestamp are appended to generate a secure reporting packet. If the reporting fails, a retry protocol and retry interval are selected based on the failure type.

[0043] Preferably, after step S105, the method further includes: the agent establishing a periodic task, periodically sending heartbeats to the server and reporting host information; when the node hardware is reconfigured, the agent synchronously reporting the updated host information to the server.

[0044] This application also provides a DHCP-based node detection system, which includes: a startup module, a server, and an agent.

[0045] The startup module is used to start the agent of the node after the server is powered on. The agent obtains the Internet Protocol address (IP) through dhclient and resolves it to the server Internet Protocol address (ServerIP) of the Host Configuration Protocol.

[0046] The proxy is used to access a preset network address containing the ServerIP in order to detect whether the host management service on the server exists.

[0047] When the server receives a probe request from the proxy, it returns a response to the proxy. The message body of the response contains the address information used by the server for node registration.

[0048] The proxy determines whether the response is a preset success status and carries address information for node registration; if yes, the proxy persistently saves the address information for node registration to the proxy's metadata file; if no, the proxy releases the currently acquired IP and returns to step S101 to re-execute.

[0049] After the detection is successful, the agent collects the host hardware information and reports the collected host hardware information to the address used for node registration in order to complete the registration of node information and realize node discovery.

[0050] According to another embodiment of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the DHCP-based node detection method.

[0051] According to another embodiment of this application, a storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the DHCP-based node detection method.

[0052] As can be seen from the above technical solutions, the present invention has the following advantages:

[0053] The DHCP-based node detection method provided by this invention uses the dhclient tool to allocate IP addresses. The agent resolves the ServerIP from the DHCP response, eliminating the need for pre-setting the server address, adapting to multiple network topologies, and improving the versatility of the solution. The agent actively probes the server's host management service using a pre-set network address, avoiding sending invalid requests to unavailable servers; the probe request carries basic identifiers to help the server filter illegal requests in advance, reducing server resource consumption.

[0054] The server in this invention completes address transmission by carrying the registration address in the response message body, reducing the number of network communications. The proxy side ensures the security of the registration process through status codes and address format verification.

[0055] This invention improves the deployment efficiency of nodes in large-scale heterogeneous systems by using the DHCP protocol throughout the entire process of IP acquisition, server location, and registration interaction. Through designs such as detection and verification, anomaly retries, and data standardization, it enhances reliability and security, ensuring the stability of node management. Attached Figure Description

[0056] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the description will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0057] Figure 1 This is an architecture diagram of the node detection system;

[0058] Figure 2 The flowchart shows the node detection method based on DHCP.

[0059] Figure 3 A flowchart illustrating an embodiment of a DHCP-based node detection method;

[0060] Figure 4 This is a schematic diagram of an electronic device. Detailed Implementation

[0061] like Figure 1 As shown, this application addresses the issue of time-consuming methods for discovering server nodes in a large number of systems, such as logging into the system or loading the ramdisk system via PXE. By designing server-side functions such as server node registration management, DHCP service, and address query, and node agent-side functions such as active address detection, failure retry, hardware data collection, and node reporting, unified management of automatic node discovery for a large number of mixed systems is achieved.

[0062] It should be noted that in this application, the term "server" refers to the server itself, and the term "agent" refers to the node's proxy. The English and Chinese terms have the same meaning. After the pre-installed system's server is powered on, the agent enables the node to dynamically obtain an IP address based on the DHCP protocol. The agent determines the reporting address by probing the server's URL. If the probe fails, it attempts to release the current IP address and re-probe. The agent periodically checks hardware information and reports it to the server.

[0063] Specifically, by designing server-side functions such as node registration management, DHCP service, and address lookup, and node agent-side functions such as active probing, failure retry, hardware data collection, and node reporting, unified management of automatic node discovery for large-scale hybrid systems is achieved. After the pre-built system server is powered on, the Agent enables nodes to dynamically obtain IP addresses based on the DHCP protocol. The reporting address is determined by probing the server's URL. If the probing fails, the Agent attempts to release the current IP address and re-probe. The Agent periodically checks hardware information and reports it to the server. This method enables the management of node discovery and detection in scenarios with large-scale server deployments, eliminating the need for manual system login and improving the level of automated machine configuration management.

[0064] The DHCP-based node detection method of this application will be described in detail below. Specific details such as particular system architectures and technologies are presented for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details.

[0065] It should be understood that, when used in this specification, the term "comprising" indicates the presence of the described feature, integral, step, operation, element, and / or component, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0066] The terms "one embodiment" or "some embodiments" used in this application mean that one or more embodiments of this application include the specific features, structures, or characteristics described in that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this application do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized.

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

[0068] Please see Figure 2 The diagram shows a flowchart of a DHCP-based node detection method in a specific embodiment. The method includes:

[0069] After the S101 server boots up, it starts the node's agent. The agent obtains the Internet Protocol address (IP) through dhclient and resolves it to the ServerIP address of the Host Configuration Protocol.

[0070] In some embodiments, after the server is powered on and completes a self-test, it starts the pre-installed operating system. When the operating system initializes the network module, it triggers the startup program of the node agent.

[0071] After the Agent starts, it calls the system's underlying dhclient tool to send an IP address request message to the DHCP server in the network. This message contains the hardware identifier of the server where the Agent is located, which can be the MAC address of the network card.

[0072] After receiving a request, the DHCP server allocates an unused IP address from its pre-defined IP address pool. Simultaneously, it includes its own Internet Protocol address (IP address), known as the ServerIP, in the response message. Upon receiving the DHCP server's response message, the Agent parses the message fields, extracts the IP address assigned to it for subsequent network communication, and extracts the ServerIP to locate the server's host management services.

[0073] It can be seen that the address allocation mechanism based on the DHCP protocol uses the dhclient tool to achieve automatic acquisition of IP addresses, avoiding inefficiency and errors caused by configuring IP addresses; by carrying the ServerIP in the DHCP response message, the Agent does not need to store the server address in advance, realizing dynamic awareness of the server address and adapting to changes in the server deployment location under different network environments.

[0074] In some specific embodiments, step S101 specifically includes the following steps:

[0075] S1011: After the agent starts, it collects at least two independent hardware feature information of the local machine, and associates and combines the hardware feature information to generate a unique node identifier.

[0076] In this embodiment, after the agent starts up, it prioritizes collecting the motherboard's unique serial number and the MAC address of at least one physical network card as independent hardware features. The two are combined into a unique node identifier in string form by character concatenation, so that the DHCP server can distinguish different nodes through this identifier and avoid the same node being repeatedly identified as a new node due to restarts or other reasons.

[0077] S1012: The agent detects the multi-segment information in the network environment, including the subnet mask, gateway address and historical connection records of each segment, and sets the segment priority of the DHCP request based on the information.

[0078] It should be noted that the proxy obtains information on multiple network segments that can be accessed by reading the local network configuration file and sending ARP broadcasts to probe surrounding devices; historical connection records include the duration of the three successful connections to each network segment in the past and the stability of data transmission.

[0079] S1013: The agent sends a DHCP request through dhclient, the request carrying the unique node identifier and preset network segment priority information.

[0080] This allows the DHCP server to combine node identifiers to confirm whether a node is a known node when assigning IP addresses, and to prioritize assigning IP addresses to it from high-priority network segments, thereby improving the targeting of IP address allocation.

[0081] S1014: After receiving the IP allocation response from the DHCP server, the agent checks whether the network segment to which the IP belongs is in the preset abnormal network segment list. If it is, the agent rejects the IP and sends a reassignment request to the DHCP server.

[0082] In this embodiment, the abnormal network segment determination is to convert the network segment to which the IP belongs into a range consisting of a start IP and an end IP. If this range intersects with any range in the abnormal network segment list, it is determined to be an abnormal IP.

[0083] In this embodiment, the proxy terminal pre-stores a list of abnormal network segments configured by the administrator. This list may include network segments with historical IP conflicts, network segments with bandwidth below a preset threshold, etc. Upon receiving an IP address, it resolves its network segment address and compares it against the list one by one. If a match is found, it is determined to be abnormal, and the IP is rejected by sending a DHCPDECLINE message. A new request is then initiated, including the exclusion of abnormal network segments. The working principle is to proactively filter IPs that may cause communication abnormalities, preventing nodes from being unable to complete subsequent probing due to IP issues.

[0084] S1015: After the agent confirms that it has received a legitimate IP, it associates and stores the IP with the unique node identifier and network environment parameters, and marks the timestamp of the IP acquisition and the expected validity period in the stored information.

[0085] In this embodiment, the proxy writes information such as IP address, unique node identifier, network segment priority, and gateway address into a local encrypted configuration file. It also records the precise time of IP acquisition and calculates the expected validity period based on the lease time returned by the DHCP server.

[0086] S102: The agent accesses a preset network address containing the ServerIP to detect whether the host management service on the server exists.

[0087] In some embodiments, after obtaining the ServerIP, the Agent constructs a complete probe address according to a preset network address format. The Agent sends a network request to the probe address, carrying basic identification information of the server where the Agent resides, which may be the previously obtained IP address and network card MAC address.

[0088] In this embodiment, after sending a request, the Agent starts a timer to wait for a response from the server while simultaneously monitoring the network connection status. If a network interruption occurs, the request is resent. If the server's host management service is running normally, it will receive and process the probe request, returning a response containing the service status to the Agent. If the server is not running or the network is unreachable, the Agent will detect a request timeout or connection failure, determining that the server's host management service is temporarily unavailable. By utilizing the basic identification information carried in the network request, the server can initially identify the source of the probe, avoiding interference from unauthorized requests. By monitoring response timeouts through a timer, the Agent is ensured not to wait indefinitely, improving process efficiency.

[0089] S103: When the server receives a probe request from the proxy, it returns a response to the proxy. The message body of the response contains the address information used by the server for node registration.

[0090] In some embodiments, the server-side host management service continuously listens to a preset network port. When it receives a probe request from an Agent, it first verifies the basic identification information carried in the request to exclude illegal requests. After successful verification, the server reads the address information used for node registration from its local configuration. This address is the interface address that the server specifically uses to receive node registration information. Subsequently, the server constructs a response message body, embedding the registration address information within it, and sets the response status code to a preset success status. Finally, the server sends the response message to the Agent that initiated the probe request to ensure that the Agent can obtain the accurate registration address.

[0091] In some specific embodiments, step S103 specifically includes the following steps:

[0092] S1031: After receiving the probe request from the proxy, the server extracts the hardware feature information carried in the request, performs hash matching verification with the locally stored legitimate hardware feature library, and determines whether the request source is an authorized hardware node.

[0093] In this embodiment, by extracting the hardware features embedded in the proxy and comparing them with the legitimate hardware library pre-stored on the server, only nodes with matching hashes are allowed to continue the process. The encrypted embedding of hardware features and the hash comparison mechanism block probe requests from illegitimate nodes.

[0094] S1032: If the hardware feature verification is successful, the server generates a dynamic registration address based on the current timestamp, the server instance identifier, and a random number. The dynamic port is a random port that is not occupied by other services and is selected from the preset range of available ports.

[0095] S1033: The server encapsulates the dynamic registration address, current timestamp, and temporary session identifier in the probe request into a response message body, hashes the message body using the server's private key, encrypts it to generate a digital signature, and appends it to the response message.

[0096] S1034: The server queries the local node information database based on the hardware feature code. If a historical registration record for the hardware exists, the historical configuration parameters are appended to the response message body; otherwise, the default configuration parameters are appended.

[0097] In this embodiment, the local node information database is queried through hardware feature encoding. If a historical record exists, the most recent configuration parameters are appended, and the agent only needs to report the changed parts. This reduces the amount of data transmission, allowing for a full report initially and subsequent reports only of incremental changes, thus improving system efficiency.

[0098] S1035: The server returns the encapsulated response message to the agent using the original protocol type of the probe request. At the same time, it records the hardware characteristics, dynamic port, timestamp, response status, and digital signature verification results of this probe in the local audit log, forming a complete session trace.

[0099] This embodiment records hardware characteristics, dynamic ports, timestamps, response status, and digital signature verification results in the log. When analyzing the log, nodes can be quickly located through hardware characteristics, communication records can be associated through dynamic ports, and timing issues can be investigated through timestamps, thus improving troubleshooting efficiency.

[0100] S104: The agent determines whether the response is a preset success status and carries address information for node registration;

[0101] If so, the proxy will persistently save the address information used for node registration to the proxy's metadata file;

[0102] If not, the proxy releases the currently acquired IP and returns to step S101 to re-execute;

[0103] In some embodiments, after receiving the response from the server, the Agent first checks whether the response status code is a preset success status code. If the status code is not a success status code, the response is directly determined to be invalid. If the status code meets the requirements, the Agent parses the response message body, checks whether it contains address information for node registration, and verifies whether the format of the registration address is valid.

[0104] Optionally, the complete protocol header, IP address, and port number may or may not be included. If the response is a default success status and the registration address is valid, the Agent opens the local metadata file, writes the registration address information into the specified field of the file, and records the writing time and address validity period to complete persistent storage. If the response is unsuccessful, does not carry a registration address, or has an invalid address format, the Agent calls a system command to release the currently acquired IP address, clears the locally temporarily stored IP and ServerIP information, and then returns to step S101 to restart the IP acquisition process.

[0105] As can be seen, the validity of the obtained registration address is ensured through status code verification, address existence verification, and address format verification; the registration address is persisted using metadata files to avoid the Agent having to obtain the registration address again after restarting.

[0106] S105: After the detection is successful, the agent collects the host hardware information and reports the collected host hardware information to the address used for node registration in order to complete the registration of node information and realize node discovery.

[0107] Step S105 and subsequent steps include: the agent establishes a periodic task to periodically send heartbeats to the server and report host information; when the node hardware is reconfigured, the agent synchronously reports the updated host information to the server.

[0108] In some embodiments, after the Agent confirms successful detection and obtains a legitimate registration address, it collects host hardware information according to preset categories: core information includes CPU model, number of CPU cores, memory capacity, and memory frequency; basic information includes hard disk capacity, hard disk interface type, network card MAC address, and network card speed; and auxiliary information includes motherboard serial number and BIOS version. During the collection process, the Agent obtains hardware data by calling the system's underlying interface to ensure the accuracy of the information.

[0109] In this embodiment, after data collection is completed, the Agent encapsulates the hardware information into a reporting data packet according to a preset data format. The data packet contains the previously acquired Agent identification information. Subsequently, the Agent sends a reporting request to the registration address and transmits the data packet to the node registration interface of the server. After receiving the data packet, the server parses the hardware information and stores it in the node management database, completing the registration of the node information. At the same time, it returns a registration success response to the Agent. After receiving the response, the Agent determines that the node auto-discovery process is complete and records the registration result. If the reporting fails, the Agent will retry the reporting until it succeeds or the preset number of retries is reached.

[0110] As can be seen, this embodiment uses a hardware information acquisition method based on the system's underlying interface to ensure that the acquired hardware data is authentic and reliable; through standardized data format encapsulation, the server can quickly parse and report information; the registration address is used to achieve accurate reporting of hardware information, and combined with the server's database storage, the registration and management of node information are completed, ultimately achieving automatic node discovery.

[0111] In one embodiment of the present invention, based on step S102, the following is a possible embodiment and its specific implementation will be described in a non-limiting manner. Step S102 specifically includes the following steps:

[0112] Step S1021: After obtaining the ServerIP, the proxy verifies the ServerIP.

[0113] The verification method in this embodiment is based on the format characteristics of ServerIP and the pre-defined IP address range rules.

[0114] Optionally, the proxy checks whether the ServerIP conforms to the standard IPv4 or IPv6 address format and determines whether the IP address belongs to a pre-configured range of legal IP addresses.

[0115] Subsequent access operations will only proceed after the ServerIP passes the validity verification.

[0116] As can be seen, when the proxy verifies the validity of the ServerIP, it first checks each field of the ServerIP according to the IPv4 or IPv6 address format specifications. For IPv4 addresses, it checks whether the value range of each field is between 0 and 255, and whether the overall address format conforms to the standard; for IPv6 addresses, it checks whether its hexadecimal representation format is correct. The proxy then reads pre-defined valid IP address range information from its local configuration file, compares the ServerIP with these address ranges, and determines whether the ServerIP belongs to a valid address range.

[0117] Step S1022: After the ServerIP passes verification, the proxy constructs a probe request packet containing preset identification information.

[0118] It should be noted that when constructing a probe request packet containing preset identification information, the proxy first obtains the server's unique hardware identifier, such as the server's serial number or MAC address, from the server's hardware information storage module. The proxy then obtains the current system time and converts it into a timestamp. Following predefined combination rules, the unique hardware identifier and the timestamp are combined into a composite identifier.

[0119] Optionally, a unique hardware identifier and a timestamp can be concatenated in a specific string format. This composite identifier is then added to the relevant fields of the probe request packet. This construction method ensures the probe request packet is unique and identifiable.

[0120] Step S1023: The agent selects an appropriate network transmission protocol to send probe request packets based on the dynamic changes in the network environment.

[0121] In this embodiment, the agent monitors the transmission characteristics of the local network in real time, such as network latency and packet loss rate.

[0122] Based on the parameters, the proxy selects the most suitable network transmission protocol from a variety of preset protocols to send probe request packets. For example, when network latency is low and packet loss rate is low, a protocol with higher transmission efficiency can be selected; when network latency is high or packet loss rate is high, a protocol with retransmission mechanisms and fault tolerance is selected. This method of dynamically selecting the transmission protocol based on the network environment can better adapt to complex network environments and improve the success rate of probe request transmission.

[0123] Optionally, when the network latency is less than a certain threshold and the packet loss rate is less than another threshold, a protocol with high transmission efficiency but relatively weak fault tolerance is selected; when the network latency or packet loss rate exceeds the corresponding threshold, a protocol with retransmission mechanism and strong fault tolerance is selected to improve the success rate of request transmission.

[0124] Step S1024: After receiving the probe request packet from the proxy, the server verifies the specific identification information in the probe request packet. The server parses and verifies the composite identifier in the probe request packet based on the pre-stored relationship between the server hardware identifier and the composite identifier generation rules. Once the composite identifier verification is successful, the server continues processing the probe request and returns a response to the proxy.

[0125] It should be noted that when the server verifies the identification information in the probe request packet, it searches the pre-stored database for information corresponding to the server's unique hardware identifier in the probe request packet. Based on the composite identifier generation rules, the server parses and verifies the composite identifier in the probe request packet.

[0126] Optionally, the timestamp in the composite identifier is verified to be within a valid time range, and the composite identifier conforms to the format requirements of the generation rules. Only when all parts of the composite identifier pass verification will the server consider the probe request legitimate, continue processing the probe request, and return a response to the proxy. This embodiment adds a server-side verification step for probe requests, effectively preventing illegal or malicious probe requests and improving server security.

[0127] Step S1025: After sending the probe request packet, the proxy starts a timer. The timer is dynamically adjusted according to the real-time network conditions. The proxy calculates the waiting time based on previously monitored parameters such as network latency. If the proxy receives a response from the server before the timer expires, it processes the response normally; if no response is received after the timer expires, the proxy reconstructs the probe request packet and resends it.

[0128] Optionally, a reasonable waiting time can be calculated based on the average and standard deviation of network latency, combined with a preset weighting coefficient. During the waiting process, the proxy continuously monitors changes in network status. If a significant change occurs in the network status, the current waiting timer is terminated early, and the waiting time is recalculated. If a response is received from the server before the waiting timer expires, the proxy processes the response promptly. If no response is received after the timeout, the proxy reconstructs the probe request packet, selects the transport protocol and sets the waiting timer in the same manner, and resends the probe request to improve probe efficiency.

[0129] In one embodiment of the present invention, based on step S104, the following is a possible embodiment and its specific implementation will be described in a non-limiting manner. Step S104 specifically includes the following steps:

[0130] S1041: The proxy parses the response message returned by the server, extracts the status code, address information and extended fields in the message body; and classifies the failure type into network timeout, server error, invalid address and forged response according to preset rules, and records them to the proxy's temporary log respectively.

[0131] S1042: Adjust the retry strategy parameters based on the failure types classified in S1041;

[0132] If the network timeout occurs, the next retry interval will be shortened to half of the current interval.

[0133] If the error is on the server side, the retry interval will be extended to twice the current interval, and the number of retries per day will be limited.

[0134] If the address is invalid, mark the ServerIP as unavailable and remove it from the probe list; if it is determined to be a forged response, immediately trigger a security alert and record the attack characteristics.

[0135] S1043: Before releasing the current IP, the proxy will encrypt and cache the temporary state of this probe to local storage;

[0136] Optionally, the temporary state includes the verified hardware feature hash, the protocol types and ports tried, and the extended fields for failures.

[0137] S1044: Before releasing the current IP, the proxy uses the server's public key to verify the digital signature of the response message. If the signature is invalid, it is determined to be a forged response, and the attack source IP is additionally recorded in the security log; if the signature is valid but still fails, it is confirmed that the server actively rejected it, and the server instance is marked as untrusted.

[0138] S1045: If the number of consecutive retries exceeds the preset maximum value or the number of retries in a single day exceeds the limit, the agent will stop retries and generate a comprehensive alarm log containing the failure type, cache status, and attack characteristics.

[0139] Upload the alarm log to the server management platform, release the current IP and clear the temporary cache, return to step S101 to obtain the IP again and start the probe.

[0140] In one embodiment of the present invention, based on step S105, the following is a possible embodiment and its specific implementation will be described in a non-limiting manner. Step S105 specifically includes the following steps:

[0141] S1051: The agent adjusts the triggering conditions for hardware information collection based on the hardware feature hash recorded during the probing phase.

[0142] In this embodiment, the hardware feature hash obtained during the probing phase reflects the device's performance level, and the acquisition interval is adjusted accordingly. Optionally, if the hardware feature corresponds to a device with more than 32 CPU cores, the acquisition interval is shortened to 10 seconds; if it corresponds to a device with fewer than 8 CPU cores, the acquisition interval is extended to 60 seconds. The correlation of the hardware feature hash allows the acquisition strategy to match the actual needs of the device.

[0143] S1052: When collecting hardware information, a multi-source verification method is used for key hardware.

[0144] Data is acquired through operating system commands and hardware driver interfaces, and the consistency between the two results is compared. If they are inconsistent, the hardware information is marked as pending verification and a second data acquisition is triggered.

[0145] S1053: Compare the currently collected hardware information with the historical configuration parameters recorded during the detection phase to generate an incremental change list;

[0146] In this embodiment, the incremental change list is generated based on a comparison between historical configurations and current data, transmitting only the changed portions. Incremental reporting uses a change-as-you-go approach, improving network efficiency.

[0147] S1054: Encrypt the incremental change list using the server's public key, and attach the temporary session identifier generated during the probing phase and the current timestamp to generate a security reporting packet.

[0148] It should be noted that data security protection is built based on a combination of encryption, TSID, and timestamps. Encryption prevents data from being tampered with, TSID prevents the replay of old data, and timestamps ensure the timeliness of data.

[0149] S1055: If the reporting fails, select the retry protocol and retry interval according to the failure type.

[0150] In this embodiment, HTTPS / 443 is used to detect successful connections, avoiding the additional overhead caused by protocol switching. If reporting fails, such as due to network timeout, the retry interval is adjusted according to the failure type, and the historical retry success rate is recorded. Retrying in this embodiment can be achieved through learning from failure types and historical data, thus improving the reporting success rate.

[0151] Furthermore, such as Figure 3 As shown, as a refinement and extension of the specific implementation of the above-described DHCP-based node detection method, the method further includes:

[0152] The server provides DHCP services, host management query and registration services, and discovers and reports information. It informs the probing agents of the addresses to be reported and records the reported node information. The node agent relies on the server vendor pre-installing the operating system and agent program on all machines, and the data center personnel complete the rack installation and connection. After the machine powers on, the system automatically starts the agent program, using the dhclient command to control the machine to automatically assign IP addresses and query the server address (ServerIP). The agent actively probes the URL of the ServerIP to confirm the existence of the host management program. If it does not exist, it releases the current IP and re-probes until the server-side host management service responds. The agent reports the hardware information to the host management service, completing the automatic node discovery process.

[0153] One possible processing step is as follows: After the server is powered on, the Agent starts, automatically obtains the IP address through dhclient, and analyzes and obtains the ServerIP address of the dhcpServer.

[0154] The agent probes whether the host management service exists on the server side by accessing the corresponding address;

[0155] When the server receives a request from the host, the response message body contains the server's address information.

[0156] If it exists, return it along with the register address. The agent saves this address to the agent metadata file for persistence. Otherwise, release the IP and re-probe.

[0157] After a successful detection, the Agent reports the collected host hardware information, such as CPU, memory, hard drive, network card, and system version, to the register address to register the node information and complete the automatic discovery of the node.

[0158] The agent establishes periodic tasks to maintain a heartbeat and periodically reports to the host.

[0159] If the node hardware is reconfigured, the host will report the updated information to the server.

[0160] As can be seen, this method can improve the efficiency of automatic discovery of a large number of host nodes. The node discovery can be completed as soon as the server is powered on. It can complete the automatic discovery of a large number of server nodes in a short time. This method is not limited to the node model and can be applied to servers, virtual machines and various operating systems with different architectures.

[0161] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0162] The following are embodiments of a DHCP-based node detection system provided in this disclosure. This system and the DHCP-based node detection methods described above belong to the same inventive concept. For details not described in detail in the embodiments of the DHCP-based node detection system, please refer to the embodiments of the DHCP-based node detection methods described above.

[0163] The system includes: a startup module, a server, and a proxy.

[0164] The startup module is used to start the agent of the node after the server is powered on. The agent obtains the Internet Protocol address (IP) through dhclient and resolves it to the server Internet Protocol address (ServerIP) of the Host Configuration Protocol.

[0165] The proxy is used to access a preset network address containing the ServerIP in order to detect whether the host management service on the server exists.

[0166] When the server receives a probe request from the proxy, it returns a response to the proxy. The message body of the response contains the address information used by the server for node registration.

[0167] The proxy determines whether the response is a preset success status and carries address information for node registration; if yes, the proxy persistently saves the address information for node registration to the proxy's metadata file; if no, the proxy releases the currently acquired IP and returns to step S101 to re-execute.

[0168] After the detection is successful, the agent collects the host hardware information and reports the collected host hardware information to the address used for node registration in order to complete the registration of node information and realize node discovery.

[0169] like Figure 4 As shown, this application also provides an electronic device, including a display module 103, a memory 102, a processor 101, and a computer program stored in the memory and executable on the processor 101. When the processor 101 executes the program, it implements the steps of the method for parsing and loading a GIM model of a power transmission project.

[0170] In embodiments of the present invention, electronic devices include, but are not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments described and / or claimed herein.

[0171] In this embodiment, processor 101 may be implemented using at least one of an application-specific integrated circuit, a programmable logic device, a field-programmable gate array, a processor, a controller, a microcontroller, a microprocessor, or an electronic unit designed to perform the functions described herein. In some cases, such an implementation may be implemented within a controller. For software implementation, implementations such as processes or functions may be implemented with separate software modules that allow the performance of at least one function or operation. Software code may be implemented by a software application (or program) written in any suitable programming language, and the software code may be stored in memory and executed by the controller.

[0172] The display module 103 is used to display information input by the user or information provided to the user. The display module 103 may include a display panel, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like.

[0173] The memory 102 can be used to store software programs and various data. The memory 102 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0174] This application also provides a storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the DHCP-based node detection method.

[0175] The storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example,, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0176] In a storage medium, a readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0177] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A node detection method based on DHCP, characterized in that, The methods include: S101: After the server boots up, it starts the agent on the node. The agent obtains the Internet Protocol address (IP) through dhclient and resolves it to the server IP address of the Host Configuration Protocol (HMAC). S102: The agent accesses a preset network address containing the ServerIP to detect whether the host management service on the server exists; S103: When the server receives a probe request from the proxy, it returns a response to the proxy. The response message body contains the address information used by the server for node registration. S104: The agent determines whether the response is a preset success status and carries the address information used for node registration; If so, the proxy will persistently save the address information used for node registration to the proxy's metadata file; If not, the proxy releases the currently acquired IP and returns to step S101 to re-execute; S105: After successful detection, the agent collects the host hardware information and reports the collected host hardware information to the address used for node registration in order to complete the registration of node information and realize node discovery.

2. The DHCP-based node detection method according to claim 1, characterized in that, Step S101 specifically includes the following steps: After the agent starts, it collects at least two independent hardware feature information of the local machine, and associates and combines the hardware feature information to generate a unique node identifier. The agent detects multi-segment information in the network environment, including the subnet mask, gateway address and historical connection records of each segment, and sets the segment priority of DHCP requests based on the multi-segment information; The agent sends a DHCP request via dhclient, which carries the unique node identifier and preset network segment priority information. After receiving the IP allocation response from the DHCP server, the agent checks whether the network segment to which the IP belongs is in the preset list of abnormal network segments. If it is, the agent rejects the IP and sends a reassignment request to the DHCP server. After the proxy confirms that it has received a legitimate IP address, it associates and stores the IP address with the unique node identifier and network environment parameters, and marks the timestamp of the IP address acquisition and the expected validity period in the stored information.

3. The DHCP-based node detection method according to claim 1, characterized in that, Step S103 specifically includes the following steps: After receiving the probe request from the proxy, the server extracts the hardware feature information carried in the request, performs hash matching verification with the locally stored legitimate hardware feature library, and determines whether the request source is an authorized hardware node. If the hardware feature verification is successful, the server generates a dynamic registration address based on the current timestamp, the server instance identifier, and a random number. The server encapsulates the dynamically registered address, current timestamp, and temporary session identifier in the probe request into a response message body, hashes the message body using the server's private key, encrypts it to generate a digital signature, and appends it to the response message. The server queries the local node information database based on the hardware feature code. If a historical registration record of the hardware exists, the historical configuration parameters are appended to the response message body; otherwise, the default configuration parameters are appended. The server returns the encapsulated response message to the proxy using the original protocol type of the probe request. At the same time, it records the hardware characteristics, dynamic port, timestamp, response status, and digital signature verification results of this probe in the local audit log, forming a session trace.

4. The DHCP-based node detection method according to claim 1, characterized in that, Step S102 also includes the following steps: After obtaining the ServerIP, the proxy verifies the ServerIP based on the format characteristics of the ServerIP and the pre-defined IP address range rules. After the ServerIP passes verification, the proxy constructs a probe request packet containing preset identification information; The proxy monitors the transmission characteristics of the local network in real time. Based on the parameters, the proxy selects the most suitable protocol from a variety of preset network transmission protocols to send probe request packets. When the network latency is less than a certain threshold and the packet loss rate is less than another threshold, a protocol with high transmission efficiency but relatively weak fault tolerance is selected. When the network latency or packet loss rate exceeds the corresponding threshold, a protocol with retransmission mechanism and strong fault tolerance is selected to improve the success rate of request sending. After receiving the probe request packet sent by the proxy, the server verifies the specific identification information in the probe request packet; The server parses and verifies the composite identifier in the probe request packet based on the pre-stored relationship between the server hardware identifier and the composite identifier generation rules; when the composite identifier is verified, the server continues to process the probe request and returns a response to the proxy. After sending the probe request packet, the proxy starts a timer; the timer is dynamically adjusted according to the real-time network conditions. The proxy calculates the waiting time based on the previously monitored network latency parameters. If the proxy receives a response from the server before the waiting timer expires, it processes the response normally. If no response is received after the waiting timer expires, the proxy reconstructs the probe request packet and sends it again.

5. The DHCP-based node detection method according to claim 1, characterized in that, Step S104 also includes the following steps: S1041: The proxy parses the response message returned by the server, extracts the status code, address information and extended fields in the message body; and classifies the failure type into network timeout, server error, invalid address and forged response according to preset rules, and records them to the proxy's temporary log respectively. S1042: Adjust the retry strategy parameters based on the failure types classified in S1041; If the network timeout occurs, the next retry interval will be shortened to half of the current interval. If the error is on the server side, the retry interval will be extended to twice the current interval, and the number of retries per day will be limited. If the address is invalid, mark the ServerIP as unavailable and remove it from the probe list; if it is determined to be a spoofed response, immediately trigger a security alert and record the attack characteristics; S1043: Before releasing the current IP, the proxy will encrypt and cache the temporary state of this probe to local storage; S1044: Before releasing the current IP, the proxy uses the server's public key to verify the digital signature of the response message. If the signature is invalid, it is determined to be a forged response, and the attack source IP is additionally recorded in the security log; if the signature is valid but still fails, it is confirmed that the server actively rejected it, and the server instance is marked as untrusted. S1045: If the number of consecutive retries exceeds the preset maximum value or the number of retries in a single day exceeds the limit, the agent will stop retries and generate a comprehensive alarm log containing the failure type, cache status, and attack characteristics. Upload the alarm log to the server management platform, release the current IP and clear the temporary cache, return to step S101 to obtain the IP again and start the probe.

6. The DHCP-based node detection method according to claim 1, characterized in that, Step S105 also includes the following steps: The agent adjusts the triggering conditions for hardware information collection based on the hardware feature hashes recorded during the probing phase. When collecting hardware information, a multi-source verification method is used for key hardware; the currently collected hardware information is compared with the historical configuration parameters recorded in the detection phase to generate an incremental change list; The incremental change list is encrypted using the server's public key, and a temporary session identifier generated during the probing phase and the current timestamp are appended to generate a security reporting packet. If the report fails, select the retry protocol and retry interval based on the failure type.

7. The DHCP-based node detection method according to claim 1, characterized in that, Step S105 and subsequent steps include: the agent establishes a periodic task to periodically send heartbeats to the server and report host information; when the node hardware is reconfigured, the agent synchronously reports the updated host information to the server.

8. A node detection system based on DHCP, characterized in that, The system is used to implement the DHCP-based node detection method as described in any one of claims 1 to 7; The system includes: a startup module, a server, and a proxy. The startup module is used to start the agent of the node after the server is powered on. The agent obtains the Internet Protocol address (IP) through dhclient and resolves it to the server Internet Protocol address (ServerIP) of the Host Configuration Protocol. The proxy is used to access a preset network address containing the ServerIP in order to detect whether the host management service on the server exists. When the server receives a probe request from the proxy, it returns a response to the proxy. The response message body contains the address information used by the server for node registration. The proxy determines whether the response is a preset success status and carries the address information used for node registration; if yes, the proxy persists the address information used for node registration to the proxy's metadata file; if no, the proxy releases the currently acquired IP and returns to step S101 to re-execute. After a successful detection, the agent collects the host hardware information and reports the collected host hardware information to the address used for node registration in order to complete the registration of node information and realize node discovery.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the DHCP-based node detection method as described in any one of claims 1 to 7.

10. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the DHCP-based node detection method as described in any one of claims 1 to 7.

Images