Optimal service discovery method, medium and device based on explicit multicast assistance

Abstract

The present invention discloses an optimal service discovery method, medium and device based on explicit multicast assistance. The method comprises: a user terminal obtains a list of IP addresses of target servers through DNS query and caches the list; based on the real-time network topology, a Dijkstra algorithm is used to generate a shortest path tree from the user terminal to all target servers; an explicit multicast message with a target IP list is constructed in the header, and an intermediate router splits the message into unicast or sub-multicast messages according to the next-hop interface; the user terminal determines the optimal server by monitoring the first valid response message. The present invention replaces the traditional multicast address with explicit multicast, saves address resources and reduces network duplication traffic, and combines dynamic path tree optimization and intelligent message splitting mechanism to significantly shorten service discovery delay. The invention is suitable for high-concurrency scenarios such as distributed CDN, Internet of Things and live video, effectively reducing bandwidth consumption and improving service reliability.

Description

Technical Field

[0001] The present invention relates to the field of distributed networks, and in particular to an optimal service discovery method based on explicit multicast assistance, a computer-readable storage medium, and an electronic device. Background Art

[0002] With the rapid development of mobile Internet, Internet of Things and distributed service technologies, high-concurrency scenarios such as warehousing and logistics, online shopping, and live video streaming are increasingly demanding service reliability and low latency. Currently, distributed CDN networks achieve localized access to content through service localization, but their core still relies on unicast communication mechanisms, which have the following technical bottlenecks: (1) The contradiction between multicast address resource exhaustion and network congestion is exacerbated: Traditional multicast technology relies on Class D IP addresses to achieve "one-to-many" communication, but the large-scale application of scenarios such as live video streaming and online conferencing has led to a serious shortage of multicast addresses. At the same time, the massive repeated data transmission in unicast mode exacerbates network congestion and increases bandwidth costs.

[0003] (2) Inefficient dynamic service discovery: Existing service discovery mechanisms (such as DNS polling and unicast detection) require initiating requests to target servers one by one, generating a large amount of redundant traffic in cross-region service calls.

[0004] To solve the above problems, explicit multicast ( ) technology came into being, which can save 90% of address resources by carrying the target IP list in the message header instead of the multicast address. The solution lacks deep integration with dynamic service discovery and path optimization, resulting in an overly large target server IP list and slow optimal service response. Summary of the Invention

[0005] Therefore, it is necessary to provide a technical solution for optimal service discovery based on explicit multicast assistance to solve the problems that the existing technology lacks. The solution that is deeply integrated with dynamic service discovery and path optimization leads to the problem of slow optimal service response speed.

[0006] To achieve the above objectives, in a first aspect, the present application provides an optimal service discovery method based on explicit multicast assistance, the method comprising the following steps:

[0007] S1: The client sends a DNS query request for the target service to the DNS server to obtain a target IP list, which contains the IP address information of all target servers;

[0008] S2: The client receives the feedback result of the DNS target server for the DNS query request, parses and caches the target IP list;

[0009] S3: Based on the network topology, with the user terminal as the source node and all target servers as target nodes, generate a shortest path tree from the user terminal to each target server using the Dijkstra algorithm;

[0010] S4: constructing an explicit multicast message, wherein the header of the explicit multicast message includes the target IP list, and the payload of the explicit multicast message is a probe request message;

[0011] S5: The intermediate router sends the explicit multicast message along the shortest path tree, parses the target IP list in the header field of the explicit multicast message, and splits the explicit multicast message into unicast messages or explicit multicast sub-messages according to the next-hop interface until all messages are unpacked and forwarded to the target server;

[0012] S6: The user end monitors the response messages from each target server to the detection request message, and the target server corresponding to the first valid response message that arrives is the optimal server.

[0013] Furthermore, step S5 includes:

[0014] S51: The intermediate router parses the header field of the explicit multicast message and extracts the target IP list, which is recorded as {IP1, IP2, ..., IP m}, m is a positive integer, indicating the number of target servers;

[0015] S52: The intermediate router performs the longest prefix match on the target IP address according to the real-time routing table and the path tree, and generates the next hop interface group G1, G2, ..., G N , N is a positive integer, indicating the number of next-hop interface groups, where the i-th hop interface group is represented by G i Indicates that the value range of i is [1, N];

[0016] S53: The intermediate router groups G for each next-hop interface i Do the following:

[0017] If group G i If there is only one target server in the packet and the IP address of the target server is reachable through the same path, a unicast message is generated, the IP header destination address of the unicast message is set to the unique IP address of the target server in the packet, and the payload of the unicast message retains the original probe request message;

[0018] If group G i If there are multiple target server IP addresses and the packet needs to be forwarded through an intermediate node on the same path, an explicit multicast sub-message is generated. The IP header extension field of the explicit multicast sub-message contains all the target server IP addresses of the packet, and the payload of the explicit multicast sub-message retains the original probe request message.

[0019] S54: The intermediate router forwards the unicast message or the explicit multicast sub-message to the next hop interface or the target server, and updates the shortest path weights of the affected nodes in the path tree based on the incremental Dijkstra algorithm;

[0020] Repeat steps S51-S54 until all explicit multicast messages or sub-messages are decapsulated as unicast messages and transmitted to the target server, and the .

[0021] Furthermore, step S531 is further included between step S53 and step S54:

[0022] The intermediate router performs HMAC-SHA256 signature verification on the generated unicast message or explicit multicast sub-message. If the signature is invalid, the router discards the message and generates an ICMP error message and returns it to the user.

[0023] Furthermore, step S52 includes:

[0024] The intermediate router extracts the target IP list and caches it in the routing table of the router. The entry format of the routing table is [prefix, next hop interface].

[0025] Perform an LPM query on each target server's IP address. This includes matching the prefix entry with the longest mask, finding the prefix that longest matches the target server's IP address, recording the corresponding next-hop interface, establishing a mapping between the target server's IP address and the next-hop interface, and storing the mapping in a temporary cache.

[0026] Using the next-hop interface as the key and the target server's IP address as the value, the target IP addresses sharing the same next-hop interface are merged into the same group, and parallel LPM queries are performed on the target IP list.

[0027] Furthermore, after the next-hop interface grouping, the method further includes:

[0028] Perform integrity checks based on the groups to ensure that all target server IP addresses have corresponding groups and meet the following formula conditions: ;

[0029] If there is no corresponding matching route for the IP address of a certain target server, a first prompt message is generated and fed back to the user end, where the first prompt message is used to prompt that the ICMP destination is unreachable;

[0030] If the explicit multicast sub-message cannot be unpacked at a subsequent node, the IP address of the target server in the header field of the explicit multicast sub-message is extracted to generate log information and the explicit multicast sub-message is discarded, and a second prompt information is generated and fed back to the user end. The second prompt information is used to indicate the reason why the message cannot be unpacked and the log information.

[0031] Furthermore, updating the shortest path weights of affected nodes in the path tree based on the incremental Dijkstra algorithm includes:

[0032] Real-time monitoring of network link status change events, including link status change times including any one or more of link cost updates, node failures, or newly added links;

[0033] Extract the affected edge v in the link from the link state change event, mark all nodes in the path tree that depend on this edge as affected nodes, and obtain the set V affected , where any link node v∈V affected The original shortest path passes through the changed link;

[0034] For each affected node v∈ , perform the local relaxation operation of the incremental Dijkstra algorithm:

[0035] If the link cost decreases, the shortest path weight of node v is updated according to the following formula:

[0036] dist(v)=min(dist(v), dist(u)+w(u,v));

[0037] Where u is the source node of the changed link, dist(u) represents the shortest path from the source node to node u, and w(u,v) represents the weight between node u and node v.

[0038] If dist(v) is updated, the updated node v is added to the priority queue and propagated to its successor nodes;

[0039] If the link cost increases or is disconnected, the shortest path weight of node v is reset to infinity, and the node is removed from the priority queue. The new shortest path from the user end to node v is recalculated, the predecessor node and weight of node v in the path tree are updated, and the updated path tree is synchronized to the intermediate routers and the user end through the routing protocol.

[0040] At this point, the shortest path weights of all nodes in the path tree satisfy the following inequality:

[0041] ∀(u,v)∈E, dist(v)≤dist(u)+w(u,v);

[0042] Among them, E is the edge set of the network topology, and w(u,v) is the link weight.

[0043] Further, the probe request message includes a TCP SYN message or an ICMP request message, and the method includes:

[0044] Determine the target service type, where the target service type includes a TCP service or a non-TCP service, and set a probe request message in the explicit multicast message payload according to the determination result, specifically including:

[0045] If the target service type is TCP, the probe request message is set to a TCP SYN message, and the target server that first receives a response message to the TCP SYN message is selected as the optimal server;

[0046] If the target service type is a non-TCP service, the probe request message is set to an ICMP request message, and the target server that receives the response message to the ICMP request message first is selected as the optimal server.

[0047] Furthermore, the method further comprises:

[0048] Deploy probe nodes to periodically send multiple batches of probe messages to each node in the network. The probe messages include TCP SYN messages, ICMP request messages, or QUIC short connection handshake messages.

[0049] According to the time series of response messages received by the probe node, the potential neighbor connection probability between nodes is calculated to generate the probability adjacency matrix P = [p ij ] N×N , where p ij It represents the probability that there is a direct link between node i and node j. The calculation formula is as follows:

[0050] ;

[0051] Among them, t ik is the response time of node i in the kth detection, τ is the preset time difference threshold, and K is the number of detections;

[0052] By filtering instantaneous noise through the sliding window statistical model, if the probability of a link p ij If the probability is continuously lower than the dynamic threshold θ = μ + 2σ, the link is removed from the topology graph, where μ is the historical probability mean and σ is the standard deviation.

[0053] Get multiple groups of p in different unit time periods ij , calculate p in each unit time ij The probability mean of , and the probability mean discrete series is obtained;

[0054] The least squares method is used to perform linear regression fitting on the discrete series of probability means to generate a time series prediction function f(t) of the link probability between nodes. The node with the largest probability prediction value is selected as the direct link node to construct the preliminary network topology.

[0055] After the user initiates a DNS query, a residual analysis is performed on the arrival time of the response message and the predicted value of f(t). If the absolute value of the residual exceeds the preset tolerance, the topology data is recalibrated, the probabilistic adjacency matrix is ​​updated, and the network topology is reconstructed.

[0056] In a second aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the optimal service discovery method based on explicit multicast assistance as described in the first aspect of the present application.

[0057] In a third aspect, the present application also provides an electronic device comprising a processor and a storage medium, wherein the storage medium stores a computer program, and when the computer program is executed by the processor, the optimal service discovery method based on explicit multicast assistance as described in the first aspect of the present application is implemented.

[0058] Different from the existing technology, the optimal service discovery method, medium and device based on explicit multicast assistance described in the above technical solution include: the user end obtains the IP address list of the target server through DNS query and caches it; based on the real-time network topology, the Dijkstra algorithm is used to generate the shortest path tree from the user end to all target servers; an explicit multicast message with a target IP list in the header is constructed, and the intermediate router splits the message into unicast or sub-multicast messages according to the next-hop interface; the user end determines the optimal server by monitoring the first valid response message. The present invention replaces the traditional multicast address with explicit multicast, saves address resources and reduces network duplication traffic, and combines dynamic path tree optimization and intelligent message splitting mechanism to significantly shorten service discovery delay. It is suitable for high-concurrency scenarios such as distributed CDN, Internet of Things and live video, effectively reducing bandwidth consumption and improving service reliability. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 Flowchart of an optimal service discovery method based on explicit multicast assistance according to a first exemplary embodiment of the present invention;

[0060] Figure 2 This is a timing flow chart of an optimal service discovery method based on explicit multicast assistance according to a second exemplary embodiment of the present invention;

[0061] Figure 3 is a timing flow chart of an optimal service discovery method based on explicit multicast assistance according to a third exemplary embodiment of the present invention;

[0062] Figure 4 A schematic diagram of a network topology involved in an exemplary embodiment of the present invention;

[0063] Figure 5 A schematic diagram of a shortest path tree according to an exemplary embodiment of the present invention;

[0064] Figure 6 A schematic diagram of a module of an electronic device according to the present invention;

[0065] Reference numerals:

[0066] 10. Electronic equipment;

[0067] 101. Processor;

[0068] 102. Storage medium. DETAILED DESCRIPTION

[0069] In order to explain in detail the possible application scenarios, technical principles, specific solutions that can be implemented, and the purpose and effects of this application, the following is a detailed description of the specific embodiments listed in conjunction with the accompanying drawings. The embodiments described herein are only used to more clearly illustrate the technical solutions of this application and are therefore only examples and are not intended to limit the scope of protection of this application.

[0070] References to "embodiments" herein mean that the specific features, structures, or characteristics described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the word "embodiment" in various places in the specification does not necessarily refer to the same embodiment, nor does it particularly limit its independence or relevance to other embodiments. In principle, in this application, as long as there are no technical contradictions or conflicts, the various technical features mentioned in the embodiments can be combined in any manner to form a corresponding implementable technical solution.

[0071] Unless otherwise defined, the technical terms used herein have the same meanings as those generally understood by those skilled in the art to which this application belongs; the use of relevant terms herein is only for describing specific embodiments and is not intended to limit this application.

[0072] In the description of this application, the term "and / or" is used to describe a logical relationship between objects, indicating that three relationships can exist. For example, A and / or B means: A exists, B exists, and both A and B exist. In addition, the character " / " in this document generally indicates that the objects before and after are in a logical "or" relationship.

[0073] In this application, terms such as "first" and "second" are merely used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual quantity, priority or sequence relationship between these entities or operations.

[0074] Without further limitations, in this application, the words "include", "comprise", "have" or other similar expressions used in sentences are intended to cover non-exclusive inclusion. These expressions do not exclude the presence of additional elements in the process, method or product that includes the elements, so that the process, method or product that includes a series of elements may include not only those limited elements, but also other elements that are not explicitly listed, or also include elements that are inherent to such process, method or product.

[0075] Consistent with the understanding in the Examination Guidelines, in this application, expressions such as "greater than," "less than," and "exceed" are understood to exclude the number itself; expressions such as "above," "below," and "within" are understood to include the number itself. Furthermore, in the description of the embodiments of this application, "multiple" means two or more (including two), and similar expressions related to "multiple," such as "multiple groups" and "multiple times," are also understood in this manner, unless otherwise specifically defined.

[0076] In the first aspect, Figure 1 As shown, the present application provides an optimal service discovery method based on explicit multicast assistance, the method comprising the following steps:

[0077] S1: The client sends a DNS query request for the target service to the DNS server to obtain a target IP list, which contains the IP address information of all target servers;

[0078] S2: The client receives the feedback result of the DNS target server for the DNS query request, parses and caches the target IP list;

[0079] S3: Based on the network topology, with the user terminal as the source node and all target servers as target nodes, generate a shortest path tree from the user terminal to each target server using the Dijkstra algorithm;

[0080] S4: constructing an explicit multicast message, wherein the header of the explicit multicast message includes the target IP list, and the payload of the explicit multicast message is a probe request message;

[0081] S5: The intermediate router sends the explicit multicast message along the shortest path tree, parses the target IP list in the header field of the explicit multicast message, and splits the explicit multicast message into unicast messages or explicit multicast sub-messages according to the next-hop interface until all messages are unpacked and forwarded to the target server;

[0082] S6: The user end monitors the response messages from each target server to the detection request message, and the target server corresponding to the first valid response message that arrives is the optimal server.

[0083] In step S1, in a real-world network environment, when an application running on a user-end device (such as a computer or mobile phone) needs to access a specific target service, it sends a query request to a DNS server based on the DNS protocol. The user-end includes the domain name information of the target service in the request. Upon receiving the request, the DNS server searches its domain name resolution database to find the IP addresses of all target servers corresponding to the domain name, compiles a list of target IP addresses, and encapsulates this list in a DNS response message, which is then fed back to the user-end.

[0084] In step S2, after receiving the DNS response message, the client parses the message through the network protocol stack, extracts the target IP list, and caches it in local memory for use in subsequent steps. For example, when the client enters the URL in the browser to access a website, the browser will initiate a similar query request to the DNS server to obtain the IP address of the website server.

[0085] In step S3, after obtaining the target IP list, the client can use the network topology to identify the client itself as the source node and the IP addresses of all target servers in the target IP list as the target nodes. The network topology represents the connections between service nodes. Service nodes can be network devices (such as routers and servers). Links represent the connections between devices, and links are assigned corresponding weights (such as link bandwidth and latency). The Dijkstra algorithm is then run. This algorithm maintains a set of nodes closest to the source node, continuously selects the node closest to the source node from the remaining nodes, and adds it to the set. It also updates the shortest distances from other nodes to the source node, ultimately generating a shortest path tree from the client to each target server.

[0086] In step S4, when constructing an explicit multicast message, the message header is first created. The previously cached target IP list is populated into the message header fields in a specific format (such as an array of IP addresses). Next, the message payload is created and the probe request message (which can be a simple ICMP echo request message or a custom application-layer probe message) is written into the payload. During the construction process, the network protocol message format specifications are followed, and fields such as the message length and protocol type are correctly set to ensure that the message can be correctly transmitted and parsed on the network.

[0087] In step S5, after receiving the explicit multicast message, the intermediate router first parses the target IP list from the message header. Then, based on its own routing table information and the guidance of the shortest path tree, it determines the next hop interface. If the next hop interface is connected to a single target server or a node on a single server link, the router will directly split the explicit multicast message into unicast messages, that is, set the corresponding IP address in the target IP list as the destination address of the unicast message, and copy the payload of the explicit multicast message to the unicast message for forwarding; if the next hop interface is connected to multiple target servers or links on multiple target servers, the router will split the explicit multicast message into multiple explicit multicast sub-messages, each sub-message header contains part of the target IP list (divided according to the target server connected to the next hop interface), and the payload is the same as the original explicit multicast message, and then these sub-messages are forwarded through the next hop interface. If there are multiple next-hop interfaces, some of which connect to a single target server or nodes on a single server link, while others connect to multiple target servers or links on multiple target servers, intermediate routers can split the explicit multicast message into several unicast messages and several explicit multicast sub-messages based on the number of next-hop interfaces, and replicate the payload content in the original message for transmission. This process is repeated until all messages are decapsulated and accurately forwarded to their corresponding target servers.

[0088] In step S6, the client starts a listening thread that continuously monitors the network port, waiting for responses from each target server to the probe request message. When the first valid response message arrives, the client parses it, obtains the corresponding target server information, and identifies it as the optimal server. The client then establishes a connection with the optimal server to conduct actual service interaction.

[0089] Traditional service discovery methods require the user to send requests to each target server in turn, wait for responses, and then compare them. This method is time-consuming. However, this solution uses explicit multicast technology to send probe request messages to multiple target servers at once, greatly reducing the time for service discovery. At the same time, the Dijkstra algorithm is used to generate a shortest path tree to ensure that messages are transmitted along the optimal path, further improving the transmission speed of requests and responses, allowing users to find suitable services more quickly and improving the user experience. During the forwarding process, intermediate routers rationally split messages based on the network topology and target server distribution, avoiding unnecessary traffic transmission, effectively reducing network bandwidth usage, saving network resources, and improving network utilization efficiency.

[0090] In some embodiments, step S5 includes:

[0091] S51: The intermediate router parses the header field of the explicit multicast message and extracts the target IP list, which is recorded as {IP1, IP2, ..., IP m}, m is a positive integer, indicating the number of target servers, IP1 indicates the first target server, IP m Indicates the mth target server.

[0092] S52: The intermediate router performs the longest prefix match on the target IP address according to the real-time routing table and the path tree, and generates the next hop interface group G1, G2, ..., G N , N is a positive integer, indicating the number of next-hop interface groups, where the i-th hop interface group is represented by G i Indicates that the value range of i is [1, N];

[0093] S53: The intermediate router groups G for each next-hop interface i Do the following:

[0094] If group G i If there is only one target server IP address in the packet, a unicast message is generated, the IP header destination address of the unicast message is set to the only target server IP address in the packet, and the payload of the unicast message retains the original probe request message;

[0095] If group G i If there are multiple target server IP addresses and the packet needs to be forwarded through an intermediate node on the same path, an explicit multicast sub-message is generated. The IP header extension field of the explicit multicast sub-message contains all the target server IP addresses of the packet, and the payload of the explicit multicast sub-message retains the original probe request message.

[0096] S54: The intermediate router forwards the unicast message or the explicit multicast sub-message to the next hop interface or the target server, and updates the shortest path weights of the affected nodes in the path tree based on the incremental Dijkstra algorithm;

[0097] Repeat steps S51-S54 until all explicit multicast messages or sub-messages are decapsulated as unicast messages and transmitted to the target server, and the .

[0098] Preferably, step S52 includes:

[0099] The intermediate router extracts the target IP list and caches it in the routing table of the router. The entry format of the routing table is [prefix, next hop interface].

[0100] Perform an LPM query on each target server's IP address. This includes matching the prefix entry with the longest mask, finding the prefix that longest matches the target server's IP address, recording the corresponding next-hop interface, establishing a mapping between the target server's IP address and the next-hop interface, and storing the mapping in a temporary cache.

[0101] Using the next-hop interface as the key and the target server's IP address as the value, the target IP addresses sharing the same next-hop interface are merged into the same group, and parallel LPM queries are performed on the target IP list.

[0102] Preferably, updating the shortest path weights of affected nodes in the path tree based on the incremental Dijkstra algorithm includes:

[0103] Real-time monitoring of network link status change events, including link status change times including any one or more of link cost updates, node failures, or newly added links;

[0104] Extract the affected edge v in the link from the link state change event, mark all nodes in the path tree that depend on this edge as affected nodes, and obtain the set V affected , where any link node v∈V affected The original shortest path passes through the changed link;

[0105] For each affected node v∈ , perform the local relaxation operation of the incremental Dijkstra algorithm:

[0106] If the link cost decreases, the shortest path weight of node v is updated according to the following formula:

[0107] dist(v)=min(dist(v), dist(u)+w(u,v));

[0108] Where u is the source node of the changed link, dist(u) represents the shortest path from the source node to node u, and w(u,v) represents the weight between node u and node v.

[0109] If dist(v) is updated, the updated node v is added to the priority queue and propagated to its successor nodes;

[0110] If the link cost increases or is disconnected, the shortest path weight of node v is reset to infinity, and the node is removed from the priority queue. The new shortest path from the user end to node v is recalculated, the predecessor node and weight of node v in the path tree are updated, and the updated path tree is synchronized to the intermediate routers and the user end through the routing protocol.

[0111] At this point, the shortest path weights of all nodes in the path tree satisfy the following inequality:

[0112] ∀(u,v)∈E, dist(v)≤dist(u)+w(u,v);

[0113] Among them, E is the edge set of the network topology, and w(u,v) is the link weight.

[0114] This solution rationally splits explicit multicast packets into unicast or explicit multicast sub-packets based on the path to the target IP address. This avoids unnecessary waste of network resources, reduces redundant transmissions, and improves data transmission efficiency. Furthermore, by using the incremental Dijkstra algorithm to update the shortest path weights of affected nodes in the path tree in real time, routers can adjust routing decisions in real time based on network topology changes, ensuring that data is always transmitted along the optimal path, thereby enhancing the network's dynamic adaptability and reliability.

[0115] In some embodiments, step S531 is further included between step S53 and step S54: the intermediate router performs HMAC-SHA256 signature verification on the generated unicast message or explicit multicast sub-message, and if the signature is invalid, the message is discarded and an ICMP error message is generated and returned to the user end.

[0116] Specifically, when generating an explicit multicast message, a shared key K and an HMAC algorithm (such as HMAC-SHA256) can be used to calculate a hash value for the message content (including the header and payload). The hash value is then appended to the message extension field as a signature. After generating a unicast message or explicit multicast sub-message in step S53, the original payload and signature in the message are extracted. The HMAC value is recalculated using the same key K and compared with the signature in the message. If the comparison is successful, step S54 is executed. If the comparison fails, the message is discarded and an ICMP error message is generated and returned to the user end. The ICMP error message includes an error code (indicating an HMAC verification failure), diagnostic information, a timestamp, etc.

[0117] The above solution uses HMAC verification to ensure that the message content has not been tampered with during transmission, preventing attackers from forging or modifying probe requests. In addition, the timely discarding of invalid messages can prevent the propagation of erroneous data in the network, reduce interference with path calculation, and save network bandwidth and router processing resources.

[0118] In some embodiments, after the next hop interface grouping, the method further comprises:

[0119] Perform integrity checks based on the groups to ensure that all target server IP addresses have corresponding groups and meet the following formula conditions: ;

[0120] If there is no corresponding matching route for the IP address of a certain target server, a first prompt message is generated and fed back to the user end, where the first prompt message is used to prompt that the ICMP destination is unreachable;

[0121] If the explicit multicast sub-message cannot be unpacked at a subsequent node, the IP address of the target server in the header field of the explicit multicast sub-message is extracted to generate log information and the explicit multicast sub-message is discarded, and a second prompt information is generated and fed back to the user end. The second prompt information is used to indicate the reason why the message cannot be unpacked and the log information.

[0122] This solution uses integrity checks to promptly detect routing table incompleteness (such as routing black holes), minimizing traffic loss. Receiving ICMP notifications on the client side automatically triggers route recalculation or fault recovery. Log information details unopenable packets and nodes, helping maintenance personnel quickly identify protocol incompatibilities.

[0123] In some embodiments, the probe request message includes a TCP SYN message or an ICMP request message, and the method includes:

[0124] Determine the target service type, where the target service type includes a TCP service or a non-TCP service, and set a probe request message in the explicit multicast message payload according to the determination result, specifically including:

[0125] If the target service type is TCP, the probe request message is set to a TCP SYN message, and the target server that first receives a response message to the TCP SYN message is selected as the optimal server;

[0126] If the target service type is a non-TCP service, the probe request message is set to an ICMP request message, and the target server that receives the response message to the ICMP request message first is selected as the optimal server.

[0127] Through the above solution, it is possible to select appropriate probe messages according to the service type, handle the detection of TCP and non-TCP services, adapt to complex network environments, improve the accuracy of service reachability detection, and reduce service discovery delays by giving priority to the server that responds first.

[0128] In some embodiments, the method further comprises:

[0129] Deploy probe nodes to periodically send multiple batches of probe messages to each node in the network. The probe messages include TCP SYN messages, ICMP request messages, or QUIC short connection handshake messages.

[0130] According to the time series of response messages received by the probe node, the potential neighbor connection probability between nodes is calculated to generate the probability adjacency matrix P = [p ij ] N×N , where p ij It represents the probability that there is a direct link between node i and node j. The calculation formula is as follows:

[0131] ;

[0132] Among them, t ik is the response time of node i in the kth detection, τ is the preset time difference threshold, and K is the number of detections;

[0133] By filtering instantaneous noise through the sliding window statistical model, if the probability of a link p ij If the probability is continuously lower than the dynamic threshold θ = μ + 2σ, the link is removed from the topology graph, where μ is the historical probability mean and σ is the standard deviation.

[0134] Get multiple groups of p in different unit time periods ij , calculate p in each unit time ij The probability mean of , and the probability mean discrete series is obtained;

[0135] The least squares method is used to perform linear regression fitting on the discrete series of probability means to generate a time series prediction function f(t) of the link probability between nodes. The node with the largest probability prediction value is selected as the direct link node to construct the preliminary network topology.

[0136] After the user initiates a DNS query, a residual analysis is performed on the arrival time of the response message and the predicted value of f(t). If the absolute value of the residual exceeds the preset tolerance, the topology data is recalibrated, the probabilistic adjacency matrix is ​​updated, and the network topology is reconstructed.

[0137] This solution calculates the probability of potential neighbor connections based on the response message time series and filters instantaneous noise through a sliding window statistical model, which can more accurately reflect the actual connection relationship between nodes and reduce misjudgments. By performing residual analysis on the response message arrival time and the predicted value of f(t), if the absolute value of the residual exceeds the preset tolerance, it triggers topology data recalibration, updates the probabilistic adjacency matrix, and reconstructs the network topology. This can effectively improve the accuracy of network topology construction, thereby making the subsequent confirmation of the shortest path tree more accurate and facilitating service optimization.

[0138] like Figure 2 and Figure 3 As shown, this application constructs a method that supports explicit multicast ( The DNS service model is composed of a DBS server, intermediate routers, user terminals, and a target server cluster that provides the target service. The target server clusters are distributed in different regions.

[0139] When selecting a service, the server first sends a DNS query request for the target service to a DNS server that supports explicit multicast. The details are as follows: The DNS server supports For example, if the FQDN name of the target service is www.abc.com, the user sends a DNS query request for www.abc.com to the DNS server. The user then receives the DNS query result returned by the DNS server, which includes the IP addresses of all servers serving the target service. The details are as follows:

[0140] Assume that the server responds to the client's DNS query request for www.abc.com service, and the returned DNS query result is A={IP1, IP2, ......, IP m}, let the IP address of the i-th server be IP i (i=1,2,3…m), where m represents the number of servers providing the target service. The client caches the IP addresses of all m target servers. The server then sends a TCP SYN request or ICMP request message to all target servers using the resolved IP addresses in an explicit multicast manner.

[0141] Specifically, the client can use Dijkstra's algorithm to construct the shortest path to all servers that provide the target service, and send a message to all servers in an explicit multicast manner to request the establishment of a connection. Figure 2 As shown, taking TCP connection as an example, Figure 2In the figure, C is the user end, and the intermediate router represents a router that supports explicit multicast. The user end first initiates a DNS query request to the DNS server. After obtaining the target IP list sent by the DNS server, it constructs an explicit multicast message based on the target IP list. Specifically, the destination address in the header of the explicit multicast message is set to the IP address list of the target server, and then sends the explicit multicast message to the target server along the shortest path tree. The user end monitors each target server (in Figure 2 The address corresponding to the target server is IP1-IP m ) response message, and the target server corresponding to the first valid response message that arrives is the optimal server, for example, Figure 2 If the valid response message of the target server with the address IP1 reaches the client first, it is confirmed that the TCP connection between the client and the target server with the address IP1 is established. m The target server returns a TCP reset message to the client, which indicates that the target server port requested by the current client is unavailable and terminates the connection between the two parties.

[0142] For services that do not support TCP, ICMP request messages are sent to all servers in an explicit multicast manner. The overall interaction process is as follows: Figure 3 As shown, Figure 3 and Figure 2 The only difference is the supported protocols, which will not be expanded here. Figure 3 In the figure, C is the user end, the intermediate router represents the router that supports explicit multicast, and the UDP (User Datagram Protocol) service request refers to the process of sending request data to the target server based on the UDP protocol. Correspondingly, the UDP service response refers to the process of the target server returning response data to the user end after receiving the UDP service request sent by the user end.

[0143] In short, the user end uses the first received TCP or ICMP probe response message as a benchmark to determine that the target server that sent the response message is the optimal server for the current target service, and provides subsequent services to the user end through the optimal server.

[0144] In order to make the technical solutions and advantages of the present invention more clear, the following will be combined with the NSFNet network with 14 nodes (such as Figure 5 ) further clearly and completely describe steps S4 and S5.

[0145] In order to more intuitively and clearly illustrate the innovation and advantages of the technical solution of the present invention, the NSFNet network topology with 14 nodes (see Figure 4), systematically disassembles and deeply analyzes step S5, striving to comprehensively and completely present the details of the technical solution from multiple dimensions such as network transmission process and algorithm execution logic.

[0146] To ensure the representativeness of the analysis results, Figure 4 Among the 14 nodes in the NSFNet network shown, one node is randomly selected as the user end, and multiple nodes are selected as distributed server nodes. In this embodiment, the user end is randomly selected as node 1, and nodes 7, 14, 13, 10, 5, and 11 are determined as the distributed server nodes corresponding to the target service (i.e., target servers). Based on the path planning principle of the Dijkstra algorithm, with the user end node as the root node and each target server node as the leaf node, a corresponding path tree structure is constructed (see for details). Figure 5 ), the following quantitative analysis is carried out from the two dimensions of communication overhead and time overhead:

[0147] In the traditional unicast scenario, the user end needs to send detection packets to 6 servers in sequence. According to the number of link hops, the detection communication overhead is 2n, 3n, 4n, 3n, 3n, and 3n, respectively, with a total cumulative overhead of 18n bytes. Due to differences in link transmission and CPU processing, the time overhead is 4t+α1, 6t+α2+τ, 8t+α3+2τ, 6t+α4+3τ, 6t+α5+4τ, and 6t+α6+5τ (where α represents processing delay and link random delay, τ is the CPU instruction cycle, and t represents the transmission time of adjacent nodes). Finally, the node corresponding to the minimum time overhead is selected as the optimal service. Therefore, the total time overhead is It can represent the maximum value of the detection delay of each node. The specific formula is as follows:

[0148] =max[4t+α1,6t+α2+τ,8t+α3+2τ,6t+α4+3τ,6t+α5+4τ,6t+α6+5τ].

[0149] Taking the explicit multicast scenario of the present invention as an example, the probe message sent by client 1 to nodes 7, 14, 13, and 10 follows branch 1 above. The explicit multicast probe packet A on the link from node 1 to node 8 has a size of n+4×3 (indicating that the header field of message A needs to carry the IP addresses of three additional target servers). When message A reaches node 8, it needs to be decapsulated. Specifically, it is decapsulated into a standard unicast message B and an explicit multicast sub-message C carrying the IP addresses of two additional target servers. Message B is sent to node 7, has a size of n, and a time overhead of 4t+β1+γ. Message B is sent to node 9, has a size of n+4×2. When message B reaches node 9, it also needs to be decapsulated, decapsulating it into three standard unicast messages. The decapsulated messages are then forwarded to nodes 14, 13, and 10, respectively. The time overheads of the three links are 6t+β2+2γ, 8t+β3+2γ, and 6t+β4+2γ, respectively. Therefore, the branch 1 probing overhead is (n+4×3)+n+(n+4×2)+n+2n+n=7n+20.

[0150] Similarly, the detection message sent by node 1 (i.e., the user end) to nodes 5 and 11 follows branch 2 below. The explicit multicast detection packet D on the link from node 1 to node 2 to node 4 has a communication overhead of (n+4×1)+(n+4×1). D needs to be decapsulated when it reaches node 4. It is decapsulated into two ordinary unicast detection messages, and then forwarded to node 5 and node 11 respectively. The time overhead is 6t+τ+β5+γ and 6t+τ+β6+γ, respectively. Among them, β includes processing delay and link randomness delay, etc., and γ is the anycast decapsulation delay. Therefore, the detection overhead of branch 2 is (n+4×1)+(n+4×1)+n+n=4n+8. It is not difficult to deduce that the total communication overhead is 11n+28 bytes. Since this scheme selects the node that responds first as the optimal service, its time overhead is the minimum value of the detection delay of each service node, expressed as follows:

[0151] =min[4t+β1+γ, 6t+β2+2γ, 8t+β3+2γ, 6t+β4+2γ, 6t+β5+τ+γ, 6t+β6+τ+γ].

[0152] A comparison of communication overhead between traditional unicast and the solution of the present invention is shown below: According to the Ethernet protocol specification, the minimum probe packet size n is ≥ 64 bytes. Calculations show that the difference in communication overhead between traditional unicast and the solution of the present invention, 18n - (11n + 28) = 7n - 28, is consistently greater than 0, demonstrating the significant communication efficiency advantage of the present invention.

[0153] The time overhead comparison between the traditional unicast method and the solution of the present invention is as follows: By assuming that the processing delay is consistent with the random delay under the same link (αi =β i , i∈[1,6]), and the CPU consumption of explicit multicast decapsulation is comparable to that of unicast forwarding (i.e., τ=γ), and No matter which node the maximum delay value in the traditional unicast scenario is taken, it can be proved that > , that is, the solution of the present invention also performs well in terms of time efficiency.

[0154] The explicit multicast technology employed in this paper is not restricted by specific network topologies and demonstrates stable performance advantages in networks of all sizes, including NSFNet. Simulation data further validates the theoretical assumptions, and the advantages of this solution in terms of communication and time overhead become increasingly significant with larger network sizes and higher node density.

[0155] This invention effectively overcomes the bottleneck of multicast IP address resource shortages through an explicit multicast mechanism. While reducing network communication load, it significantly shortens optimal service lookup time and significantly improves user-side service acquisition efficiency. Furthermore, this solution requires no server-side modifications and is highly compatible with existing OSD systems. It is particularly suitable for scenarios such as low-density distributed services, object storage device (OSD) systems, and optimal task offloading in edge computing, demonstrating its high engineering value and potential for application.

[0156] In a second aspect, the present invention further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the optimal service discovery method based on explicit multicast assistance as described in the first aspect of the present invention.

[0157] The computer-readable storage medium may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories.

[0158] The non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a ferromagnetic random access memory (FRAM), a flash memory, a magnetic surface storage, an optical disc, or a compact disc read-only memory (CD ROM); the magnetic surface storage may be a magnetic disk storage or a magnetic tape storage.

[0159] The volatile memory may be a random access memory (RAM) that is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static random access memory (SRAM), synchronous static random access memory (SSRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronized dynamic random access memory (SLDRAM), and direct rambus random access memory (DRRAM). The computer-readable storage medium described in the embodiments of the present invention is intended to include these and any other suitable types of memory.

[0160] like Figure 6 As shown, in the third aspect, the present invention provides an electronic device 10, including a processor 101 and a storage medium 102, on which a computer program is stored, and when the computer program is executed by the processor, it implements the optimal service discovery method based on explicit multicast assistance as described in the first aspect of the present invention.

[0161] In some embodiments, the processor can be implemented by software, hardware, firmware or a combination thereof, and can use a circuit, a single or multiple application-specific integrated circuits (ASIC), a digital signal processor (DSP), a digital signal processing device (DSPD), a programmable logic device (PLD), a field programmable gate array (FPGA), a central processing unit (CPU), a controller, a microcontroller, or at least one of a microprocessor, so that the processor can execute some or all of the steps or any combination of the steps in the optimal service discovery method based on explicit multicast assistance described in the various embodiments of the present application.

[0162] It should be noted that although the above embodiments have been described herein, this does not limit the scope of patent protection of the present invention. Therefore, based on the innovative concept of the present invention, changes and modifications to the embodiments described herein, or equivalent structural or equivalent process transformations made using the contents of the present invention's specification and drawings, and direct or indirect application of the above technical solutions to other related technical fields, are all included in the scope of patent protection of the present invention.

Claims

1. An optimal service discovery method based on explicit multicast assistance, characterized in that: The method comprises the following steps: S1: The client sends a DNS query request for the target service to the DNS server to obtain a target IP list, which contains the IP address information of all target servers; S2: The client receives the feedback result of the DNS target server for the DNS query request, parses and caches the target IP list; S3: Based on the network topology, with the user terminal as the source node and all target servers as target nodes, generate a shortest path tree from the user terminal to each target server using the Dijkstra algorithm; S4: constructing an explicit multicast message, wherein the header of the explicit multicast message includes the target IP list, and the payload of the explicit multicast message is a probe request message; S5: The intermediate router sends the explicit multicast message along the shortest path tree, parses the target IP list in the header field of the explicit multicast message, and splits the explicit multicast message into unicast messages or explicit multicast sub-messages according to the next-hop interface until all messages are unpacked and forwarded to the target server; S6: The user end monitors the response messages from each target server to the detection request message, and the target server corresponding to the first valid response message that arrives is the optimal server.

2. The optimal service discovery method based on explicit multicast assistance according to claim 1, characterized in that: Step S5 includes: S51: The intermediate router parses the header field of the explicit multicast message and extracts the target IP list, which is recorded as {IP1, IP2, ..., IP m }, m is a positive integer, indicating the number of target servers; S52: The intermediate router performs the longest prefix match on the IP address of the target server according to the real-time routing table and the path tree, and generates the next hop interface group G1, G2, ..., G N , N is a positive integer, indicating the number of next-hop interface groups, where the i-th hop interface group is represented by G i Indicates that the value range of i is [1, N]; S53: The intermediate router groups G for each next hop interface i Do the following: If group G i If there is only one target server IP address in the packet, a unicast message is generated, the IP header destination address of the unicast message is set to the only target server IP address in the packet, and the payload of the unicast message retains the original probe request message; If group G i If there are multiple target server IP addresses and the packet needs to be forwarded through an intermediate node on the same path, an explicit multicast sub-message is generated. The IP header extension field of the explicit multicast sub-message contains all the target server IP addresses of the packet, and the payload of the explicit multicast sub-message retains the original probe request message. S54: The intermediate router forwards the unicast message or the explicit multicast sub-message to the next hop interface or the target server, and updates the shortest path weights of the affected nodes in the path tree based on the incremental Dijkstra algorithm; Repeat steps S51-S54 until all explicit multicast messages or sub-messages are decapsulated as unicast messages and transmitted to the target server, and the .

3. The optimal service discovery method based on explicit multicast assistance according to claim 2, characterized in that: Also included between step S53 and step S54 is step S531: The intermediate router performs HMAC-SHA256 signature verification on the generated unicast message or explicit multicast sub-message. If the signature is invalid, the router discards the message and generates an ICMP error message and returns it to the user.

4. The optimal service discovery method based on explicit multicast assistance according to claim 2, characterized in that: Step S52 includes: The intermediate router extracts the target IP list and caches it in the routing table of the router. The entry format of the routing table is [prefix, next hop interface]. Perform an LPM query on each target server's IP address. This includes matching the prefix entry with the longest mask, finding the prefix that longest matches the target server's IP address, recording the corresponding next-hop interface, establishing a mapping between the target server's IP address and the next-hop interface, and storing the mapping in a temporary cache. Using the next-hop interface as the key and the target server's IP address as the value, the target IP addresses sharing the same next-hop interface are merged into the same group, and parallel LPM queries are performed on the target IP list.

5. The optimal service discovery method based on explicit multicast assistance according to claim 2 or 4, characterized in that: After the next hop interface grouping, the method further includes: Perform integrity checks based on the groups to ensure that all target server IP addresses have corresponding groups and meet the following formula conditions: ; If there is no corresponding matching route for the IP address of a certain target server, a first prompt message is generated and fed back to the user end, where the first prompt message is used to prompt that the ICMP destination is unreachable; If the explicit multicast sub-message cannot be unpacked at a subsequent node, the IP address of the target server in the header field of the explicit multicast sub-message is extracted to generate log information and the explicit multicast sub-message is discarded, and a second prompt information is generated and fed back to the user end. The second prompt information is used to indicate the reason why the message cannot be unpacked and the log information.

6. The optimal service discovery method based on explicit multicast assistance according to claim 2, wherein: Updating the shortest path weights of affected nodes in the path tree based on the incremental Dijkstra algorithm includes: Real-time monitoring of network link status change events, including link status change times including any one or more of link cost updates, node failures, or newly added links; Extract the affected edge v in the link from the link state change event, mark all nodes in the path tree that depend on this edge as affected nodes, and obtain the set V affected , where any link node v∈V affected The original shortest path passes through the changed link; For each affected node v∈ , perform the local relaxation operation of the incremental Dijkstra algorithm: If the link cost decreases, the shortest path weight of node v is updated according to the following formula: dist(v)=min(dist(v), dist(u)+w(u,v)); Where u is the source node of the changed link, dist(u) represents the shortest path from the source node to node u, and w(u,v) represents the weight between node u and node v. If dist(v) is updated, the updated node v is added to the priority queue and propagated to its successor nodes; If the link cost increases or is disconnected, the shortest path weight of node v is reset to infinity, and the node is removed from the priority queue. The new shortest path from the user end to node v is recalculated, the predecessor node and weight of node v in the path tree are updated, and the updated path tree is synchronized to the intermediate routers and the user end through the routing protocol. At this point, the shortest path weights of all nodes in the path tree satisfy the following inequality: ∀(u,v)∈E, dist(v)≤dist(u)+w(u,v); Among them, E is the edge set of the network topology, and w(u,v) is the link weight.

7. The optimal service discovery method based on explicit multicast assistance according to claim 1, wherein: The probe request message includes a TCP SYN message or an ICMP request message, and the method includes: Determine the target service type, where the target service type includes a TCP service or a non-TCP service, and set a probe request message in the explicit multicast message payload according to the determination result, specifically including: If the target service type is TCP, the probe request message is set to a TCP SYN message, and the target server that first receives a response message to the TCP SYN message is selected as the optimal server; If the target service type is a non-TCP service, the probe request message is set to an ICMP request message, and the target server that receives the response message to the ICMP request message first is selected as the optimal server.

8. The optimal service discovery method based on explicit multicast assistance according to claim 1, wherein: The method further comprises: Deploy probe nodes to periodically send multiple batches of probe messages to each node in the network. The probe messages include TCP SYN messages, ICMP request messages, or QUIC short connection handshake messages. According to the time series of response messages received by the probe node, the potential neighbor connection probability between nodes is calculated to generate the probability adjacency matrix P = [p ij ] N×N , where p ij It represents the probability that there is a direct link between node i and node j. The calculation formula is as follows: ； Among them, t ik is the response time of node i in the kth detection, τ is the preset time difference threshold, and K is the number of detections; By filtering instantaneous noise through the sliding window statistical model, if the probability of a link p ij If the probability is continuously lower than the dynamic threshold θ = μ + 2σ, the link is removed from the topology graph, where μ is the historical probability mean and σ is the standard deviation. Get multiple groups of p in different unit time periods ij , calculate p in each unit time ij The probability mean of , and the probability mean discrete series is obtained; The least squares method is used to perform linear regression fitting on the discrete series of probability means to generate a time series prediction function f(t) of the link probability between nodes. The node with the largest probability prediction value is selected as the direct link node to construct the preliminary network topology. After the user initiates a DNS query, a residual analysis is performed on the arrival time of the response message and the predicted value of f(t). If the absolute value of the residual exceeds the preset tolerance, the topology data is recalibrated, the probabilistic adjacency matrix is ​​updated, and the network topology is reconstructed.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the optimal service discovery method based on explicit multicast assistance is implemented as described in any one of claims 1 to 8.

10. An electronic device, characterized in that: The system comprises a processor and a storage medium, wherein the storage medium stores a computer program, and when the computer program is executed by the processor, the optimal service discovery method based on explicit multicast assistance is implemented as described in any one of claims 1 to 8.

Images