A DNS resolution method, system, storage medium and program product for low-power device

Abstract

A low-power device DNS resolution method, system, storage medium and program product, relating to the field of digital information transmission, in which the default DNS server address of the business system of the low-power device is configured as a local loopback address; the domain name information in the DNS request is extracted, and the request message is sent to the low-power module; a hash value is calculated; a corresponding DNS cache entry is found; if found, it is determined whether the survival time of the DNS cache entry has expired; if the survival time has not expired, the IP address and survival time are returned to the DNS proxy module; if not found or the survival time has expired, a DNS resolution request is initiated; the IP address and survival time in the resolution result and the hash value form a new DNS cache entry and store it in a preset storage space; the IP address and survival time are returned to the DNS proxy module; a DNS response message is generated and responded. The application reduces the number of cache establishment times, thereby achieving the purpose of optimizing the performance of low-power devices.

Description

Technical Field

[0001] The present application belongs to the field of digital information transmission, and in particular, relates to a low-power device DNS resolution method, system, storage medium and program product. Background Art

[0002] With the widespread application of IoT technology, the use of low-power devices in various scenarios is becoming increasingly popular. In order to achieve low-power operation, such devices usually adopt a master-slave architecture design, in which the business system will remain powered off when not necessary, and only the low-power module maintains basic network connection. However, when the device needs to communicate with the server, the business system needs to perform DNS resolution first after being awakened. This process not only prolongs the wake-up time of the device, but may also cause additional power consumption due to DNS resolution failure or timeout, affecting the actual use of the device.

[0003] In response to the above problems, the relevant technology solves them by implementing a DNS cache module in the business system, which can save the DNS resolution results locally, thereby avoiding the need to interact with the external DNS server every time it is woken up. When the business system needs to perform domain name resolution, it first queries the local cache, and directly uses the valid resolution results if they exist, thereby reducing the DNS resolution time and the number of network interactions.

[0004] However, since the business system is in a periodic power-off state, the DNS cache stored in the business system will be lost, causing the device to re-establish the DNS cache every time it is reawakened. Repeated cache establishment increases system overhead, making it difficult to truly achieve the goal of optimizing the performance of low-power devices. Summary of the invention

[0005] The present application provides a low-power device DNS resolution method, system, storage medium and program product for reducing the number of cache establishment times, thereby achieving the purpose of optimizing the performance of low-power devices.

[0006] In a first aspect, the present application provides a DNS resolution method for a low-power device, wherein a default DNS server address of a business system of the low-power device is configured as a local loopback address, and the business system includes a DNS proxy module, and the DNS proxy module is used to monitor a preset DNS port;

[0007] When the DNS proxy module monitors a DNS request, it extracts the domain name information in the DNS request, and sends the request message containing the domain name information to the low-power module of the low-power device through a preset hardware communication protocol;

[0008] Receive the hash value of the domain name information calculated by the low power module;

[0009] Based on the hash value, searching for a corresponding DNS cache entry in a preset storage space, where the DNS cache entry includes a hash value, a survival time, and an IP address;

[0010] If the corresponding DNS cache entry is found, determine whether the survival time of the DNS cache entry has expired;

[0011] If the survival time has not expired, the IP address and survival time in the DNS cache entry are returned to the DNS proxy module through the hardware communication protocol;

[0012] If the corresponding DNS cache entry is not found or the survival time has expired, a DNS resolution request is initiated to the external DNS server;

[0013] The IP address, survival time and hash value in the received resolution result are combined into a new DNS cache entry and stored in a preset storage space;

[0014] Return the IP address and survival time to the DNS proxy module through the hardware communication protocol;

[0015] Generates a DNS response message according to the DNS protocol specification and responds to the DNS request.

[0016] By adopting the above technical solution, by configuring the default DNS server of the low-power device business system as a local loopback address, the DNS request is intercepted and processed by the DNS proxy module. The low-power module calculates the hash value of the domain name and searches in the local cache. If there is an unexpired cache entry, the IP address is directly returned, avoiding the initiation of a resolution request to an external DNS server. When a resolution request needs to be initiated to an external DNS server, the resolution result is cached in the local storage space, realizing localized storage and fast access of the DNS resolution result, and reducing network communication power consumption. Since the DNS proxy module only wakes up the low-power module for hash value calculation and cache query when necessary, it avoids the continuous operation of the low-power module, further reducing the overall power consumption of the system. Data is transmitted between the business system and the low-power module through a preset hardware communication protocol, ensuring the reliability and efficiency of data transmission, so that the entire DNS resolution process not only guarantees resolution performance but also achieves low-power operation.

[0017] In conjunction with some embodiments of the first aspect, in some embodiments, the step of determining the hash value calculated by the low power consumption module according to the domain name information specifically includes:

[0018] Receive data frames sent by the low-power module through a preset hardware communication protocol;

[0019] Parse the frame header and frame footer identifiers in the data frame, and extract the fragment sequence number and check code;

[0020] Verify the integrity of the data frame based on the checksum;

[0021] Reassemble multiple data frames according to fragment sequence numbers;

[0022] Determine the hash value from the reassembled data.

[0023] By adopting the above technical solution, the hash value is reliably obtained by parsing and processing the data frames sent by the low-power module. The data frame is received through the preset hardware communication protocol, and the frame header and frame tail identifiers are parsed to extract the fragment sequence number and check code. Combined with the check code verification mechanism, errors or losses in the data transmission process can be discovered in time. The mechanism of reorganizing the data frame based on the fragment sequence number ensures the integrity and orderliness of the data, avoids the failure of hash value calculation caused by data reorganization errors, improves the adaptability and reliability of the DNS resolution process, and reduces system power consumption while ensuring data accuracy.

[0024] In conjunction with some embodiments of the first aspect, in some embodiments, the step of searching whether there is a corresponding DNS cache entry in a preset storage space based on the hash value specifically includes:

[0025] Calculate the current storage capacity of the preset storage space;

[0026] When the current storage capacity is less than the preset threshold, the DNS cache entries are traversed;

[0027] The weight value is calculated based on the access frequency and remaining survival time of each DNS cache entry;

[0028] Sort DNS cache entries by weight value;

[0029] Delete the DNS cache entries with the lowest weight until the preset storage requirements are met.

[0030] By adopting the above technical solution, by monitoring the storage capacity of the preset storage space, cache entries are actively cleaned up when the storage capacity approaches the threshold. By calculating the access frequency and remaining survival time of the DNS cache entries to obtain the weight value, and sorting and deleting based on the weight value, it is ensured that the most valuable cache entries can be retained, reducing the problem of new cache entries that cannot be stored due to storage space exhaustion, and retaining cache entries with high access frequency and still within the validity period. Since the system prioritizes the retention of the most valuable cache entries, the number of external DNS queries for these frequently accessed domain names is reduced, the network communication overhead is reduced, and the cache effect is optimized, which not only ensures the system's continuous operation capability, but also improves the DNS resolution efficiency and reduces the system power consumption.

[0031] In conjunction with some embodiments of the first aspect, in some embodiments, after generating a DNS response message according to the DNS protocol specification and responding to the DNS request, the method further includes:

[0032] Record the sleep and wake-up time of the business system and the corresponding number of DNS requests;

[0033] When it is detected that the business system switches from the dormant state to the awakened state, the first batch of DNS request records after the last N awakenings are extracted;

[0034] Add domain names that appear more than a preset number of times in the first batch of DNS request records to the quick wake-up list;

[0035] When the business system enters the dormant state, the DNS cache entries of the domain names in the quick wake-up list are kept valid at all times;

[0036] Dynamically update the number of repetitions of each domain name in the quick wakeup list.

[0037] By adopting the above technical solution, by recording the time points of business system sleep and wake-up and the corresponding number of DNS requests, analyzing the pattern of the first batch of DNS requests after the system wakes up, domain names that appear more than a preset number of times are added to the quick wake-up list. By keeping the DNS cache entries of the domain names in the quick wake-up list valid at all times in the sleep state, the system can directly use the cached DNS resolution results after waking up without waiting for the response of the external DNS server. This cache preheating mechanism based on access rules reduces the DNS resolution delay after the system wakes up, improves the response speed of the business system, and reduces network communication overhead and system power consumption. The mechanism of dynamically updating the number of domain name occurrences ensures that the quick wake-up list can adapt to changes in business access patterns, so that the system always maintains the optimal cache preheating effect.

[0038] In conjunction with some embodiments of the first aspect, in some embodiments, the step of keeping the DNS cache entry of the domain name in the fast wake-up list always valid specifically includes:

[0039] Set the upper limit of the capacity of the quick wakeup list;

[0040] Calculate the time interval between the most recent access time of each domain name and the current time;

[0041] When the time interval exceeds the first preset time length, reducing the repetition count value of the corresponding domain name;

[0042] Delete domain names with duplicate count values ​​lower than a pre-designed value;

[0043] Before the DNS cache entry expires, update the resolution result through the external DNS server;

[0044] Generate a DNS response message based on the updated resolution result and respond.

[0045] By adopting the above technical solution, by monitoring the access time of the domain name in the quick wake-up list, reducing its repetition count value when the access time interval of the domain name exceeds the first preset time length, and deleting the domain name with a repetition count value lower than the preset value, the domain name that is no longer frequently accessed can be cleaned up in time to ensure that the quick wake-up list is always maintained in the optimal state. For the domain names that are still in the list, the system will actively update the resolution results through the external DNS server before the DNS cache entry expires, so that the DNS cache of these domain names always remains valid, so that after the device wakes up from the sleep state, it can quickly complete the DNS resolution of these domain names without waiting for the response of the external DNS server, thereby reducing the network delay after the device wakes up. Since the first batch of DNS requests after the device wakes up are usually fixed system services or domain names related to key applications, by pre-maintaining the effective DNS cache of these domain names, the network connection speed and user experience after the device wakes up can be improved, while avoiding unnecessary DNS query requests and reducing the power consumption of the device.

[0046] In conjunction with some embodiments of the first aspect, in some embodiments, before generating a DNS response message based on the updated resolution result and responding, the method further includes:

[0047] When the low power consumption module is in the active state for a duration exceeding a second preset time, detecting whether there is a pending DNS request;

[0048] If there is no pending DNS request, the low power module is switched to a sleep state;

[0049] Record the state switching time point and remaining power of the low-power module;

[0050] Adjusting the second preset duration based on the state switching time point and the remaining power;

[0051] Generate a response message for the newly received DNS request and respond.

[0052] By adopting the above technical solution, by monitoring the duration of the active state of the low-power module, when it exceeds the second preset time and there is no pending DNS request, the low-power module is switched to a sleep state, and the state switching time point and the remaining power information are recorded. Based on this information, the second preset time is dynamically adjusted, so that the system can reduce the working time of the low-power module while ensuring the normal processing of DNS requests, avoid the situation where the low-power module is still in an active state when there is no DNS request to be processed, and reduce unnecessary energy consumption. At the same time, by generating and responding to the newly received DNS request, the continuity and reliability of the DNS service are ensured, and the overall power consumption of the device is reduced and the battery life of the device is extended while ensuring the quality of the DNS resolution service.

[0053] In combination with some embodiments of the first aspect, in some embodiments, adjusting the second preset duration based on the state switching time point and the remaining power specifically includes:

[0054] Count the average working time of low-power modules in different power ranges;

[0055] Set multiple working hours levels according to the average working hours;

[0056] When the remaining power is in different power ranges, the corresponding duration level is determined;

[0057] Record the actual work results after each adjustment;

[0058] The value range of the duration level is adjusted according to the actual work results to obtain an adjusted second preset duration.

[0059] By adopting the above technical solution, the system establishes a power-adaptive working time control mechanism by counting the average working time of the low-power module in different power ranges, setting multiple time levels, and selecting the corresponding time level according to the remaining power. By recording the actual working effect after each adjustment and dynamically adjusting the value range of the time level accordingly, the second preset time can be continuously optimized according to the actual use of the device. This self-learning time control mechanism enables the system to adopt the optimal working time strategy under different power levels, improves the working efficiency of the low-power module, and realizes the refined management of power consumption, extending the use time of the device while ensuring the availability of the DNS resolution service.

[0060] In a second aspect, an embodiment of the present application provides a low-power device DNS resolution system, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and one or more processors call the computer instructions to enable the system to execute the method described in the first aspect and any possible implementation method of the first aspect.

[0061] In a third aspect, an embodiment of the present application provides a computer-readable storage medium, comprising instructions, which, when executed on a system, causes the system to execute the method described in the first aspect and any possible implementation of the first aspect.

[0062] One or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages:

[0063] 1. The present application provides a DNS resolution method for low-power devices. By configuring the default DNS server of the low-power device business system as a local loopback address, the DNS request is intercepted and processed by the DNS proxy module. The low-power module calculates the hash value of the domain name and searches in the local cache. If there is an unexpired cache entry, the IP address is directly returned, avoiding the initiation of a resolution request to an external DNS server. When a resolution request needs to be initiated to an external DNS server, the resolution result is cached in the local storage space, realizing localized storage and fast access of the DNS resolution result, and reducing network communication power consumption. Since the DNS proxy module only wakes up the low-power module for hash value calculation and cache query when necessary, the low-power module is avoided from working continuously, further reducing the overall power consumption of the system. Data is transmitted between the business system and the low-power module through a preset hardware communication protocol, ensuring the reliability and efficiency of data transmission, so that the entire DNS resolution process not only guarantees resolution performance but also achieves low-power operation.

[0064] 2. The present application provides a DNS resolution method for low-power devices. By recording the time points of business system sleep and wake-up and the corresponding number of DNS requests, the first batch of DNS requests after the system wakes up are analyzed, and domain names that appear more than a preset number of times are added to a quick wake-up list. By keeping the DNS cache entries of the domain names in the quick wake-up list valid at all times in the sleep state, the cached DNS resolution results can be used directly after the system wakes up without waiting for the response of the external DNS server. This cache preheating mechanism based on access rules reduces the DNS resolution delay after the system wakes up, improves the response speed of the business system, and reduces network communication overhead and system power consumption. The mechanism of dynamically updating the number of domain name occurrences ensures that the quick wake-up list can adapt to changes in business access patterns, so that the system always maintains the optimal cache preheating effect.

[0065] 3. The present application provides a DNS resolution method for low-power devices. By monitoring the duration of the active state of the low-power module, when it exceeds the second preset time and there is no pending DNS request, the low-power module is switched to a sleep state, and the state switching time point and the remaining power information are recorded. The second preset time is dynamically adjusted based on this information, so that the system can reduce the working time of the low-power module while ensuring the normal processing of DNS requests, avoid the situation where the low-power module continues to be active when there is no DNS request to be processed, and reduce unnecessary energy consumption. At the same time, by generating and responding to the newly received DNS request, the continuity and reliability of the DNS service are ensured. On the premise of ensuring the quality of DNS resolution service, the overall power consumption of the device is reduced and the battery life of the device is extended. BRIEF DESCRIPTION OF THE DRAWINGS

[0066] Figure 1 It is a flow chart of a DNS resolution method for a low-power device in an embodiment of the present application.

[0067] Figure 2 It is a flow chart of a fast wake-up method based on historical DNS request records in an embodiment of the present application.

[0068] Figure 3 It is a schematic diagram of the physical device structure of a low-power device DNS resolution system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0069] The terms used in the following embodiments of the present application are only for the purpose of describing specific embodiments, and are not intended to be used as limitations to the present application. As used in the specification and appended claims of the present application, the singular expressions "one", "a kind of", "said", "above", "the" and "this" are intended to also include plural expressions, unless there is a clear indication to the contrary in the context. It should also be understood that the term "and / or" used in the present application refers to any or all possible combinations comprising one or more listed items.

[0070] In the following, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as suggesting or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features, and in the description of the embodiments of the present application, unless otherwise specified, "plurality" means two or more.

[0071] The following uses an embodiment and combines Figure 1 , a low-power device DNS resolution method in an embodiment of the present application is described:

[0072] See also Figure 1 , which is a flow chart of a DNS resolution method for a low-power device in an embodiment of the present application.

[0073] S101, configuring the default DNS server address of the service system of the low-power device as a local loopback address;

[0074] The system configures the default DNS server address of the business system of the low-power device as a local loopback address. The business system includes a DNS proxy module, and the DNS proxy module is used to monitor a preset DNS port.

[0075] First, the system needs to configure the default DNS server address of the business system of the low-power device to the local loopback address. The loopback address is a special IP address that points to the device itself. By setting the default DNS server address to the loopback address, the system can ensure that all DNS requests are processed by the local DNS proxy module of the device instead of being sent directly to an external DNS server.

[0076] The system can configure the default DNS server address by modifying the network configuration file or using the network management interface provided by the operating system. Specifically, the system can set the nameserver field to 127.0.0.1 in the network configuration file (such as / etc / resolv.conf), or use commands such as ifconfig and ip to dynamically modify the DNS configuration of the network interface. In addition, the system also needs to ensure that the DNS proxy module in the business system is listening to the preset DNS port (such as port 53) in order to receive and process DNS requests from local applications.

[0077] When configuring the default DNS server address, the system may encounter the problem that some applications or services cannot recognize the loopback address as a DNS server. In this case, the system can consider implementing a transparent proxy function in the DNS proxy module, that is, intercepting and forwarding DNS requests from these applications to the real external DNS server, and returning the response results to the application, thereby avoiding compatibility issues. Another solution is to set iptables rules at the operating system level to redirect DNS requests sent to the loopback address to the port listened by the DNS proxy module.

[0078] S102, when the DNS proxy module monitors the DNS request, extracts the domain name information in the DNS request, and sends the request message containing the domain name information to the low-power module of the low-power device through a preset hardware communication protocol;

[0079] When the DNS proxy module monitors the DNS request, the system extracts the domain name information in the DNS request and sends the request message containing the domain name information to the low-power module of the low-power device through a preset hardware communication protocol.

[0080] When the DNS proxy module listens to the DNS request from the local application, the system needs to extract the domain name information from the request message. The DNS request message follows a specific format, which contains the domain name to be queried. The system can parse the request message according to the DNS protocol specification and obtain the domain name from the Question Section field.

[0081] After extracting the domain name information, the system needs to encapsulate it into a request message and send it to the low-power module of the low-power device through a preset hardware communication protocol. The hardware communication protocol can be a common communication interface and protocol such as UART, SPI, I2C, etc. The system must first determine the communication rate and maximum transmission unit (MTU) of the hardware communication protocol used in order to appropriately fragment and transmit the request message.

[0082] Due to the MTU limitation of the hardware communication protocol, the domain name information may need to be divided into multiple request message fragments for transmission. The system can divide the domain name information into several fragments less than or equal to the MTU according to the MTU size. For each fragment, the system also needs to add a frame header and a frame tail identifier, where the frame header includes the fragment sequence number and a check code, which are used for message reassembly and integrity verification at the receiving end. Finally, the system sends each request message fragment in sequence according to the fragment sequence number.

[0083] When sending domain name query requests through the hardware communication protocol, the system may encounter problems with request message loss or damage due to communication anomalies. In order to improve the reliability of communication, the system can introduce a retransmission mechanism in the request message. Specifically, the sender starts a timer after sending a request. If no confirmation response is received from the receiver within the timeout period, the request is automatically resent until confirmation is received or the maximum number of retries is reached. Another optimization method is to add a flow control mechanism to the hardware communication protocol to dynamically adjust the sending window size according to the processing capacity of the receiver to avoid message loss caused by sending too fast.

[0084] S103, determining a hash value calculated by the low power module according to the domain name information;

[0085] The system determines the hash value calculated by the low-power module according to the domain name information, specifically: receiving the data frame sent by the low-power module through a preset hardware communication protocol;

[0086] Parse the frame header and frame footer identifiers in the data frame, and extract the fragment sequence number and check code;

[0087] Verify the integrity of the data frame based on the checksum;

[0088] Reassemble multiple data frames according to fragment sequence numbers;

[0089] Determine the hash value from the reassembled data.

[0090] After sending the domain name query request, the system needs to wait for the low-power module to return the hash value of the domain name information. The hash value is a fixed-length value calculated by the domain name information through a hash algorithm. It can uniquely identify the original domain name and can also be easily matched and searched locally.

[0091] The system receives the hash value sent back by the low-power module through the hardware communication protocol. Depending on the hardware communication protocol, the receiving process may be slightly different. For example, for the UART protocol, the system needs to read the data from the serial port buffer, parse it according to the frame format, and extract the hash value part. If the hash value is sent in fragments, the system also needs to wait for all the fragments to be received and reassemble them according to the fragment sequence number to obtain the complete hash value.

[0092] In the process of receiving hash values, the system may encounter abnormal situations such as communication errors or data corruption. In order to ensure the integrity and accuracy of the data, the system can verify the received hash value. A common method is to calculate the checksum (such as CRC32) of the hash value when sending, and attach it to the end of the frame. After receiving the complete hash value, the receiving end recalculates the checksum and compares it with the checksum at the end of the frame. If the two are inconsistent, it means that an error has occurred in the data transmission process and a retransmission request is required. Another solution is to use a more reliable transmission protocol, such as TCP, which provides a connection-based, reliable data transmission service that can automatically handle abnormal situations such as data loss and disorder.

[0093] S104, searching in a preset storage space whether there is a corresponding DNS cache entry based on the hash value;

[0094] Based on the hash value, the system searches for a corresponding DNS cache entry in the preset storage space. The DNS cache entry includes the hash value, survival time, and IP address. Specifically: calculate the current storage capacity of the preset storage space;

[0095] When the current storage capacity is less than the preset threshold, the DNS cache entries are traversed;

[0096] The weight value is calculated based on the access frequency and remaining survival time of each DNS cache entry;

[0097] Sort DNS cache entries by weight value;

[0098] Delete the DNS cache entries with the lowest weight until the preset storage requirements are met.

[0099] After receiving the hash value of the domain name information, the system needs to check whether there is a corresponding DNS cache entry in the local preset storage space. The DNS cache entry contains the hash value of the domain name information, the corresponding IP address, and TTL (Time-To-Live, i.e., survival time) and other information.

[0100] The preset storage space can be a memory area on the device or an independent storage device (such as Flash, EEPROM, etc.). The system selects the appropriate storage medium and data structure to organize the DNS cache based on the current storage capacity and access frequency. For example, if the number of cache entries is small and access is frequent, they can be directly stored in the memory, and data structures such as hash tables can be used to speed up the search; if the number of cache entries is large or needs to be persisted, you can consider using a file system or database to store them.

[0101] The specific search process is as follows: the system first calculates the current storage capacity of the preset storage space. If it is found that the current capacity is close to the preset threshold (such as 80%), the cache needs to be cleaned. The cleaning strategy can be LRU (Least Recently Used), that is, removing the least recently used cache entries. To this end, the system needs to traverse all DNS cache entries and calculate a weight value for each entry. The weight value comprehensively considers the access frequency and remaining survival time of the entry. The smaller the weight value, the more likely the entry is to be deleted. After calculating the weight values ​​of all entries, the system sorts the entries according to the weight values ​​and deletes several entries with the smallest weight values ​​until the preset storage requirements are met. After completing the cache cleanup, the system matches the received hash value with the current cache entry to see if there is an entry with the same hash value.

[0102] If there is no entry matching the current hash value in the cache, the system can also asynchronously send the query request that missed this time to the low-power module, allowing it to perform DNS resolution and update the cache in the background, so that the system can directly return the result of this query without waiting for the cache to be updated. Similarly, if it is found that the survival time of the cache entry is very short (such as less than a preset threshold), the system can also trigger an asynchronous cache update while returning the cache result, and refresh the survival time in time, thereby reducing additional network requests caused by cache failure.

[0103] S105, determining whether the survival time of the DNS cache entry has expired;

[0104] If the corresponding DNS cache entry is found, it is determined whether the survival time of the DNS cache entry has expired.

[0105] If a DNS cache entry matching the domain name information hash value is found in the preset storage space, the system then needs to determine whether the lifetime of the entry has expired. The lifetime of a DNS cache entry refers to the maximum time that the entry remains valid in the local cache since the last successful DNS resolution.

[0106] The setting of the survival time follows the TTL field in the DNS protocol. When the system obtains the domain name resolution result from the external DNS server, the response message will contain a TTL value, which indicates how long the result can be cached locally. The system adds the current timestamp to the TTL value to obtain the expiration time of the cache entry and saves it in the cache entry.

[0107] The process of determining whether the survival time has expired is relatively simple. The system only needs to compare the current system time with the expiration time recorded in the cache entry. If the current time has exceeded the expiration time, the entry is considered invalid and DNS resolution needs to be performed again. Conversely, if the current time is still less than the expiration time, the cached IP address in the entry can be used directly.

[0108] When determining the survival time, the system can also consider introducing a certain tolerance, that is, allowing the cache entry to remain valid for a short period of time after expiration. This is because there may be a certain error between the system time of the client and the server. If the time accuracy is too strict, some caches that could have been reused may be mistakenly discarded. Therefore, the system can set a time tolerance window (such as 10 seconds), and the cache entry will still be considered valid during this period after it expires. Of course, this tolerance window should not be set too long, otherwise it will affect the timeliness of the cache.

[0109] In addition, for some domain names with high update frequency or strict timeliness requirements, the system can also set a fixed cache expiration time for them, forcing the cache to be refreshed after a certain time interval, rather than relying entirely on the TTL value. This requires adding an additional timestamp field to the cache entry to record the time of the most recent successful resolution. When the system receives a query request for the domain name, it first checks whether the difference between the current time and the most recent resolution time exceeds the preset expiration time. If so, a new resolution request is initiated and the cache is updated regardless of whether the TTL has expired, ensuring that the latest resolution result is always used.

[0110] S106, initiating a DNS resolution request to an external DNS server;

[0111] If the corresponding DNS cache entry is not found or the survival time has expired, a DNS resolution request is initiated to the external DNS server.

[0112] When the system fails to find the entry corresponding to the requested domain name in the local cache, or finds the entry but its lifetime has expired, it needs to initiate a new DNS resolution request to the external DNS server to obtain the latest IP address of the domain name.

[0113] The process of initiating a DNS resolution request follows the specifications of the DNS protocol. The system must first construct a DNS query message, which needs to contain the domain name information to be queried, the query type (such as A record, AAAA record, etc.) and some other control fields. Then, the system needs to select a suitable DNS server to send the query request. The address of the DNS server can be obtained from the network configuration of the device, or some public DNS services (such as 8.8.8.8, 114.114.114.114, etc.) can be used.

[0114] When sending a DNS query message, the system also needs to wait for and process the response message returned by the DNS server. If the DNS server can successfully resolve the domain name, it will return a response message containing the corresponding IP address. The system needs to extract the IP address from the message and record the TTL value in the response message for subsequent cache updates. If the DNS server cannot resolve the domain name, it will return a response code indicating an error. The system needs to take appropriate measures based on the specific error type (such as domain name does not exist, server failure, etc.).

[0115] S107, storing the IP address and survival time in the received resolution result and the hash value into a new DNS cache entry in a preset storage space;

[0116] After receiving the resolution result returned by the external DNS server, the system needs to combine the IP address, survival time and other information with the original domain name information hash value to form a new DNS cache entry and store it in the preset storage space for subsequent fast query and access. This can avoid repeated DNS resolution requests for the same domain name, reduce network communication overhead and latency, and improve system performance and efficiency.

[0117] When implementing this step, the system needs to extract key field information, such as IP address list, TTL value, authoritative answer flag, etc., based on the format and semantics of the DNS response message. For the IP address list, the system can select IPv4 address or IPv6 address, or save multiple IP addresses at the same time to achieve failover or load balancing. For the TTL value, the system needs to convert it into an absolute expiration timestamp and set the corresponding timer in the cache time management module to clear expired cache in time. In addition, the system also needs to check the integrity and validity of the DNS response message to eliminate possible abnormalities such as format errors and data tampering.

[0118] In the process of updating the DNS cache, some technical problems and challenges may be encountered. For example, due to concurrent access, cache synchronization and other reasons, cache data inconsistency or conflict may occur. In response to this situation, the system can use concurrent control mechanisms such as read-write locks and version number control to ensure the atomicity and consistency of cache data. At the same time, the system also needs to consider the time management of the cache to avoid long-term residence of cache entries resulting in obsolete data or waste of space. To solve this problem, the system can adopt cache optimization strategies such as regular cleanup and LRU elimination to dynamically adjust the time and space configuration of the cache to balance data timeliness and query efficiency.

[0119] S108, returning the IP address and survival time to the DNS proxy module through the hardware communication protocol;

[0120] After successfully updating the DNS cache entry, the system needs to return the resolved IP address and survival time to the DNS proxy module through the previously agreed hardware communication protocol, so that it can generate the final DNS response message in accordance with the standard DNS protocol format and return the result to the requesting business system. This can complete a complete DNS resolution process and meet the business system's needs for domain name resolution.

[0121] When implementing this step, the system needs to follow the communication protocol and data format agreed upon with the DNS proxy module, and encapsulate information such as the IP address and survival time into a standardized response message. The specific encapsulation method can adopt a processing logic similar to step S102, such as fragmenting messages longer than the MTU, adding frame headers and frame tails, calculating checksums, etc. At the same time, in order to ensure the reliability of data transmission, the system can also introduce reliable transmission mechanisms such as timeout retransmission and response confirmation.

[0122] In the process of returning data to the DNS proxy module, some technical problems and challenges may be encountered. For example, due to the limitations of the hardware communication protocol or implementation differences, data transmission may be delayed, erroneous, and other abnormal situations, affecting the performance and stability of the system. In response to this situation, the system can adopt optimization measures such as multi-channel concurrency and error checking to improve the efficiency and reliability of data transmission. In addition, when the DNS proxy module fails or is unresponsive, the system also needs to consider appropriate exception handling and recovery strategies, such as re-electing a new proxy module, actively closing invalid connections, etc., to avoid affecting the availability of the entire system due to local failures.

[0123] S109, generating a DNS response message according to the DNS protocol specification and responding to the DNS request;

[0124] After receiving the IP address and survival time information returned in step S108, the DNS proxy module needs to generate a standard DNS response message according to the DNS protocol specification and send it to the business system that originally initiated the DNS request to complete the entire DNS resolution process. The DNS response message usually includes multiple parts such as the query question, answer, authoritative information, and additional information, which are used to describe the requested domain name, IP address, TTL value, authoritative server, and other information.

[0125] When implementing this step, the DNS proxy module needs to strictly follow the format and semantics of the DNS protocol to construct a legal DNS response message. Specifically, the DNS proxy module needs to fill the received IP address into the RDATA field of the answer part, fill the survival time into the TTL field of the answer part, and set the corresponding flag bit and response code to indicate the type and status of the response. For other non-critical fields, such as authoritative information, additional information, etc., the DNS proxy module can omit or fill in default values ​​according to actual conditions to reduce the size of the response message.

[0126] S110: Return the IP address and survival time in the DNS cache entry to the DNS proxy module through the hardware communication protocol.

[0127] If it is determined in step S105 that the survival time has not expired, the system returns the IP address and survival time in the DNS cache entry to the DNS proxy module through the hardware communication protocol.

[0128] If it is determined in step S105 that the survival time of the DNS cache entry has not expired, the system can directly obtain the IP address and TTL information from the cache entry, and return this information to the DNS proxy module through the hardware communication protocol agreed upon with the DNS proxy module, without having to initiate a request to the external DNS server again. This can avoid unnecessary network communications and repeated queries, and improve the speed and efficiency of DNS resolution.

[0129] When implementing this step, the system can use a processing logic similar to step S108 to encapsulate the IP address and TTL value in the cache entry into a standardized response message and send it to the DNS proxy module through the hardware communication protocol. At the same time, in order to ensure the reliability and security of data transmission, the system also needs to consider necessary error checking, encryption protection and other measures.

[0130] In the process of obtaining data from the cache and returning it to the DNS proxy module, some technical problems and challenges may be encountered. For example, due to untimely or inconsistent updates of cache entries, the returned IP address information may not match the actual situation, affecting the normal access to the business system. In response to this situation, the system can adopt cache consistency maintenance mechanisms such as active updates and passive verification, and trigger cache data to synchronize with the authoritative DNS server regularly or according to specific events, and promptly correct possible errors or expired information. In addition, when the cache data fails or is damaged on a large scale, the system also needs to consider strategies for rapid recovery and reconstruction of the cache, such as loading from backup data, re-pulling, etc., to minimize the impact on the business system.

[0131] In the above embodiment, by configuring the default DNS server of the low-power device business system as a local loopback address, the DNS request is intercepted and processed by the DNS proxy module. The low-power module calculates the hash value of the domain name and searches in the local cache. If there is an unexpired cache entry, the IP address is directly returned, avoiding the initiation of a resolution request to an external DNS server. When it is necessary to initiate a resolution request to an external DNS server, the resolution result is cached in the local storage space, realizing localized storage and fast access of the DNS resolution result, and reducing network communication power consumption. Since the DNS proxy module will only wake up the low-power module for hash value calculation and cache query when necessary, it avoids the continuous operation of the low-power module, further reducing the overall power consumption of the system. Data is transmitted between the business system and the low-power module through a preset hardware communication protocol, ensuring the reliability and efficiency of data transmission, so that the entire DNS resolution process not only guarantees the resolution performance but also achieves low-power operation.

[0132] In actual applications, business systems frequently switch between sleep and wake-up states. When a business system switches from sleep to wake-up, a batch of DNS resolution requests are usually generated. If the cache entries of these DNS requests have expired, it is necessary to re-initiate resolution requests to the external DNS server, which will significantly increase the response delay after the system wakes up. To solve this problem, this embodiment proposes a fast wake-up method based on historical DNS request records. Figure 2 , a fast wake-up method based on historical DNS request records in an embodiment of the present application is described:

[0133] See also Figure 2 , which is a flow chart of a fast wake-up method based on historical DNS request records in an embodiment of the present application.

[0134] S201, recording the sleep and wake-up time points of the business system and the corresponding number of DNS requests;

[0135] The system records the time points of the business system's sleep and wake-up and the corresponding number of DNS requests, aiming to establish a correlation between the business system's operating status and the DNS request pattern, and to provide data support for subsequent fast wake-up optimization. Specifically, the system can record timestamps at key state switching points of the business system (such as entering sleep, exiting sleep, etc.), and count the number of DNS requests that occur within a certain time window (such as the first N minutes after wake-up) to form a complete historical record. These historical records can be stored in memory, files, or databases for subsequent analysis and use.

[0136] When implementing this step, the system can use a variety of methods to obtain the status information and DNS request information of the business system. For example, the dormancy and wake-up behavior of the business system can be captured by hooking the system API, monitoring power management events, etc.; DNS request data can be collected by network packet capture, log analysis, etc. At the same time, in order to save storage space and improve processing efficiency, the system can also perform necessary filtering and aggregation on the original data, such as removing duplicate or invalid records, counting the number of requests according to a fixed time granularity, etc. In addition, considering that the business characteristics and network environment may differ in different periods, the system can also introduce a data aging mechanism to regularly clean up or archive expired historical records to ensure the timeliness and representativeness of the data.

[0137] In the process of recording the sleep and wake-up time points and the corresponding number of DNS requests, some technical problems and challenges may be encountered. For example, when the business system is under high load or the network conditions are poor, the capture and statistics of DNS requests may be delayed, lost, and other anomalies, affecting the accuracy and completeness of the data. In response to this situation, the system can adopt fault-tolerant mechanisms such as multi-point collection and cross-validation to collect and compare data through multiple channels to promptly discover and correct possible errors or omissions. At the same time, the system can also set a reasonable sampling frequency and timeout threshold to minimize the impact on the normal operation of the business system while ensuring data quality. When the system detects serious anomalies or continuous missing data, it can also send an alarm notification to the administrator to prompt possible system failures or network problems, and assist in troubleshooting and repairing potential hidden dangers.

[0138] S202, when it is detected that the business system switches from the dormant state to the awakened state, extract the first batch of DNS request records after the most recent N awakenings;

[0139] When the system detects that the business system switches from the dormant state to the awake state, the system extracts the first batch of DNS request records after the last N awakenings from the historical records as the focus of analysis for fast awakening optimization. The first batch of DNS requests here usually refers to the first wave of domain name resolution requests initiated after the business system completes environmental recovery and network connection, which is often closely related to the rapid recovery of core business functions. By extracting the historical data of the last N awakenings, the system can obtain a relatively stable and reliable request sample set, reduce the interference of individual abnormal situations, and improve the universality of the optimization mechanism.

[0140] When implementing this step, the system first needs to set a reasonable statistical window period, that is, how long after wake-up the DNS request records can be classified as the first batch of requests. The size of this window period needs to be weighed according to the characteristics of the business system and the status of the network environment. It must be large enough to cover the main request scenarios, but small enough to ensure the relevance of the sample. Secondly, the system needs to filter out the most recent N wake-up events and their corresponding DNS request data from the historical records based on conditions such as timestamps, and arrange them in chronological order to form a structured data set. Finally, the system can perform appropriate cleaning and conversion on this data set, such as removing redundant fields, normalizing the domain name format, etc., to facilitate subsequent statistical analysis.

[0141] In the process of extracting the first batch of DNS request records after the last N wake-ups, the following technical problems and challenges may be encountered: First, the data quality of historical records may be inconsistent or missing, affecting the representativeness and reliability of the sample. In response to this situation, the system can introduce data repair and interpolation algorithms to infer and restore missing data points based on the characteristics and trends of adjacent records to improve the integrity of the overall data. Second, as time goes by and the business changes, some historical records may gradually lose their reference value and need to be dynamically updated and optimized. In response to this situation, the system can introduce differentiated attenuation factors, assign different weights to samples from different periods, gradually eliminate outdated and no longer representative data, and continue to include new and more valuable request records to maintain the freshness and effectiveness of the sample set.

[0142] S203, adding domain names that appear more than a preset number of times in the first batch of DNS request records to a quick wake-up list;

[0143] The system adds domain names that appear more than the preset threshold in the first batch of DNS request records to the quick wake-up list as candidates for priority caching and accelerated resolution. The purpose of this step is to automatically discover and extract key domain names that the business system must or frequently access when waking up from a large number of request records, and to maximize the network performance and user experience after waking up by focusing on optimizing these domain names. Among them, the number of repetitions is a key evaluation indicator, which reflects the frequency and stability of the domain name being requested. The higher the number, the more important the domain name is to the operation of the business system, and the higher its priority in wake-up optimization.

[0144] When implementing this step, the system first needs to traverse the first batch of DNS request records extracted, group and count them according to the domain name, and obtain the distribution of the number of times each domain name appears in different wake-up events. Then, the system screens and sorts the domain names according to the preset threshold of repeated occurrences (such as 80% of the total number of times), and marks the domain names that appear more than the threshold as key candidates. Next, the system can also further analyze and evaluate the key candidate domain names, such as examining their resolution time, TTL value, error rate and other indicators to determine whether they are suitable for inclusion in the final quick wake-up list. Finally, the system adds the screened domain names to the quick wake-up list and sets the corresponding cache strategy and optimization parameters, such as increasing the cache priority and extending the cache validity period.

[0145] In the process of generating a quick wake-up list, the following technical problems and challenges may be encountered: First, how to set the optimal threshold of the number of repetitions to ensure the coverage of key domain names without excessively expanding the size of the list. In response to this situation, the system can adopt a dynamic threshold adjustment strategy to adaptively adjust the threshold value based on the distribution characteristics of historical data and feedback on optimization effects, and seek a balance between accuracy and recall. Second, how to deal with the dependencies and priority issues between different domain names to avoid the optimization of secondary domain names interfering with or destroying the resolution of key domain names. In response to this situation, the system can introduce dependency analysis and optimization constraint mechanisms. Before adding a domain name to the quick wake-up list, check whether it has a strong dependency or conflict with the existing domain name, and reasonably arrange the optimization order and resource allocation according to the dependency graph to ensure that the optimization of the core domain name is not affected.

[0146] S204, when the business system enters the dormant state, keeping the DNS cache entry of the domain name in the quick wake-up list always valid;

[0147] When the business system enters the dormant state, the system keeps the DNS cache entries of the domain names in the quick wake-up list valid at all times, including:

[0148] Set the upper limit of the capacity of the quick wakeup list;

[0149] Calculate the time interval between the most recent access time of each domain name and the current time;

[0150] When the time interval exceeds the first preset time length, reducing the repetition count value of the corresponding domain name;

[0151] Delete domain names with duplicate count values ​​lower than a pre-designed value;

[0152] Before the DNS cache entry expires, update the resolution result through the external DNS server;

[0153] When the low power consumption module is in the active state for a duration exceeding a second preset time, detecting whether there is a pending DNS request;

[0154] If there is no pending DNS request, the low power module is switched to a sleep state;

[0155] Record the state switching time point and remaining power of the low-power module;

[0156] Count the average working time of low-power modules in different power ranges;

[0157] Set multiple working hours levels according to the average working hours;

[0158] When the remaining power is in different power ranges, the corresponding duration level is determined;

[0159] Record the actual work results after each adjustment;

[0160] The value range of the duration level is adjusted according to the actual work effect to obtain an adjusted second preset duration;

[0161] Generate a response message for the newly received DNS request and respond.

[0162] When the business system enters the dormant state, the system sets the DNS cache entries of the domain names in the quick wake-up list to always be valid to avoid DNS resolution delays caused by cache expiration during the dormant period. The purpose of this step is to minimize the impact of the dormant wake-up process on the resolution performance of key domain names and ensure that the business system can quickly recover to a usable state. Since the domain names in the quick wake-up list are all key objects that the business system relies on, even during the dormant period, it is necessary to maintain the validity and freshness of their cache as much as possible to reduce additional network requests and time overhead caused by cache failure.

[0163] When implementing this step, the system first needs to obtain the DNS cache entries corresponding to each domain name in the quick wake-up list, and extract its original TTL value and expiration timestamp. Then, the system updates the expiration timestamp of these cache entries to a special constant value (such as INT_MAX), indicating that it will never expire, and writes the updated cache entries back to the cache system. In this way, even during hibernation, the cache entries of these key domain names can always remain valid, avoiding additional network interactions and delays. At the same time, in order to prevent cache entries that never expire from occupying system resources for a long time, the system also needs to set an upper threshold to control the maximum capacity of the quick wake-up list, and regularly eliminate domain names that are no longer active or have a lower priority. In addition, the system also needs to monitor change information of external DNS services (such as TTL value adjustment, record update, etc.), and synchronize and update the local cache in a timely manner to ensure the consistency of cached data with authoritative data.

[0164] In the process of maintaining the validity of the domain name cache in the fast wake-up list, the following technical problems and challenges may be encountered: First, how to weigh the benefits and costs of the never-expiring strategy to avoid resource waste and data inconsistency risks caused by excessive caching. In response to this situation, the system can introduce a dynamic adjustment mechanism for the cache validity period. According to factors such as the importance of the domain name, the frequency of change, and the timeliness requirements, different cache validity periods can be set for different domain names. While improving the cache hit rate, expired or invalid data can also be eliminated in a timely manner. Second, how to ensure the continuous availability of key domain names and respond to abnormal situations such as network interruptions and server failures. In response to this situation, the system can introduce a multi-level cache and disaster recovery backup mechanism. In addition to local caching, it can also use distributed cache clusters, CDN and other technologies to provide multi-point disaster recovery and failover capabilities for key domain names. At the same time, the system can also establish a health check and fault notification mechanism with external DNS services. Once the authoritative service is found to be abnormal or unavailable, it can automatically switch to the backup cache or trigger the emergency plan to minimize the scope and duration of the failure.

[0165] S205: Dynamically update the number of repetitions of each domain name in the quick wakeup list.

[0166] The system needs to dynamically update the number of recurrences of each domain name in the quick wake-up list to adapt to changes in the business system operation mode and network environment. Since the access mode and network conditions of the business system are dynamically changing, the quick wake-up list also needs to keep pace with the times and promptly reflect the changing trends of the activity and importance of the domain name. Regularly updating the number of recurrences of domain names helps to discover new key domain names, eliminate domain names that are no longer frequently accessed, and maintain the effectiveness and timeliness of the list. This is also a process of continuous optimization and adaptive adjustment. Through continuous data collection, statistical analysis and strategy improvement, the quick wake-up mechanism can always keep up with business needs and performance requirements and achieve the best optimization effect.

[0167] When implementing this step, the system needs to establish a complete domain name statistics and update mechanism, which mainly includes the following key links: First, the system needs to continuously monitor the network requests of the business system, especially the first batch of requests after wake-up, extract key domain name information and timestamps, and update the corresponding request records. Secondly, the system needs to select an appropriate time window (such as daily, weekly, etc.), aggregate and count the request records within the specified time range, and calculate the number of repeated occurrences of each domain name and other key indicators. Thirdly, the system needs to compare the updated statistical results with the current fast wake-up list, identify the newly added high-frequency domain names and the low-frequency domain names that need to be eliminated, and adjust the list's membership composition and optimization strategy accordingly. Finally, the system also needs to set up some manual intervention and feedback mechanisms to allow administrators to make appropriate corrections and optimizations to the fast wake-up list based on business experience and performance diagnosis results to improve its applicability and reliability.

[0168] In the above embodiment, by recording the time points of the business system's sleep and wake-up and the corresponding number of DNS requests, analyzing the pattern of the first batch of DNS requests after the system wakes up, domain names that are repeated more than a preset number of times are added to the quick wake-up list. By keeping the DNS cache entries of the domain names in the quick wake-up list valid at all times in the sleep state, the system can directly use the cached DNS resolution results after waking up without waiting for the response of the external DNS server. This cache preheating mechanism based on access rules reduces the DNS resolution delay after the system wakes up, improves the response speed of the business system, and reduces network communication overhead and system power consumption. The mechanism of dynamically updating the number of domain name occurrences ensures that the quick wake-up list can adapt to changes in business access patterns, so that the system always maintains the optimal cache preheating effect.

[0169] The following describes the system in the embodiment of the present invention from the perspective of hardware processing. Figure 3 , which is a schematic diagram of the physical device structure of a low-power device DNS resolution system provided in an embodiment of the present application.

[0170] It should be noted that Figure 3The structure of the system shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0171] like Figure 3 As shown, the system includes a central processing unit (CPU) 301, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 302 or the program loaded from the storage part 308 to the random access memory (RAM) 303, such as executing the method in the above embodiment. In RAM 303, various programs and data required for system operation are also stored. CPU 301, ROM 302 and RAM 303 are connected to each other through bus 304. Input / output (I / O) interface 305 is also connected to bus 304.

[0172] The following components are connected to the I / O interface 305: an input section 306 including a camera, an infrared sensor, etc.; an output section 307 including a liquid crystal display (LCD) and a speaker, etc.; a storage section 308 including a hard disk, etc.; and a communication section 309 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 309 performs communication processing via a network such as the Internet. A drive 310 is also connected to the I / O interface 305 as needed. A removable medium 311, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 310 as needed so that a computer program read therefrom is installed into the storage section 308 as needed.

[0173] In particular, according to an embodiment of the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present invention includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication section 309, and / or installed from a removable medium 311. When the computer program is executed by a central processing unit (CPU) 301, various functions defined in the present invention are performed.

[0174] See also Figure 4 , which is a schematic diagram of a virtual device structure of a low-power device DNS resolution system provided in an embodiment of the present application.

[0175] The figure includes a low-power module (RTOS), a business system (Linux) and a physical connection part (SPI / SDIO / UART). The low-power module (RTOS) includes a logic processing module and a WIFI / 4G module. The logic processing module includes other low-power logic control modules and a DNS cache module, where the DNS cache sends a request to the actual DNS server to the WIFI / 4G module. The business system (Linux) includes a DNS proxy and business processing, and the business processing sends a DNS request to the DNS proxy.

[0176] The low-power module (RTOS) and the business system (Linux) are connected through the physical connection part (SPI / SDIO / UART) and forwarded through a private protocol. The private protocol between the business system and the low-power module is simply extended based on the application protocol carried by the existing hardware communication protocol (SPI / SDIO / UART). The request message needs to include the domain name to be resolved, and the response message includes the IP address and survival time (TTL) of the resolution result. The specific message format can be extended to include the above fields according to the existing communication protocol between the specific business system and the low-power module, and is not limited here.

[0177] It should be noted that the computer-readable medium shown in the embodiment of the present invention may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, device or device. In the present invention, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable computer program. Such a propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing.

[0178] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present invention. Among them, each box in the flowchart or block diagram can represent a module, a program segment, or a part of the code, and the above-mentioned module, program segment, or a part of the code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0179] As another aspect, the present invention further provides a computer-readable storage medium, which may be included in the system described in the above embodiment; or may exist independently without being assembled into the system. The above storage medium carries one or more computer programs, and when the above one or more computer programs are executed by a processor of a system, the system implements the method provided in the above embodiment.

[0180] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

[0181] As used in the above embodiments, the term "when..." may be interpreted to mean "if..." or "after..." or "in response to determining..." or "in response to detecting...", depending on the context. Similarly, the phrases "upon determining..." or "if (the stated condition or event) is detected" may be interpreted to mean "if determining..." or "in response to determining..." or "upon detecting (the stated condition or event)" or "in response to detecting (the stated condition or event)", depending on the context.

[0182] Those skilled in the art can understand that to implement all or part of the processes in the above-mentioned embodiments, the processes can be completed by computer programs to instruct related hardware, and the programs can be stored in computer-readable storage media. When the programs are executed, they can include the processes of the above-mentioned method embodiments. The aforementioned storage media include: ROM or random access memory RAM, magnetic disk or optical disk and other media that can store program codes.

Claims

1. A low-power device DNS resolution method, characterized in that: include: Configuring a default DNS server address of a business system of a low-power device as a local loopback address, wherein the business system includes a DNS proxy module, and the DNS proxy module is used to monitor a preset DNS port; When the DNS proxy module monitors a DNS request, it extracts the domain name information in the DNS request, and sends the request message containing the domain name information to the low-power module of the low-power device through a preset hardware communication protocol; Determine a hash value calculated by the low power consumption module according to the domain name information; Searching a preset storage space for a corresponding DNS cache entry based on the hash value, the DNS cache entry including the hash value, the survival time, and the IP address; If the corresponding DNS cache entry is found, determine whether the survival time of the DNS cache entry has expired; If the survival time has not expired, the IP address and the survival time in the DNS cache entry are returned to the DNS proxy module through the hardware communication protocol; If the corresponding DNS cache entry is not found or the survival time has expired, a DNS resolution request is initiated to an external DNS server; The IP address and survival time in the received resolution result and the hash value are combined into a new DNS cache entry and stored in the preset storage space; Returning the IP address and the survival time to the DNS proxy module through the hardware communication protocol; Generate a DNS response message according to the DNS protocol specification and respond to the DNS request.

2. The method according to claim 1, characterized in that The step of determining the hash value calculated by the low power consumption module according to the domain name information specifically includes: Receiving the data frame sent by the low power consumption module through the preset hardware communication protocol; Parsing the frame header and frame tail identifiers in the data frame, and extracting the fragment sequence number and the check code; Verifying the integrity of the data frame according to the check code; Reorganize the plurality of data frames according to the fragment sequence numbers; Determine the hash value from the reassembled data.

3. The method according to claim 1, characterized in that The step of searching for a corresponding DNS cache entry in a preset storage space based on the hash value specifically includes: Calculating the current storage capacity of the preset storage space; When the current storage capacity is less than a preset threshold, traversing the DNS cache entries; Calculate a weight value based on the access frequency and remaining survival time of each of the DNS cache entries; Sorting the DNS cache entries according to the weight values; The DNS cache entries with the lowest weight values ​​are deleted until the preset storage requirements are met.

4. The method according to claim 1, characterized in that: After generating a DNS response message according to the DNS protocol specification and responding to the DNS request, the method further includes: Record the sleep and wake-up time points of the business system and the corresponding number of DNS requests; When it is detected that the business system switches from a dormant state to an awake state, extract the first batch of DNS request records after the most recent N awakenings; Adding domain names in the first batch of DNS request records that appear more than a preset number of times to a quick wake-up list; When the service system enters the dormant state, keeping the DNS cache entry of the domain name in the quick wake-up list always valid; The number of repetitions of each domain name in the quick wake-up list is dynamically updated.

5. The method according to claim 4, characterized in that The step of keeping the DNS cache entry of the domain name in the quick wake-up list always valid specifically includes: Setting an upper limit value of the capacity of the quick wakeup list; Calculate the time interval between the most recent access time of each domain name and the current time; When the time interval exceeds a first preset duration, reducing a repetition count value of the corresponding domain name; Deleting the domain name whose repeat count value is lower than a pre-set value; Before the DNS cache entry expires, updating the resolution result through the external DNS server; Generate a DNS response message based on the updated resolution result and respond.

6. The method according to claim 5, characterized in that Before generating a DNS response message based on the updated resolution result and responding, the method further includes: When the low power consumption module is in the active state for a duration exceeding a second preset time, detecting whether there is a pending DNS request; If there is no pending DNS request, switching the low power consumption module to the sleep state; Recording the state switching time point and remaining power of the low power module; Adjusting the second preset duration based on the state switching time point and the remaining power; Generate a response message for the newly received DNS request and respond.

7. The method according to claim 6, characterized in that The adjusting the second preset duration based on the state switching time point and the remaining power specifically includes: Counting the average working time of the low-power module in different power ranges; Setting a plurality of duration levels according to the average working duration; When the remaining power is in different power intervals, determining corresponding duration levels; Record the actual work results after each adjustment; The value range of the duration level is adjusted according to the actual working effect to obtain an adjusted second preset duration.

8. A low-power device DNS resolution system, characterized in that: The system comprises: One or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to cause the system to execute the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that: When the instructions are executed on a system, the system is caused to execute the method according to any one of claims 1 to 7.

Images