Internet-of-things code distributed analysis method and system and storage medium

Abstract

The invention discloses an Internet of Things code distributed analysis method and system and a storage medium. The analysis method comprises Internet of Things code release and Internet of Things code analysis which are performed in sequence. The Internet of Things code publishing comprises the following steps: when an Internet of Things device end changes, publishing an Internet of Things code of the Internet of Things device end and corresponding analysis data to a distributed hash table network (DHT); and when the client needs to parse the Internet of Things code, executing an Internet of Things code parsing process. According to the method, a Kademlia routing algorithm of the DHT is utilized, a'provider mechanism 'is creatively adopted, only a lightweight'data provider index' is stored and distributed in the DHT, and when an Internet of Things code is queried, the DHT quickly returns a list of nodes holding code information. And the query party directly obtains the latest equipment information from the provider. The method is an extremely light-weight operation, almost takes effect in real time, and solves the problem of cache delay of a traditional DNS (Domain Name Server).

Description

A distributed resolution method, system and storage medium for IoT coding Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) coding and parsing technology, and more specifically, to a distributed IoT coding and parsing method, system, and storage medium based on a provider mechanism. Background Technology

[0002] With the rapid development of Internet of Things (IoT) technology, the number of devices connected to networks worldwide is growing exponentially. In this era of interconnected everything, every IoT device needs a unique identifier, namely an IoT code.

[0003] In order for these devices to be effectively managed and accessed, an efficient and reliable resolution system is essential. IoT code resolution refers to the process of querying and retrieving device information, network address, server endpoint, metadata, or other relevant attributes corresponding to a given IoT code. This is functionally similar to the Internet's DNS (Domain Name System).

[0004] Currently, the mainstream technical solutions for IoT coding and parsing, along with their shortcomings, can be summarized into two categories:

[0005] 1. Centralized database-based solutions (including clustered and federated systems): These solutions store codes and information in a central server cluster.

[0006] Its fundamental drawback lies in the bottleneck of centralization:

[0007] Poor scalability: It is difficult to cope with the scale of hundreds of billions of IoT devices, and horizontal scaling is complex and expensive; Single point of failure: The failure of the central node will lead to a wide range of service interruptions, and the fault tolerance is low.

[0008] 2. Scheme based on the traditional DNS system:

[0009] This type of solution attempts to apply domain name resolution. Its fundamental drawback lies in the update delays caused by caching.

[0010] Poor real-time performance: The TTL caching mechanism that DNS relies on means that changes to device IP, status and other information cannot take effect in real time (the delay can be several minutes to several hours), which is fatal for highly dynamic mobile IoT devices; Incompatible architecture: The tree-like hierarchical structure of DNS is not suitable for the massive flat coding space of IoT.

[0011] In summary, existing technologies have not solved the core challenge of how to perform low-latency, high-availability, and near-real-time parsing of highly dynamic IoT codes (such as frequent IP address changes) on a massive scale.

[0012] Chinese patent document (application number: 202310446847.1, application date: 2023.04.24) discloses a blockchain-based heterogeneous identifier resolution method for the industrial internet. The method includes: Step 1: The client initiates a heterogeneous identifier resolution request, the resolution request including an identifier protocol type and an identifier code; Step 2: After receiving the resolution request, the protocol type identifier first determines whether the identifier protocol type and the identifier code correspond. If they correspond, it is determined to be a valid request and proceeds to Step S3; otherwise, an encoding error message is returned; Step 3: It is determined whether the identifier code is an IIoT-DID identifier. If it is, the IIoT-DID identifier resolution component is directly called to interact with the blockchain for resolution. Otherwise, proceed to step S4; Step 4: Determine if an IIoT-DID identifier corresponding to the identifier code exists in the preset heterogeneous identifier protocol mapping table. If it exists, directly call the IIoT-DID identifier parsing component; otherwise, proceed to step S5; Step 5: Input the identifier code into the heterogeneous identifier parsing component for parsing, and output the carrier attribute information corresponding to the parsed identifier; Step 6: Input the carrier attribute information corresponding to the parsed identifier into the IIoT-DID identifier generation component to generate an IIoT-DID identifier and synchronize it on the blockchain; Write the mapping relationship between the newly generated IIoT-DID identifier and the requested identifier code into the heterogeneous identifier protocol mapping table, and update the heterogeneous identifier protocol mapping table. This scheme requires multiple verification steps and has a high parsing latency.

[0013] Therefore, how to solve the following problems has become an urgent technical issue in this field: 1. the centralization bottleneck problem, 2. the high availability and fault tolerance problem, 3. the high latency query problem, and 4. the dynamic data update problem. Summary of the Invention

[0014] In view of this, the present invention provides a distributed IoT coding parsing method, system, and storage medium based on a provider mechanism to solve the above-mentioned technical problems: 1. Centralization bottleneck problem, 2. High availability and fault tolerance problem, 3. High-latency query problem, and 4. Dynamic data update problem. This system consists of a large number of distributed DHT nodes, forming a P2P network. It utilizes the Kademlia routing algorithm of the Distributed Hash Table (DHT), but instead of directly storing the volatile IoT coding parsing data (Value) in the DHT network, it creatively employs a "provider mechanism," storing and distributing only a lightweight "data provider index" (Provider Record) within the DHT network.

[0015] In a first aspect, this application provides a distributed resolution method for IoT codes based on a provider mechanism, comprising sequential IoT code publishing and IoT code resolution;

[0016] The IoT code publishing includes: when changes occur on the IoT device, publishing the IoT code of the IoT device and the corresponding parsed data to a distributed hash table network, including the following process:

[0017] The IoT device starts up, connects to the preset seed node in the Distributed Hash Table (DHT) network, obtains the peer node identifier (PeerID) of the IoT device, and initializes the local routing table of the IoT device.

[0018] The IoT device stores preset key-value pairs in the IoT device to the local storage of the IoT device, wherein the key-value pairs include the IoT code and the parsed data corresponding to the IoT code;

[0019] The IoT device uses a standard hash algorithm to calculate the content ID of the IoT code. The content ID (CID) includes the peer identifier (PeerID) and network address of the IoT device.

[0020] The IoT device initiates a provisioning operation to the Distributed Hash Table (DHT) network, declaring itself as the provider of the content ID for the IoT code.

[0021] The Distributed Hash Table (DHT) network executes the search algorithm in the Kademlia algorithm to find K distributed hash table network nodes that are closest to the content ID of the IoT code in terms of XOR distance. Each distributed hash table network node stores the provider record, and K is the total number of nodes in the distributed hash table network that are closest to the content ID in terms of XOR distance, and K is no greater than 20.

[0022] The IoT code parsing includes the following process when the client needs to parse the IoT code:

[0023] The client initiates a query request for the IoT device identifier to the connected Distributed Hash Table (DHT) network, such as a GET / api / v1 / get / {Bcode-Device-SN-001} request;

[0024] The Distributed Hash Table (DHT) network that receives the query request uses the standard hash algorithm employed in the IoT code publication to calculate the content ID corresponding to the IoT device identifier (Bcode);

[0025] The client initiates a lookup provider index command in the Distributed Hash Table (DHT) network to find the IoT coded data provider index;

[0026] The Distributed Hash Table (DHT) network executes an iterative Kademlia query according to the lookup provider instruction to find the K distributed hash table network nodes that store the provider's records.

[0027] The distributed hash table network generates a provider list based on the query results and transmits it to the client. The provider record is the provider of the content ID. The client obtains the provider list, which includes the peer node identifier (PeerID) of the IoT device and the latest network address.

[0028] The client connects to the IoT device corresponding to the network address in the provider list and requests to obtain the original IoT code corresponding to the IoT device.

[0029] After receiving the request from the client, the IoT device searches for the IoT code in its local storage and returns the parsed data corresponding to the IoT code to the client.

[0030] Optionally, the IoT code publishing also includes dynamic updates, which include:

[0031] When the IP address of the IoT device changes, the IoT device stores the prepared key-value pair in its local storage, wherein the key-value pair includes IoT code and parsing data; the IoT device uses a standard hash algorithm to calculate the content ID of the IoT code; the IoT device initiates a provision operation to the Distributed Hash Table (DHT) network, declaring that the IoT device is the provider of the content ID of the IoT code.

[0032] Optionally, in the IoT coding publication, the preset key-value pairs include:

[0033] The IoT device side customizes the IoT code Key and the corresponding parsed data Value.

[0034] Optionally, the local storage may include a memory cache or LevelDB.

[0035] Optionally, the changes on the IoT device side include the IoT device going online or the IoT device side changing its information.

[0036] In a second aspect, this application provides an IoT coding distributed parsing system based on a provider mechanism, characterized in that the IoT coding distributed parsing system is used to execute the above-described IoT coding distributed parsing method;

[0037] The IoT coding distributed parsing system includes an IoT device subsystem, a distributed hash table (DHT) network subsystem, and a client subsystem;

[0038] The IoT device subsystem is coupled to the distributed hash table (DHT) network subsystem and is used to publish the IoT code and the corresponding parsing data of the IoT code to the distributed hash table (DHT) network subsystem, and to initiate a providing operation to the distributed hash table (DHT) network subsystem, declaring that the IoT device is the provider of the content ID of the IoT code;

[0039] The Distributed Hash Table (DHT) network subsystem is coupled to both the IoT device subsystem and the client subsystem. The DHT network subsystem executes the Kademlia algorithm to generate provider records for the content IDs of the IoT codes. Furthermore, the DHT network subsystem executes iterative queries within the Kademlia algorithm based on provider lookup instructions initiated by the client subsystem, forming the provider list which is then transmitted to the client subsystem.

[0040] The client subsystem is coupled to the IoT device subsystem and the distributed hash table (DHT) network subsystem, respectively. It is used to send a command to the distributed hash table (DHT) network subsystem to look up the provider index, obtain the provider list, and send a request to the IoT device subsystem to obtain the original IoT code corresponding to the IoT device based on the peer ID and the latest network address in the provider list, and obtain the parsing data corresponding to the original IoT code.

[0041] In a third aspect, this application provides a computer-readable storage medium storing a computer program or computer instructions that can be loaded by a processor and executed by the aforementioned IoT coding distributed resolution method based on the provider mechanism.

[0042] Compared with existing technologies, the IoT coding distributed parsing method, system, and storage medium provided by this invention, based on a provider mechanism, achieves at least the following beneficial effects:

[0043] First, extremely high availability and fault tolerance: The solution of this invention is completely decentralized, with no master node or central server. The parsing index (provider records) is distributed and stored on multiple nodes in the network. The offline or failure of a single or even a large number of nodes will not affect the normal operation of the entire parsing system, achieving extremely high fault tolerance;

[0044] Secondly, extremely high horizontal scalability: system capacity and performance are directly proportional to the number of nodes in the network. As the scale of devices increases, simply adding new resolution nodes to the DHT network can linearly increase the total capacity and concurrent processing capability of the system, solving the scalability problem of centralized architectures;

[0045] Third, efficient low-latency query: The solution of this invention adopts the Kademlia routing algorithm based on XOR distance, ensuring that the query complexity of any parsing request is only O(log N) (N is the total number of network nodes). This means that even in a network of tens of billions of nodes, the target index can be quickly located with very few network hops (usually less than 20 hops), achieving low-latency parsing globally;

[0046] Fourth, real-time dynamic data updates (core advantage): The core "provider mechanism" of this invention completely solves the problem of dynamic updates. The DHT network itself does not store large amounts of frequently changing device information (Value), but rather stores provider records of "who owns this information".

[0047] Of course, any product implementing this invention does not necessarily need to achieve all of the technical effects described above at the same time.

[0048] Other features and advantages of the invention will become clear from the following detailed description of exemplary embodiments of the invention with reference to the accompanying drawings. Attached Figure Description

[0049] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments of the invention and, together with their description, serve to explain the principles of the invention.

[0050] Figure 1 is a flowchart of a distributed parsing method for IoT coding based on a provider mechanism according to the present invention;

[0051] Figure 2 is a flowchart of the IoT coding distribution process in the IoT coding distributed parsing method of the present invention;

[0052] Figure 3 is a timing diagram of IoT coding deployment in the distributed resolution method of IoT coding of the present invention;

[0053] Figure 4 is a flowchart of the IoT coding parsing process in the distributed IoT coding parsing method of the present invention;

[0054] Figure 5 is a timing diagram of IoT coding parsing in the distributed IoT coding parsing method of the present invention;

[0055] Figure 6 is a schematic diagram of the connection between the subsystems in the IoT coding distributed parsing system of the present invention;

[0056] Figure 7 is a schematic diagram of the connection of each logical layer in the IoT coding distributed parsing system of the present invention. Detailed Implementation

[0057] Various exemplary embodiments of the present invention will now be described in detail with reference to the accompanying drawings. It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of the invention.

[0058] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit the invention or its application or use.

[0059] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0060] In all the examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values.

[0061] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0062] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of this disclosure, unless otherwise stated, "a plurality of" means two or more. Furthermore, the use of "based on" or "according to" implies openness and inclusiveness, because processes, steps, calculations, or other actions "based on" or "according to" one or more of the stated conditions or values ​​may in practice be based on additional conditions or beyond the stated values.

[0063] For ease of understanding, the terms or nouns involved in the embodiments of this invention will be introduced first.

[0064] DHT: Distributed Hash Table, is a decentralized distributed system infrastructure that distributes data (in the form of key-value pairs) across a large, dynamically changing network of nodes (in this application, a P2P network). Each node in the network is responsible for storing a portion of the data and collaborates to enable any participant to efficiently retrieve the corresponding value using the key without the need for a central server.

[0065] The Kademlia search algorithm finds the M closest known nodes to a given target node ID in a distributed network. Its core steps include: 1. Initialization: The query node selects *a* nodes from its routing table that are closest to the target ID. These *a* nodes form a set of active nodes. 2. Parallel query: The query node simultaneously sends asynchronous query requests to the *a* active nodes, asking: Which node in this routing table is closest to the target ID? 3. Iteration and update: Upon receiving a response, the query node adds the newly discovered node to a dynamic candidate node list. From this list, it selects the *a* closest nodes that have not yet been queried and continues to send the same query request to them. This "query-update-query" process iterates. 4. Termination condition: After one round of queries, if no new node is found that is closer than the currently known M closest nodes, the algorithm terminates, and the query node will have the M nodes closest to the target ID.

[0066] XOR distance: XOR distance is a rule used by Kademlia (Kad algorithm) to measure the "logical distance" between two nodes in a network. It uses the numerical value of the XOR operation result to represent the distance, and usually only requires O(logN) steps to locate the target among a massive number of nodes.

[0067] Standard Hash Algorithm: In this invention, the standard hash algorithm specifically refers to SHA-256 (Secure Hash Algorithm 256-bit). It is a cryptographic hash function that can convert an input of arbitrary length (such as an IoT coded string) into a fixed-length (256-bit, or 32-byte) binary sequence.

[0068] In existing technologies, the mainstream solutions for IoT encoding and resolution mainly include: centralized database-based solutions (including clustered and federated solutions) and solutions based on the traditional DNS system. Centralized database-based solutions store encoding and information in a central server cluster. Their fundamental drawback lies in the centralization bottleneck, specifically including: poor scalability (difficult to handle the scale of hundreds of billions of IoT devices; horizontal scaling is complex and expensive); single point of failure (failure of the central node will lead to widespread service interruption; low fault tolerance). Solutions based on the traditional DNS (Domain Name System) system attempt to apply domain name resolution. Their fundamental drawback is the update delay caused by caching, specifically including: poor real-time performance (the TTL caching mechanism relied upon by DNS means that changes to device IP, status, and other information cannot take effect in real time (delays can reach several minutes to several hours), which is fatal for highly dynamic mobile IoT devices); and architectural mismatch (the tree-like hierarchical structure of DNS is not suitable for the massive, flat encoding space of the IoT). Existing technologies have not solved the core challenge of how to perform low-latency, high-availability, and near-real-time parsing of highly dynamic IoT codes (such as frequent IP address changes) on a massive scale.

[0069] This application proposes a distributed parsing method and system for IoT coding based on a provider mechanism, aiming to solve the following core technical problems:

[0070] 1. Solving the centralized bottleneck problem: How to build a parsing system without single points of failure and performance bottlenecks, so that it can be horizontally scaled to support hundreds of billions of IoT codes;

[0071] 2. Solve high availability and fault tolerance issues: How to ensure that the system can still provide stable and uninterrupted parsing services when some nodes (servers) fail;

[0072] 3. Solving the high-latency query problem: How to provide low-latency encoding and parsing services for globally distributed IoT devices, regardless of the device's location;

[0073] 4. Solve the problem of dynamic data updates: How to support the second-level fast updates and real-time queries of network addresses, status and other information of IoT devices (especially mobile devices) and get rid of the TTL caching latency limitation of traditional DNS.

[0074] It should be noted that in this invention, the IoT device side specifically refers to the business system / management platform that manages low-power hardware devices. The IoT device acts as a provider in this invention, that is, the device / IoT device acts as a provider node; the "DHT network" is a cluster composed of a large number of servers, and the "DHT node" is a server. The DHT network stores the location index of the "provider" and redundantly stores K backups. The DHT network also has the function of receiving HTTP query requests.

[0075] Referring to Figures 1-7, Figure 1 is a flowchart of an IoT code distributed parsing method based on a provider mechanism according to the present invention; Figure 2 is a flowchart of IoT code publishing in the IoT code distributed parsing method of the present invention; Figure 3 is a timing diagram of IoT code publishing in the IoT code distributed parsing method of the present invention; Figure 4 is a flowchart of IoT code parsing in the IoT code distributed parsing method of the present invention; Figure 5 is a timing diagram of IoT code parsing in the IoT code distributed parsing method of the present invention; Figure 6 is a schematic diagram of the connection of each subsystem in the IoT code distributed parsing system of the present invention; Figure 7 is a schematic diagram of the connection of each logic layer in the IoT code distributed parsing system of the present invention.

[0076] As shown in Figures 1-5, this embodiment provides a distributed resolution method for IoT codes based on a provider mechanism. The distributed resolution method for IoT codes includes sequential IoT code publishing and IoT code parsing (as shown in Figure 1).

[0077] S100, IoT code publishing (as shown in Figure 2) includes: When changes occur on the IoT device, the IoT code of the IoT device and the corresponding parsed data of the IoT code are published to the distributed hash table network, including the following process:

[0078] S101. The IoT device starts up, connects to the preset seed node in the Distributed Hash Table (DHT) network, obtains the peer node identifier (PeerID) of the IoT device, and initializes the local routing table of the IoT device.

[0079] S102, The IoT device stores the preset key-value pairs (S1021) in the local storage of the IoT device (S1022), wherein the key-value pairs include IoT codes and the parsing data corresponding to the IoT codes;

[0080] S103. The IoT device uses a standard hash algorithm to calculate the content ID of the IoT code. The content ID (CID) includes the peer identifier (PeerID) and network address of the IoT device.

[0081] S104. The IoT device initiates a provisioning operation to the Distributed Hash Table (DHT) network, declaring that the IoT device is the provider of the IoT-coded content ID;

[0082] S105. The Distributed Hash Table (DHT) network executes the Kademlia algorithm (Kad algorithm for short) to find the K distributed hash table network nodes that are closest to the IoT-encoded content ID in terms of XOR distance. Each of the distributed hash table network nodes stores the provider record, and K is the total number of nodes in the distributed hash table network that are closest to the content ID in terms of XOR distance. K is not greater than 20.

[0083] S200, IoT code parsing (as shown in Figure 4) includes: When the client needs to parse the IoT code, the following process is executed:

[0084] S201. The client initiates a query request for the IoT device identifier to the connected Distributed Hash Table (DHT) network; for example: GET / api / v1 / get / {Bcode-Device-SN-001} request;

[0085] S202. The Distributed Hash Table (DHT) network that receives the query request uses the standard hash algorithm adopted in the IoT code publishing to calculate the content ID corresponding to the IoT device identifier (Bcode);

[0086] S203. The client initiates a query provider index command in the Distributed Hash Table (DHT) network to find the IoT coded data provider index;

[0087] S204. The Distributed Hash Table (DHT) network executes a Kademlia iterative query based on the lookup provider instruction to find the K distributed hash table network nodes storing the provider's records.

[0088] S205. The distributed hash table network generates a list of providers based on the query results and transmits it to the client. The provider record is the provider of the content ID.

[0089] The client obtains a list of providers, which includes the peer identifier (PeerID) of the IoT device and the latest network address;

[0090] S206. The client connects to the IoT device corresponding to the network address in the provider list and requests to obtain the original IoT code corresponding to the IoT device.

[0091] S207. After receiving the request from the client, the IoT device searches for the IoT code in its local storage and returns the parsed data corresponding to the IoT code to the client.

[0092] It should be noted that in this invention, the IoT code (Key) is the unique identifier (Bcode) of the IoT device; the parsed data (Value) encodes the corresponding device information, such as {"ip": "1.2.3.4", "port": 9001, "status": "online", "location": "..."}. It's important to note that this data is not stored in the DHT network, but rather locally on the provider node; the content ID (CID) is a content identifier (cid.Cid) generated from the IoT code (Key) using a hash function (such as SHA-256). The CID is the "logical index address" of the data in the DHT network; and the provider record is the core data structure of this invention. It is a tuple (CID, PeerID), indicating that the node corresponding to the PeerID possesses the data corresponding to the CID. The DHT network primarily stores and distributes this record.

[0093] It should be noted that, in this invention, initializing the local routing table of the IoT device is a step in the IoT device node initialization process, which is a standardized P2P procedure, specifically including:

[0094] 1. Identity Generation: IoT device nodes generate asymmetric encryption key pairs and calculate a globally unique identity identifier, PeerID, based on the public key using a hash algorithm;

[0095] 2. Connecting to Seed Nodes: The IoT device node loads a pre-configured list of seed node (Bootstrap Nodes) addresses and establishes an initial connection with them to enter the P2P network;

[0096] 3. Route table refresh (Self-lookup): IoT device nodes initiate a lookup request for their own PeerID to the connected seed nodes. According to the Kademlia algorithm logic, this process will induce nodes along the way to return information of nodes that are close to them.

[0097] 4. K-bucket filling: IoT device nodes store the obtained neighbor node information (including IP address, port, PeerID and XOR distance) into the local routing table (K-buckets) according to distance, completing the initial construction of the network topology.

[0098] It should be noted that in step S106, this index record is redundantly stored on each node. The significance of searching K network nodes is: 1. Anti-fluctuation: Nodes in a P2P network may come online or go offline at any time; 2. High availability: By redundantly backing up this index record on K nodes, as long as one of them is still active, external parsing requests can find the real device by following the index.

[0099] Specifically, in this embodiment, the overall process of the IoT coding distributed parsing method based on the provider mechanism is divided into an IoT coding publishing process and an IoT coding parsing process, wherein:

[0100] S100, the IoT code publishing process includes: when an IoT device (or its proxy gateway) goes online or its information changes, it needs to publish its code and corresponding parsing data to the DHT network, as shown in Figure 2:

[0101] S101 Joining the Network: The device node starts up, connects to the seed node (Bootstrap Nodes) of the DHT network, obtains its own PeerID, and initializes the local routing table (K-bucket).

[0102] S1021. Prepare data: Nodes define their IoT code (Key) and corresponding parsed data (Value):

[0103] Key = "Bcode-Device-SN-001";

[0104] Value = {"ip": "114.114.114.114", "port": 8080}.

[0105] S1022, Local Storage: The provider node (IoT device) stores the (Key, Value) key-value pair in its own local storage (such as a memory cache or LevelDB).

[0106] S103. Calculate CID: The provider node (IoT device) uses a standard hash algorithm to calculate the content ID (CID) of the key:

[0107] CID = generateCID("Bcode-Device-SN-001").

[0108] S104, Declaring the Provider (Core): This is the publishing step of the "Provider Mechanism". The node does not write the large Value to the DHT network. Instead, it initiates a Provide operation to the DHT network, declaring itself as the provider of the CID, dht.Provide(ctx, CID, true).

[0109] S105. Provider Record Storage: The DHT network executes the Kademlia lookup algorithm to find K (e.g., K=20) nodes that are closest to the CID in terms of XOR distance. These K nodes will store a provider record: (CID, PeerID of the device node, and network address).

[0110] As shown in Figure 3, the IoT coding release process is implemented through IoT devices and a DHT network. The main process includes: the IoT device, acting as a provider node, stores key-value pairs (Key, Value) in local storage (S103); and calculates the CID (Content ID) of the Key using a standard hash algorithm (S104); the device (provider node) initiates a Provide (CID) declaration to the DHT network, declaring itself as the provider of the CID (S105). After receiving the declaration, the DHT network executes the Kademlia lookup algorithm to find the K nodes closest to the CID. Based on the lookup results, the DHT network stores the "Provider Record" (CID). - PeerID), and send a "successful declaration" message to the device (provider node) (S106).

[0111] The IoT code parsing process includes the following steps when an application or another device needs to parse a certain IoT code (as shown in Figure 4):

[0112] S201, Initiate a request: The client initiates a query request to any of the DHT nodes it is connected to: GET / api / v1 / get / {Bcode-Device-SN-001} request.

[0113] S202, Calculate CID: The DHT node receiving the request uses the same hash algorithm as when it was published to calculate the CID corresponding to the Bcode.

[0114] S203, Find Provider (Core): This is the parsing step of the "Provider Mechanism". The client node initiates a FindProviders operation in the DHT network, the purpose of which is not to find data (Value), but to find the index (Provider Record);

[0115] providers = dht.FindProviders(ctx, CID).

[0116] S204. Iterative Query: The DHT network node executes the iterative query in the Kademlia algorithm, and quickly finds the K nodes that stored the CID provider record in step S106 within O(log N) steps (where N is the total number of network nodes).

[0117] S205. Obtain the list of providers: K nodes return the provider records they store. The query nodes are aggregated to obtain a list containing the PeerID of "Device SN-001" (i.e., the publisher) and its latest network address (115.115.115.115).

[0118] S206, Direct Data Acquisition: The query node (or the original client) directly connects to the provider (115.115.115.115) and requests the original Key ("Bcode-Device-SN-001").

[0119] S207. Returning Data: The provider node searches for the Key in its local storage and returns the corresponding Value ({"ip": "115.115.115.115", ...}) to the querying party.

[0120] S208, Parsing complete: The client receives the latest parsed data, free from cache contamination.

[0121] As shown in Figure 5, the timing diagram for IoT code parsing is as follows: The main process of IoT code parsing includes:

[0122] S201. The client (querying party) initiates a query request to any of the DHT network nodes it is connected to;

[0123] S202. The DHT network node receiving the query request uses the same hash algorithm as when it was published to calculate the CID (Content ID) corresponding to the Bcode.

[0124] S204. The DHT network uses the FindProviders (CID) instruction to locate the node storing the CID record. The FindProviders (CID) instruction is initiated by the client (querying party) in the DHT network as a FindProviders operation (S203) to obtain the IoT coding data provider index (Provider Record).

[0125] S205. Retrieve and obtain provider records, and return the obtained provider records (Provider). - PeerID (address) client (queryer), specifically to obtain the provider's PeerID and latest network address;

[0126] S206. The client (queryer) directly requests the device (provider node) based on the address in the provider record to obtain the original IoT code (Key).

[0127] S207. The device (provider node) searches for the Key in local storage according to the client's request and obtains the corresponding parsed data (Value); and returns the latest parsed data to the client (queryer).

[0128] In some optional embodiments provided by the present invention, the IoT code publishing also includes dynamic updates, which include:

[0129] When the IP address of an IoT device changes, the IoT device stores the prepared key-value pair in its local storage. The key-value pair includes IoT code and parsing data. The IoT device uses a standard hash algorithm to calculate the content ID of the IoT code. The IoT device initiates a provision operation to the Distributed Hash Table (DHT) network, declaring itself as the provider of the content ID of the IoT code.

[0130] Specifically, for dynamic updates, such as when the device's IP address changes from 114.114.114.114 to 115.115.115.115, the entire IoT code publishing process only requires repeating steps S103 to S105. The "provider record" stored in the DHT network will be updated to the device's new network address, and the old record will expire. This process is extremely fast, achieving near real-time updates.

[0131] In some optional embodiments provided by the present invention, the preset (S1021) of key-value pairs in the IoT coding publication includes:

[0132] The IoT device side can customize the IoT code key and the corresponding parsed data value.

[0133] In some optional embodiments provided by the present invention, local storage includes a memory cache or a key-value pair storage database.

[0134] It should be noted that in this invention, the key-value pair storage database is LevelDB, which is an open-source key-value pair storage database from Google.

[0135] In some optional embodiments provided by the present invention, changes on the IoT device side include the IoT device going online or changes to IoT device information.

[0136] In one embodiment, an IoT coding distributed resolution system based on a provider mechanism is provided, which consists of a large number of distributed DHT nodes that together form a P2P network;

[0137] The IoT coding distributed resolution system is used to execute the above-mentioned IoT coding distributed resolution method;

[0138] As shown in Figure 6, the IoT coding distributed parsing system includes an IoT device subsystem 100, a distributed hash table (DHT) network subsystem 200, and a client subsystem 300.

[0139] The IoT device subsystem 100 is coupled to the distributed hash table (DHT) network subsystem 200. It is used to publish the IoT code and the corresponding parsing data of the IoT code to the distributed hash table (DHT) network subsystem 200, and to initiate a provision operation to the distributed hash table (DHT) network subsystem 200, declaring that the IoT device is the provider of the content ID of the IoT code.

[0140] The Distributed Hash Table (DHT) network subsystem 200 is coupled to the IoT device subsystem 100 and the client subsystem 300, respectively. The Distributed Hash Table (DHT) network subsystem 200 is used to execute the Kademlia algorithm to generate provider records of IoT-coded content IDs. The Distributed Hash Table (DHT) network subsystem 200 is also used to execute the iterative query in the Kademlia algorithm according to the provider lookup instruction initiated by the client subsystem 300, and form a provider list to be transmitted to the client subsystem 300.

[0141] The client subsystem 300 is coupled to the IoT device subsystem 100 and the distributed hash table (DHT) network subsystem 200, respectively. It is used to send a provider index lookup command to the distributed hash table (DHT) network subsystem 200 to obtain the provider list. Based on the peer node identifier (PeerID) and the latest network address in the provider list, it sends a request to the IoT device subsystem 100 to obtain the original IoT code corresponding to the IoT device and obtain the parsing data corresponding to the original IoT code.

[0142] Specifically, in this embodiment, an IoT coding distributed parsing system based on a provider mechanism is logically divided into four layers, as shown in Figure 7:

[0143] C1, Network Layer: Based on the libp2p protocol stack, it is responsible for P2P communication, encryption (TLS / Noise), and transmission (TCP / QUIC) between nodes.

[0144] C2, DHT Core Layer: Implements the Kademlia DHT algorithm. Each node maintains a routing table (K-buckets) based on XOR distance for efficient node lookup. This is the routing foundation of the "provider mechanism";

[0145] C3. Application Logic Layer: Encapsulates the core logic for implementing the "provider mechanism", including the "Provide" and "FindProviders" requests for IoT coding;

[0146] C4. Interface Layer (HTTP API Layer): Provides RESTful APIs (such as POST / api / v1 / set and GET / api / v1 / get / {key}) for IoT applications or devices to call.

[0147] In one embodiment, a computer-readable storage medium is provided, storing a computer program or computer instructions, wherein the computer program or computer instructions are configured to load and execute the steps in any of the above-described embodiments of the IoT code distributed resolution method based on the provider mechanism: S100, IoT code publishing includes: when changes occur on the IoT device, publishing the IoT code of the IoT device and the corresponding resolution data to the distributed hash table network, including the following process: S101, the IoT device starts up, connects to a preset seed node in the distributed hash table (DHT) network, and obtains the peer node identifier (Pee) of the IoT device. S103. The IoT device initializes its local routing table using the pre-defined key-value pairs (S102) and stores them in its local storage. Each key-value pair includes the IoT code and its corresponding parsing data. S104. The IoT device calculates the content ID (CID) of the IoT code using a standard hash algorithm. The content ID includes the peer identifier (PeerID) and network address. S105. The IoT device initiates a provision operation to the Distributed Hash Table (DHT) network, declaring itself as the provider of the content ID for the IoT code. S106. The Distributed Hash Table (DHT) network executes the... The Kademlia search algorithm is used to find K distributed hash table network nodes that are closest to the content ID of the IoT code in terms of XOR distance. Each of these distributed hash table network nodes stores a provider record. S200, IoT code parsing includes: when a client needs to parse the IoT code, the following process is executed: S201, the client initiates a query request for the IoT device identifier to the connected distributed hash table (DHT) network; S202, the distributed hash table (DHT) network receiving the query request uses the standard hash algorithm used in IoT code publishing to calculate the content ID corresponding to the Bcode; S203, the client retrieves the content ID from the distributed hash table (DHT). S204: The network initiates a provider index lookup command to find the IoT code data provider index; S205: The Distributed Hash Table (DHT) network executes a Kademlia iterative query according to the provider lookup command to find the K distributed hash table network nodes storing provider records; S206: A provider list is formed and transmitted to the client, where the provider record is the provider of the content ID; The client obtains the provider list, which includes the peer node identifier (PeerID) of the IoT device and the latest network address; S207: The client connects to the IoT device corresponding to the network address in the provider list and requests to obtain the original IoT code corresponding to the IoT device.S207. After receiving the request from the client, the IoT device looks up the IoT code in its local storage and returns the parsed data corresponding to the IoT code to the client.

[0148] In some optional embodiments provided by the present invention, the computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0149] As can be seen from the above embodiments, the IoT coding distributed parsing method, system, and storage medium based on the provider mechanism provided by the present invention achieves at least the following beneficial effects:

[0150] The core of this solution lies in utilizing the Kademlia routing algorithm of the Distributed Hash Table (DHT), but instead of directly storing the volatile IoT coded parsing data (Value) in the DHT network, it creatively adopts a "Provider Mechanism" to store and distribute only a lightweight "Data Provider Index" (Provider Record) in the DHT network.

[0151] Specific beneficial effects include:

[0152] 1. Extremely high availability and fault tolerance: The solution of this invention is completely decentralized, with no master node or central server. The parsing index (provider records) is distributed and stored on multiple nodes in the network. The offline or failure of a single or even a large number of nodes will not affect the normal operation of the entire parsing system, achieving extremely high fault tolerance;

[0153] 2. Extremely high horizontal scalability: System capacity and performance are directly proportional to the number of nodes in the network. As the scale of devices increases, simply adding new resolution nodes to the DHT network can linearly increase the total capacity and concurrent processing capability of the system, solving the scalability problem of centralized architectures;

[0154] 3. Highly efficient low-latency query: The solution of this invention adopts the Kademlia routing algorithm based on XOR distance, ensuring that the query complexity of any parsing request is only O(log N) (N is the total number of network nodes). This means that even in a network of billions of nodes, the target index can be quickly located with very few network hops (usually less than 20 hops), achieving low-latency parsing globally.

[0155] 4. Real-time dynamic data updates (core advantage): The core "provider mechanism" of this invention completely solves the problem of dynamic updates. The DHT network itself does not store large amounts of frequently changing device information (Value), but rather stores provider records of "who owns this information" (Provider Record).

[0156] 5. When an IoT key is queried, the DHT network quickly returns a list of nodes (i.e., providers) holding that key information. The querying party then directly obtains the latest device information (value) from the provider. When device information (such as IP address) changes, the device node only needs to redeclare itself as the "provider" of that key in the DHT network. This is an extremely lightweight operation, taking effect almost instantly, completely solving the caching latency problem of traditional DNS.

[0157] While specific embodiments of the invention have been described in detail by way of examples, those skilled in the art should understand that the examples are for illustrative purposes only and not intended to limit the scope of the invention. Those skilled in the art should understand that modifications can be made to the above embodiments without departing from the scope and spirit of the invention. The scope of the invention is defined by the appended claims.

Claims

1. A distributed resolution method for IoT coding based on a provider mechanism, characterized in that, This includes sequential IoT code publishing and IoT code parsing. The IoT code publishing includes: when an IoT device undergoes changes, publishing the IoT code of the IoT device and the corresponding parsed data to a distributed hash table network, including the following process: the IoT device starts up, connects to a preset seed node in the distributed hash table network, obtains the peer node identifier of the IoT device, and initializes the local routing table of the IoT device; the IoT device stores preset key-value pairs in its local storage, wherein the key-value pairs include the IoT code... The IoT device uses a standard hash algorithm to calculate the content ID of the IoT code, which includes the peer node identifier and network address of the IoT device. The IoT device then initiates a provision operation to the distributed hash table network, declaring itself as the provider of the content ID of the IoT code. The distributed hash table network executes the Cadmillian algorithm to find K distributed hash table network nodes that are closest to the content ID of the IoT code in terms of XOR distance. Each distributed hash table network node stores a provider record. K is the total number of nodes in the distributed hash table network that are closest to the content ID in terms of XOR distance, and K is no greater than 20; the IoT code parsing includes: when the client needs to parse the IoT code, the following process is executed: the client initiates a query request for the IoT device identifier to the connected distributed hash table network; the distributed hash table network receiving the query request uses the standard hash algorithm used in the IoT code publishing to calculate the content ID corresponding to the IoT device identifier; the client initiates a lookup provider index instruction in the distributed hash table network to look up the IoT code data provider index; the distributed hash table network executes an iterative query of the Cadmillian algorithm according to the lookup provider instruction. The system searches for K distributed hash table network nodes recorded by the storage provider; the distributed hash table network forms a provider list based on the query results and transmits it to the client, wherein the provider record is the provider of the content ID; the client obtains the provider list, which includes the peer node identifier and the latest network address of the IoT device; the client connects to the IoT device corresponding to the network address in the provider list and requests to obtain the original IoT code corresponding to the IoT device; after accepting the client's request, the IoT device searches for the IoT code in its local storage and returns the parsed data corresponding to the IoT code to the client.

2. The distributed parsing method for IoT coding according to claim 1, characterized in that, The IoT code publishing also includes dynamic updates, which include: when the IP address of the IoT device changes, the IoT device stores the prepared key-value pair in its local storage, wherein the key-value pair includes the IoT code and parsing data; the IoT device calculates the content ID of the IoT code using a standard hash algorithm; and the IoT device initiates a provision operation to the distributed hash table network, declaring itself as the provider of the content ID of the IoT code.

3. The distributed resolution method for IoT coding according to claim 1, characterized in that, In the IoT code publishing process, the preset key-value pairs include: the IoT device's custom IoT code and the corresponding parsing data.

4. The distributed resolution method for IoT coding according to claim 1, characterized in that, The local storage includes a memory cache or a key-value pair storage database.

5. The distributed parsing method for IoT coding according to claim 1, characterized in that, The changes on the IoT device side include the IoT device going online or the IoT device information being changed.

6. A distributed IoT coding parsing system based on a provider mechanism, characterized in that, The IoT code distributed parsing system is used to execute the IoT code distributed parsing method according to any one of claims 1 to 5; the IoT code distributed parsing system includes an IoT device subsystem, a distributed hash table network subsystem, and a client subsystem; the IoT device subsystem is coupled to the distributed hash table network subsystem and is used to publish the IoT code of the IoT device and the parsing data corresponding to the IoT code to the distributed hash table network subsystem, and to initiate a providing operation to the distributed hash table network subsystem, declaring that the IoT device is the provider of the content ID of the IoT code; the distributed hash table network subsystem is coupled to both the IoT device subsystem and the client subsystem, and the distributed hash table network subsystem is used to execute The Cadmillian algorithm generates provider records for the content ID of the IoT code. The distributed hash table network subsystem is also used to execute iterative queries in the Cadmillian algorithm according to the provider lookup command initiated by the client subsystem, forming the provider list and transmitting it to the client subsystem. The client subsystem is coupled to the IoT device subsystem and the distributed hash table network subsystem respectively, and is used to initiate a provider index lookup command to the distributed hash table network subsystem to obtain the provider list. Based on the peer node identifiers and the latest network addresses in the provider list, the client subsystem initiates a request to the IoT device subsystem to obtain the original IoT code corresponding to the IoT device, and obtains the parsing data corresponding to the original IoT code.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program or computer instructions that can be loaded by a processor and executed by the IoT coding distributed resolution method based on the provider mechanism as described in any one of claims 1 to 5.

Images