Movatterモバイル変換


[0]ホーム

URL:


CN120263717A - Optimal service discovery method, medium and device based on explicit multicast assistance - Google Patents

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

Info

Publication number
CN120263717A
CN120263717ACN202510736090.9ACN202510736090ACN120263717ACN 120263717 ACN120263717 ACN 120263717ACN 202510736090 ACN202510736090 ACN 202510736090ACN 120263717 ACN120263717 ACN 120263717A
Authority
CN
China
Prior art keywords
message
target
node
explicit multicast
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202510736090.9A
Other languages
Chinese (zh)
Other versions
CN120263717B (en
Inventor
熊建辉
贾文康
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Concord University College Fujian Normal University
Fujian Normal University
Original Assignee
Concord University College Fujian Normal University
Fujian Normal University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Concord University College Fujian Normal University, Fujian Normal UniversityfiledCriticalConcord University College Fujian Normal University
Priority to CN202510736090.9ApriorityCriticalpatent/CN120263717B/en
Publication of CN120263717ApublicationCriticalpatent/CN120263717A/en
Application grantedgrantedCritical
Publication of CN120263717BpublicationCriticalpatent/CN120263717B/en
Activelegal-statusCriticalCurrent
Anticipated expirationlegal-statusCritical

Links

Landscapes

Abstract

Translated fromChinese

本发明公开了一种基于显式多播辅助的最优服务发现方法、介质和设备,该方法包括:用户端通过DNS查询获取目标服务器的IP地址列表并缓存;基于实时网络拓扑,利用Dijkstra算法生成用户端到所有目标服务器的最短路径树;构造头部携带目标IP列表的显式多播报文,中间路由器按下一跳接口拆分报文为单播或子多播报文;用户端通过监听首个有效响应报文确定最优服务器。本发明通过显式多播替代传统多播地址,节省地址资源并降低网络重复流量,同时结合动态路径树优化和智能报文拆分机制,显著缩短服务发现延迟,适用于分布式CDN、物联网及视频直播等高并发场景,有效降低带宽消耗并提升服务可靠性。

The present invention discloses an optimal service discovery method, medium and device based on explicit multicast assistance, the method comprising: 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, which 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

Optimal service discovery method, medium and device based on explicit multicast assistance
Technical Field
The present invention relates to the field of distributed networks, and in particular, to an optimal service discovery method, a computer readable storage medium, and an electronic device based on explicit multicast assistance.
Background
With the rapid development of mobile internet, internet of things and distributed service technology, requirements of high concurrency scenes such as warehouse logistics, online shopping, video live broadcast and the like on service reliability and low delay are increasingly severe. Currently, the distributed CDN network realizes the nearby access of the content through service localization deployment, but the core of the distributed CDN network still depends on a unicast communication mechanism, and has the technical bottlenecks that (1) multicast address resource exhaustion and network congestion contradiction are aggravated, the traditional multicast technology depends on a D-type IP address to realize one-to-many communication, but the multicast address is seriously starved due to the large-scale application of the scenes such as video live broadcast, online conference and the like. Meanwhile, massive repeated data transmission in a unicast mode aggravates network congestion, and bandwidth cost is increased.
(2) Dynamic service discovery is inefficient in that existing service discovery mechanisms (e.g., DNS polling, unicast probing) need to initiate requests to the target server one by one, creating a large amount of redundant traffic in the cross-regional service invocation.
Explicit multicast to solve the above problems) Techniques have been developed that can save 90% of the address resources by substituting the multicast address with the destination IP list carried by the header. However, existingThe lack of the scheme is combined with the depth of dynamic service discovery and path optimization, so that the IP list of the target server is oversized, and the optimal service response speed is slow.
Disclosure of Invention
For this reason, there is a need to provide a solution for optimal service discovery based on explicit multicast assistance to solve the lack of the prior artThe solution combined with the depth of dynamic service discovery and path optimization results in the problem of slow response speed of the optimal service.
To achieve the above object, in a first aspect, the present application provides an optimal service discovery method based on explicit multicast assistance, the method comprising the steps of:
the method comprises the steps that S1, a user side sends a DNS query request aiming at target service to a DNS server to obtain a target IP list, wherein the target IP list contains IP address information of all target servers;
S2, the user side receives a feedback result of the DNS target server aiming at the DNS query request, and analyzes and caches the target IP list;
S3, generating a shortest path tree from a user terminal to each target server through a Dijkstra algorithm by taking the user terminal as a source node and all the target servers as target nodes based on network topology;
s4, constructing an explicit multicast message, wherein the head of the explicit multicast message comprises the target IP list, and the load of the explicit multicast message is a detection request message;
S5, the intermediate router sends an explicit multicast message along the shortest path tree, analyzes a target IP list in a header field of the explicit multicast message, splits the explicit multicast message into a unicast message or an explicit multicast sub-message according to a next hop interface until all messages are unpacked and forwarded to a target server;
And S6, the user side monitors response messages from each target server aiming at the detection request message, and takes the target server corresponding to the effective response message which arrives first as the optimal server.
Further, step S5 includes:
s51, the intermediate router analyzes the header field of the explicit multicast message, extracts the target IP list, marks the target IP list as { IP1,IP2,...,IPm }, and m is a positive integer to represent the number of target servers;
S52, the intermediate router executes longest prefix matching on the target IP address according to a real-time routing table and a path tree to generate a next hop interface packet G1,G2,...,GN, wherein N is a positive integer and represents the number of the next hop interface packets, the ith hop interface packet is represented by Gi, and the value range of i is [1, N ];
The intermediate router performs the following for each next hop interface packet Gi:
If only one target server exists in the group Gi and the IP address of the target server is reachable through the same path, generating a unicast message, wherein the IP head target address of the unicast message is set as the unique IP address of the target server in the group, and the load of the unicast message keeps the original detection request message;
If the packet Gi has a plurality of target server IP addresses and needs to be forwarded by an intermediate node of the same path, generating an explicit multicast sub-message, wherein an IP header extension field of the explicit multicast sub-message comprises all target server IP addresses of the packet, and the load of the explicit multicast sub-message keeps an original detection request message;
s54, the intermediate router forwards the unicast message or the explicit multicast sub-message to a next-hop interface or a target server, and meanwhile, the shortest path weight of the affected node in the path tree is updated based on an increment Dijkstra algorithm;
Repeating steps S51-S54 until all explicit multicast messages or sub-messages are unpacked into unicast messages and transmitted to the target server, and satisfying
Further, step S531 is further included between step S53 and step S54:
And the intermediate router performs HMAC-SHA256 signature verification on the generated unicast message or the generated explicit multicast sub-message, discards the message if the signature is invalid, generates ICMP error message and returns to the user terminal.
Further, step S52 includes:
the intermediate router caches the extracted target IP list in a routing table of the router, wherein the entry format of the routing table is [ prefix, next hop interface ];
The method specifically comprises the steps of starting to match from the prefix item of the longest mask, finding the prefix which is matched with the IP address of the target server longest, recording the corresponding next hop interface, establishing the mapping relation between the IP address of the target server and the next hop interface, and storing the mapping relation into a temporary cache;
And taking the next hop interface as a key, taking the IP address of the target server as a value, combining the target IP addresses sharing the same next hop interface into the same packet, and carrying out parallel LPM inquiry on the target IP list.
Further, after the next hop interface packet, the method further comprises:
and carrying out integrity check according to the packets, ensuring that the IP addresses of all the target servers have corresponding packets, and meeting the following formula conditions:;
if the IP address of a certain target server does not have a corresponding matching route, generating first prompt information which is used for prompting that the ICMP objective is not reachable and feeding back to the user side;
If the explicit multicast sub-message cannot be unpacked at the subsequent node, extracting the IP address of the target server in the header field of the explicit multicast sub-message to generate log information, discarding the explicit multicast sub-message, and generating second prompt information for prompting the reason that the message cannot be unpacked and the log information, and feeding back the second prompt information to the user side.
Further, updating the shortest path weights of the affected nodes in the path tree based on the incremental Dijkstra algorithm includes:
Monitoring network link state change events in real time, including link state change time including any one or more of link cost update, node failure or newly added links;
Extracting an affected side V in a link from the link state change event, marking all nodes depending on the side in a path tree as affected nodes, and obtaining a set Vaffected, wherein any link node V epsilon Vaffected meets the condition that the original shortest path passes through the changed link;
for each affected node v EA local relaxation operation of the delta Dijkstra algorithm is performed:
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));
Wherein u is a source node of a changed link, dist (u) represents the shortest path from the source node to the node u, and w (u, v) represents the weight between the node u and the node v;
if dist (v) is updated, adding the updated node v into a priority queue and transmitting the node v to a subsequent node;
If the link cost is increased or disconnected, resetting the shortest path weight of the node v to infinity, removing the node from the priority queue, recalculating a new shortest path from the user end to the node v, updating the precursor node and the weight of the node v in the path tree, and synchronizing the updated path tree to the intermediate router and the user end through a routing protocol;
At this time, 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);
where E is the edge set of the network topology and w (u, v) is the link weight.
Further, the probe request message includes a TCP SYN message or an ICMP request message, and the method includes:
Judging a target service type, wherein the target service type comprises TCP (transmission control protocol) service or non-TCP service, and setting a detection request message in an explicit multicast message load according to a judging result, and specifically comprises the following steps:
if the target service type is TCP type, the probe request message is set as TCP SYN message, and the target server of the response message which is received first and is aimed at the TCP SYN message is selected as the optimal server;
If the target service type is non-TCP service, the probe request message is set as an ICMP request message, and a target server of a response message which is received first and aims at the ICMP request message is selected as an optimal server.
Further, the method further comprises:
Deploying probe nodes, and periodically sending a plurality of batches of detection messages to each node in a network, wherein the detection messages comprise TCP SYN messages, ICMP request messages or QUIC short connection handshake messages;
According to the response message time sequence received by the probe node, calculating the potential neighbor connection probability among the nodes, and generating a probability adjacency matrix P= [ Pij]N×N ], wherein Pij represents the probability that a direct link exists between the node i and the node j, and the calculation formula is as follows:
;
Wherein tik is the response time of the node i in the kth detection, τ is a preset time difference threshold, and K is the detection times;
Filtering transient noise through a sliding window statistical model, and if the probability pij of a certain link is continuously lower than a dynamic threshold value theta=mu+2sigma, removing the link from the topological graph, wherein mu is a historical probability mean value, and sigma is a standard deviation;
obtaining a plurality of groups of pij in different unit time periods, and calculating the probability average value of pij in each unit time period to obtain a probability average value discrete number sequence;
performing linear regression fitting on the probability mean value discrete number sequence by adopting a least square method, generating a time sequence prediction function f (t) of inter-node link probability, selecting a node with the maximum probability prediction value as a direct link node, and constructing a preliminary network topology;
After the DNS inquiry is initiated by the user terminal, residual analysis is carried out 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 recalibration of topology data is triggered, the probability adjacency matrix is updated, and the network topology is reconstructed.
In a second aspect, the present application provides a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements an explicit multicast assistance based optimal service discovery method according to the first aspect of the present application.
In a third aspect, the present application also provides an electronic device, comprising a processor and a storage medium, the storage medium having stored thereon a computer program which, when executed by the processor, implements the explicit multicast assistance based optimal service discovery method according to the first aspect of the present application.
The method comprises the steps that a user side obtains an IP address list of a target server through DNS query and caches the IP address list, a shortest path tree from the user side to all the target servers is generated by using Dijkstra algorithm based on real-time network topology, an explicit multicast message with a target IP list carried by the head is constructed, an intermediate router splits the message into unicast or sub-multicast messages according to a next hop interface, and the user side determines the optimal server by monitoring a first effective response message. The invention replaces the traditional multicast address by explicit multicast, saves address resources and reduces network repeated flow, and simultaneously combines dynamic path tree optimization and intelligent message splitting mechanism to obviously shorten service discovery delay, thereby being applicable to high concurrency scenes such as distributed CDN, internet of things, video live broadcast and the like, effectively reducing bandwidth consumption and improving service reliability.
Drawings
Fig. 1 is a flowchart of an explicit multicast assistance-based optimal service discovery method according to a first exemplary embodiment of the present invention;
Fig. 2 is a timing flowchart of an explicit multicast assistance-based optimal service discovery method according to a second exemplary embodiment of the present invention;
fig. 3 is a timing flowchart of an explicit multicast assistance-based optimal service discovery method according to a third exemplary embodiment of the present invention;
FIG. 4 is a schematic diagram of a network topology according to an exemplary embodiment of the present invention;
FIG. 5 is a schematic diagram of a shortest path tree according to an exemplary embodiment of the present invention;
FIG. 6 is a block diagram of an electronic device according to the present invention;
Reference numerals:
10. An electronic device;
101. a processor;
102. A storage medium.
Detailed Description
In order to describe the possible application scenarios, technical principles, practical embodiments, and the like of the present application in detail, the following description is made with reference to the specific embodiments and the accompanying drawings. The embodiments described herein are only for more clearly illustrating the technical aspects of the present application, and thus are only exemplary and not intended to limit the scope of the present application.
Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the application. The appearances of the phrase "in various places in the specification are not necessarily all referring to the same embodiment, nor are they particularly limited to independence or relevance from other embodiments. In principle, in the present application, as long as there is no technical contradiction or conflict, the technical features mentioned in each embodiment may be combined in any manner to form a corresponding implementable technical solution.
Unless defined otherwise, technical terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application pertains, and the use of related terms herein is intended only to describe specific embodiments, not to limit the present application.
In the description of the present application, the term "and/or" is a representation for describing a logical relationship between objects, meaning that three relationships may exist, for example, a and/or B, meaning that there are a, B, and both a and B. In addition, the character "/" herein generally indicates that the front-to-back associated object is an "or" logical relationship.
In the present application, terms such as "first" and "second" are used merely to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual number, order, or sequence of such entities or operations.
Without further limitation, the use of the terms "comprising," "including," "having," or other like terms in this specification is intended to cover a non-exclusive inclusion, such that a process, method, or article of manufacture that comprises a list of elements does not include additional elements but may include other elements not expressly listed or inherent to such process, method, or article of manufacture.
In the present application, the expressions "greater than", "less than", "exceeding" and the like are understood to exclude the present number, and the expressions "above", "below", "within" and the like are understood to include the present number, as well as the expressions "examining the guideline" and the like. Furthermore, in the description of embodiments of the present application, the meaning of "a plurality of" is two or more (including two), and similarly, the expression "a plurality of" is also to be understood as such, for example, "a plurality of" and the like, unless specifically defined otherwise.
In a first aspect, as shown in fig. 1, the present application provides an optimal service discovery method based on explicit multicast assistance, the method comprising the steps of:
the method comprises the steps that S1, a user side sends a DNS query request aiming at target service to a DNS server to obtain a target IP list, wherein the target IP list contains IP address information of all target servers;
S2, the user side receives a feedback result of the DNS target server aiming at the DNS query request, and analyzes and caches the target IP list;
S3, generating a shortest path tree from a user terminal to each target server through a Dijkstra algorithm by taking the user terminal as a source node and all the target servers as target nodes based on network topology;
s4, constructing an explicit multicast message, wherein the head of the explicit multicast message comprises the target IP list, and the load of the explicit multicast message is a detection request message;
S5, the intermediate router sends an explicit multicast message along the shortest path tree, analyzes a target IP list in a header field of the explicit multicast message, splits the explicit multicast message into a unicast message or an explicit multicast sub-message according to a next hop interface until all messages are unpacked and forwarded to a target server;
And S6, the user side monitors response messages from each target server aiming at the detection request message, and takes the target server corresponding to the effective response message which arrives first as the optimal server.
In step S1, in an actual network environment, an application program running on a user terminal device (such as a computer, a mobile phone, etc.) sends a query request to a DNS server according to a DNS (domain name system) protocol when a specific target service needs to be acquired. The user side carries the domain name information of the target service in the request, after the DNS server receives the request, the DNS server searches in a domain name resolution database of the request, finds the IP address information of all the target servers corresponding to the domain name, forms a target IP list, and encapsulates the target IP list in a DNS response message to be fed back to the user side.
In step S2, after receiving the DNS response message, the user parses the message through the network protocol stack, extracts the target IP list, and caches the target IP list in the local memory for use in the subsequent step. For example, when the user inputs a website to access a website in the browser, the browser will initiate a similar query request to the DNS server to obtain the IP address of the website server.
In step S3, after the user terminal obtains the target IP list, based on the network topology, the user terminal itself can be used as a source node, and IP addresses corresponding to all target servers in the target IP list can be used as target nodes. The network topology is used to represent the connection relationship between the current service nodes, which may be network devices (such as routers, servers, etc.), and the links represent the connection relationship between the devices and assign corresponding weights (such as link bandwidths, delays, etc.) to the links. And then a Dijkstra algorithm can be operated, and the algorithm continuously selects the node closest to the source node from the rest nodes to join the set by maintaining a node set closest to the source node, updates the shortest distance between other nodes and the source node, and finally generates the shortest path tree from the user terminal to each target server.
In step S4, when constructing the explicit multicast message, a message header may be created first, and the previously cached target IP list is filled into the message header field according to a specific format (such as an IP address array). Then, a message payload portion is created, and a probe request message (which may be a simple ICMP echo request message or a custom application layer probe message) is written into the payload. In the construction process, the correct message length, protocol type and other fields are set according to the message format specification of the network protocol, so that the message can be correctly transmitted and analyzed in the network.
In step S5, after receiving the explicit multicast message, the intermediate router first parses out the target IP list from the header of the message. And then, determining a next hop interface according to the routing table information of the next hop interface and the guidance of the shortest path tree. If the next hop interface is connected with a single target server or a node on a single server link, the router directly splits the explicit multicast message into unicast messages, namely, the corresponding IP address in the target IP list is set as the destination address of the unicast message, and copies the load of the explicit multicast message into the unicast message for forwarding, if the next hop interface is connected with a plurality of target servers or links on a plurality of target servers, the router splits the explicit multicast message into a plurality of explicit multicast sub-messages, the head of each sub-message contains part of the target IP list (divided according to the target servers connected by the next hop interface), the load is the same as that of the original explicit multicast message, and then the sub-messages are forwarded through the next hop interface. If there are multiple next hop interfaces, some of which are connected with a single target server or nodes on a single server link, and others are connected with multiple target servers or links on multiple target servers, the intermediate router can split the explicit multicast message into several unicast messages and several explicit multicast sub-messages according to the number of the next hop interfaces, and copy the load content in the original message for transmission. This process is repeated until all messages are unpacked and forwarded accurately to the corresponding target servers.
In step S6, the ue starts a listening thread to continually monitor the network ports, and waits for response messages from each target server for the probe request messages. When the first effective response message arrives, the user end analyzes the response message, acquires the target server information corresponding to the response message, and considers the target server information as an optimal server. And the subsequent user end establishes connection with the optimal server to perform actual service interaction.
The traditional service discovery method needs that the user side sends a request to each target server in turn, and the time consumption is long after waiting for a response to compare. According to the scheme, the detection request message is sent to a plurality of target servers at one time by an explicit multicast technology, so that the service discovery time is greatly reduced. Meanwhile, the Dijkstra algorithm is utilized to generate the shortest path tree, so that the message is ensured to be transmitted along the optimal path, the transmission speed of a request and a response is further improved, a user side can find a proper service more quickly, and the user side experience is improved. In the forwarding process, the intermediate router reasonably splits the message according to the network topology and the distribution of the target servers, so that unnecessary traffic transmission is avoided, occupation of network bandwidth is effectively reduced, network resources can be saved, and the utilization efficiency of the network is improved.
In some embodiments, step S5 comprises:
And S51, the intermediate router analyzes the header field of the explicit multicast message, extracts the target IP list, marks the target IP list as { IP1,IP2,...,IPm }, wherein m is a positive integer, the number of the target servers is represented, IP1 represents the 1 st target server, and IPm represents the m-th target server.
S52, the intermediate router executes longest prefix matching on the target IP address according to a real-time routing table and a path tree to generate a next hop interface packet G1,G2,...,GN, wherein N is a positive integer and represents the number of the next hop interface packets, the ith hop interface packet is represented by Gi, and the value range of i is [1, N ];
The intermediate router performs the following for each next hop interface packet Gi:
if only one IP address of the target server exists in the packet Gi, generating a unicast message, wherein the IP head target address of the unicast message is set as the unique IP address of the target server in the packet, and the load of the unicast message keeps the original detection request message;
If the packet Gi has a plurality of target server IP addresses and needs to be forwarded by an intermediate node of the same path, generating an explicit multicast sub-message, wherein an IP header extension field of the explicit multicast sub-message comprises all target server IP addresses of the packet, and the load of the explicit multicast sub-message keeps an original detection request message;
s54, the intermediate router forwards the unicast message or the explicit multicast sub-message to a next-hop interface or a target server, and meanwhile, the shortest path weight of the affected node in the path tree is updated based on an increment Dijkstra algorithm;
Repeating steps S51-S54 until all explicit multicast messages or sub-messages are unpacked into unicast messages and transmitted to the target server, and satisfying
Preferably, step S52 includes:
the intermediate router caches the extracted target IP list in a routing table of the router, wherein the entry format of the routing table is [ prefix, next hop interface ];
The method specifically comprises the steps of starting to match from the prefix item of the longest mask, finding the prefix which is matched with the IP address of the target server longest, recording the corresponding next hop interface, establishing the mapping relation between the IP address of the target server and the next hop interface, and storing the mapping relation into a temporary cache;
And taking the next hop interface as a key, taking the IP address of the target server as a value, combining the target IP addresses sharing the same next hop interface into the same packet, and carrying out parallel LPM inquiry on the target IP list.
Preferably, updating the shortest path weights of the affected nodes in the path tree based on the incremental Dijkstra algorithm includes:
Monitoring network link state change events in real time, including link state change time including any one or more of link cost update, node failure or newly added links;
Extracting an affected side V in a link from the link state change event, marking all nodes depending on the side in a path tree as affected nodes, and obtaining a set Vaffected, wherein any link node V epsilon Vaffected meets the condition that the original shortest path passes through the changed link;
for each affected node v EA local relaxation operation of the delta Dijkstra algorithm is performed:
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));
Wherein u is a source node of a changed link, dist (u) represents the shortest path from the source node to the node u, and w (u, v) represents the weight between the node u and the node v;
if dist (v) is updated, adding the updated node v into a priority queue and transmitting the node v to a subsequent node;
If the link cost is increased or disconnected, resetting the shortest path weight of the node v to infinity, removing the node from the priority queue, recalculating a new shortest path from the user end to the node v, updating the precursor node and the weight of the node v in the path tree, and synchronizing the updated path tree to the intermediate router and the user end through a routing protocol;
At this time, 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);
where E is the edge set of the network topology and w (u, v) is the link weight.
According to the scheme, the explicit multicast message is reasonably split, and the unicast message or the explicit multicast sub-message is selected to be split according to the path condition of the target IP address, so that unnecessary network resource waste can be avoided, redundant transmission is reduced, and data transmission efficiency is improved. Meanwhile, the shortest path weight of affected nodes in the path tree is updated in real time by using an incremental Dijkstra algorithm, so that a router can timely adjust a routing decision according to network topology changes, data is ensured to be always transmitted along an optimal path, and the dynamic adaptability and reliability of the network are enhanced.
In some embodiments, step S531 is further included between step S53 and step S54, where the intermediate router performs HMAC-SHA256 signature verification on the generated unicast message or explicit multicast sub-message, discards the message if the signature is invalid, and generates an ICMP error message to return to the client.
Specifically, when generating an explicit multicast message, a hash value may be calculated for the message content (including the header and payload) using the shared key K and an HMAC algorithm (e.g., HMAC-SHA 256), and the hash value may be appended as a signature to the message extension field. After generating a unicast message or an explicit multicast sub-message in step S53, extracting the original load and signature in the message, recalculating the HMAC value by using the same key K, comparing with the signature in the message, if the comparison is successful, continuing to execute step S54, if the comparison is failed, discarding the message, and generating an ICMP error message and returning to the user side. The ICMP error message includes an error code (for indicating a HMAC verification failure), diagnostic information, a timestamp, and the like.
According to the scheme, the HMAC verification is adopted to ensure that the message content is not tampered in the transmission process, an attacker cannot forge or modify the detection request, and in addition, invalid messages are discarded in time, so that error data can be prevented from being transmitted in a network, interference on path calculation is reduced, and network bandwidth and router processing resources are saved.
In some embodiments, after the next hop interface packet, the method further comprises:
and carrying out integrity check according to the packets, ensuring that the IP addresses of all the target servers have corresponding packets, and meeting the following formula conditions:;
if the IP address of a certain target server does not have a corresponding matching route, generating first prompt information which is used for prompting that the ICMP objective is not reachable and feeding back to the user side;
If the explicit multicast sub-message cannot be unpacked at the subsequent node, extracting the IP address of the target server in the header field of the explicit multicast sub-message to generate log information, discarding the explicit multicast sub-message, and generating second prompt information for prompting the reason that the message cannot be unpacked and the log information, and feeding back the second prompt information to the user side.
By means of the scheme, through integrity inspection, the problem that a routing table is incomplete (such as a routing black hole) is found in time, and traffic loss is reduced. After receiving the ICMP prompt, the user terminal can automatically trigger the route recalculation or fault recovery flow. The log information records the message and the node which cannot be unpacked in detail, and helps maintenance personnel to quickly locate the problem of protocol incompatibility.
In some embodiments, the probe request message includes a TCP SYN message or an ICMP request message, the method comprising:
Judging a target service type, wherein the target service type comprises TCP (transmission control protocol) service or non-TCP service, and setting a detection request message in an explicit multicast message load according to a judging result, and specifically comprises the following steps:
if the target service type is TCP type, the probe request message is set as TCP SYN message, and the target server of the response message which is received first and is aimed at the TCP SYN message is selected as the optimal server;
If the target service type is non-TCP service, the probe request message is set as an ICMP request message, and a target server of a response message which is received first and aims at the ICMP request message is selected as an optimal server.
By the scheme, the appropriate detection message can be selected according to the service type, the detection of TCP and non-TCP services can be processed, the method is suitable for complex network environments, the accuracy of service reachability detection is improved, and the service discovery delay is reduced by preferentially selecting the first-responding server.
In some embodiments, the method further comprises:
Deploying probe nodes, and periodically sending a plurality of batches of detection messages to each node in a network, wherein the detection messages comprise TCP SYN messages, ICMP request messages or QUIC short connection handshake messages;
According to the response message time sequence received by the probe node, calculating the potential neighbor connection probability among the nodes, and generating a probability adjacency matrix P= [ Pij]N×N ], wherein Pij represents the probability that a direct link exists between the node i and the node j, and the calculation formula is as follows:
;
Wherein tik is the response time of the node i in the kth detection, τ is a preset time difference threshold, and K is the detection times;
Filtering transient noise through a sliding window statistical model, and if the probability pij of a certain link is continuously lower than a dynamic threshold value theta=mu+2sigma, removing the link from the topological graph, wherein mu is a historical probability mean value, and sigma is a standard deviation;
obtaining a plurality of groups of pij in different unit time periods, and calculating the probability average value of pij in each unit time period to obtain a probability average value discrete number sequence;
performing linear regression fitting on the probability mean value discrete number sequence by adopting a least square method, generating a time sequence prediction function f (t) of inter-node link probability, selecting a node with the maximum probability prediction value as a direct link node, and constructing a preliminary network topology;
After the DNS inquiry is initiated by the user terminal, residual analysis is carried out 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 recalibration of topology data is triggered, the probability adjacency matrix is updated, and the network topology is reconstructed.
According to the scheme, the potential neighbor connection probability is calculated based on the response message time sequence, and the transient noise is filtered through the sliding window statistical model, so that the real connection relation between the nodes can be reflected more accurately, and erroneous judgment is reduced. And through carrying out residual analysis on the arrival time of the response message and the predicted value of f (t), if the absolute value of the residual exceeds a preset tolerance, the topology data recalibration is triggered, the probability adjacency matrix is updated, the network topology is reconstructed, the construction accuracy of the network topology can be effectively improved, further the follow-up shortest path tree is more accurate in confirmation, and the service preference is facilitated.
As shown in figures 2 and 3, the application constructs a method for supporting explicit multicast) The model architecture includes a DBS server, an intermediate router, a client, and a target server group providing a target service. Wherein, the m server groups for providing the target service are distributed at different area positions.
When the service is preferred, firstly, the service end sends a DNS query request aiming at the target service to a DNS server supporting explicit multicast, which is specifically described as followsThe service, assuming that the FQDN name of the target service is www.abc.com, the client sends a DNS query request for www.abc.com to the DNS server, and then the client obtains a DNS query result returned by the DNS server, where the result includes all the server IP addresses of the target service, which is specifically described as follows:
Assuming that the server serves the client DNS query request www.abc.com, the returned DNS query result is a= { IP1, IP2, ......, IPm }, recording the IP address of the ith server IPi (i=1, 2, 3..m.), m represents the number of servers providing the target service. The user side caches the IP addresses of all the m target servers. And then the server side sends out TCP SYN request messages or ICMP request messages to all the target servers in an explicit multicast mode according to the resolved IP addresses of the target servers.
Specifically, the user side may construct a shortest path with all servers providing the target service through Dijkstra algorithm (Dijkstra), and send a message requesting to establish a connection to all servers in an explicit multicast manner. Taking TCP connection as an example, as shown in fig. 2, C is taken as a client, an intermediate router represents a router supporting explicit multicast, the client first initiates a DNS query request to a DNS server, after obtaining a target IP list sent by the DNS server, constructs an explicit multicast message based on the target IP list, specifically, sets a destination address in a header of the explicit multicast message as an IP address list of the target server, and then sends the explicit multicast message to the target server along a shortest path tree. The ue monitors the response messages of each target server (IP1-IPm is the address corresponding to the target server in fig. 2), and uses the target server corresponding to the first valid response message arrived as the optimal server, for example, the valid response message of the target server with IP1 is the first to arrive at the ue in fig. 2, so as to confirm that the TCP connection between the ue and the target server with IP1 is established, and returns a TCP reset message to the ue for the target server with IP2-IPm, where the reset message is used to indicate that the target server port requested by the current ue is unavailable, so as to terminate the connection between the ue and the ue.
For services that do not support TCP, ICMP request messages are sent to all servers in an explicit multicast manner, and the overall interaction process is shown in fig. 3, where fig. 3 differs from fig. 2 only in the supported protocol, and is not expanded here. In fig. 3, C is a client, an intermediate router indicates a router supporting explicit multicast, a UDP (User Datagram Protocol ) service request refers to a process of sending request data to a target server based on a UDP protocol, and a corresponding UDP service response refers to a process of returning response data to the client after the target server receives a UDP service request sent by the client.
In short, the user terminal uses the first received TCP or ICMP detection response message as a reference, determines that the target server sending the response message is the optimal server of the current target service, and provides the subsequent service for the user terminal through the optimal server.
In order to make the technical solution and advantages of the present application more clear, the following will describe the steps S4 and S5 in more detail with reference to the NSFNet network (shown in fig. 5) including 14 nodes.
In order to more intuitively and clearly explain the innovation point and advantage of the technical scheme of the invention, the step S5 is systematically disassembled and deeply analyzed by combining the NSFNet network topology structure (see particularly figure 4) with 14 nodes, so as to aim at comprehensively and completely presenting the technical scheme details from the multidimensional degree of network transmission flow, algorithm execution logic and the like.
To ensure that the analysis result is representative, 1 node is selected randomly from 14 nodes of NSFNet networks shown in fig. 4 as a user terminal, and a plurality of nodes are selected as distributed server nodes. In this embodiment, the user terminal is randomly selected as node 1, and nodes 7, 14, 13, 10, 5, 11 are determined as distributed server nodes corresponding to the target service (i.e. target servers). Based on the path planning principle of Dijkstra algorithm, a corresponding path tree structure is constructed by taking a user end node as a root node and each target server node as a leaf node (see specifically fig. 5), and the following two dimensions of communication overhead and time overhead are developed for quantitative analysis:
Under the traditional unicast scene, the user side needs to sequentially send detection packets to 6 servers, the detection communication overhead is sequentially 2n, 3n, 4n, 3n and 3n according to the link hop count, the accumulated total overhead reaches 18n bytes, the time overhead is respectively 4t+alpha1、6t+α2+τ、8t+α3+2τ、6t+α4+3τ、6t+α5+4τ、6t+α6 +5τ due to the link transmission and CPU processing difference (wherein alpha represents the processing time delay and the link random time delay, τ is the CPU instruction period, and t represents the adjacent node transmission time). Finally, the node corresponding to the minimum time cost is selected as the optimal service, so that the total time costThe maximum value of the detection delay of each node can be represented, and the specific formula is as follows:
=max[4t+α1,6t+α2+τ,8t+α3+2τ,6t+α4+3τ,6t+α5+4τ,6t+α6+5τ].
Taking the explicit multicast scenario of the present invention as an example, the probe packet sent by the ue 1 to the nodes 7, 14, 13, 10 goes through the branch 1 above, where the explicit multicast probe packet a of the link of node 1- > node 8 has a size of n+4x3 (which means that the header field of the packet a needs to carry the IP addresses of 3 target servers in addition). When the message a is transferred to the node 8, it needs to be unpacked, specifically, into a common unicast message B and an explicit multicast sub-message C carrying IP addresses of another 2 target servers, where the message B is sent to the node 7, the size is n, the time overhead is 4t+β1 +γ, and the B is sent to the node 9, the size is n+4x2. When the message B arrives at the node 9, it needs to be unpacked, and is respectively unpacked into 3 common unicast messages, and then the unpacked messages are respectively forwarded to the nodes 14, 13 and 10, so that the time cost of the three links is 6t+β2+2γ、8t+β3+2γ、6t+β4 +2γ. Thus, the branch 1 probe overhead is (n+4×3) +n+ (n+4×2) +n+2n+n=7n+20.
Similarly, the probe packet sent by the node 1 (i.e. the user end) to the nodes 5 and 11 goes through the branch 2 below, where the communication overhead is (n+4x1) + (n+4x1) in the explicit multicast probe packet D of the link of the node 1- > node 2- > node 4, D is transferred to the node 4 and needs to be unpacked, and is respectively unpacked into 2 common unicast probe packets, and then is respectively forwarded to the node 5 and the node 11, and the time overhead is 6t+τ+β5 +γ and 6t+τ+β6 +γ, where β includes a processing delay, a link randomness delay, and γ is any multicast unpacking delay, so the probe overhead of the branch 2 is (n+4x1) + (n+4x1) +n=4n+8. It is not difficult to derive that the total communication overhead is 11n+28 bytes. Because the scheme selects the node which responds first as the optimal service, the time cost is highThe minimum value of the detection time delay for each service node is expressed as follows:
=min[4t+β1+γ, 6t+β2+2γ, 8t+β3+2γ, 6t+β4+2γ, 6t+β5+τ+γ, 6t+β6+τ+γ].
The traditional unicast mode is compared with the scheme of the invention in terms of communication overhead, namely, the minimum size n of the probe packet is more than or equal to 64 bytes according to the Ethernet protocol specification. Through calculation, the communication overhead difference value 18n- (11n+28) =7n-28 between the traditional unicast and the scheme of the invention is constantly larger than 0, and the invention has obvious advantages in communication efficiency.
The traditional unicast mode is compared with the scheme of the invention in terms of time overhead by assuming that the processing delay is consistent with the random delay (alphaii, i epsilon [1,6 ]) under the same link, and the CPU consumption of the explicit multicast unpacking is equivalent to that of unicast forwarding (i.e. tau=gamma), the method is characterized in that the method comprises the following steps ofAnd (3) withSystematic deductions are made. No matter what node is taken by the maximum delay value in the traditional unicast scene, the method can prove that>I.e. the inventive solution is equally excellent in terms of time efficiency.
The explicit multicast technique adopted by the invention is not limited by specific network topology, and shows stable performance advantages in NSFNet and various scale networks. The simulation experiment data further verifies the rationality of theoretical assumption, and the larger the network scale is, the higher the node density is, the more remarkable the advantages of the scheme in terms of communication and time cost are.
The invention effectively breaks through the bottleneck of multicast IP address resource shortage through an explicit multicast mechanism, reduces network communication load, greatly shortens optimal service searching time, and remarkably improves service acquisition efficiency of a user side. In addition, the scheme does not need to modify a server, has strong compatibility with the existing OSD system, is particularly suitable for scenes such as low-density distributed service, object Storage Device (OSD) systems, optimal task unloading in edge calculation and the like, and has extremely high engineering practical value and application potential.
In a second aspect, the present invention also provides a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements the explicit multicast-assisted best service discovery method according to the first aspect of the present invention.
Wherein the computer readable storage medium may be volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory.
The non-volatile Memory may be a Read Only Memory (ROM), a programmable Read Only Memory (PROM, programmable Read Only Memory), an erasable programmable Read Only Memory (EPROM, erasable Programmable Read Only Memory), an electrically erasable programmable Read Only Memory (EEPROM, ELECTRICALLY ERASABLE PROGRAMMABLE READ ONLY MEMORY), a magnetic random access Memory (FRAM, ferromagnetic random access Memory), a Flash Memory (Flash Memory), a magnetic surface Memory, an optical disk, or a compact disk Read Only Memory (CD ROM, compact Disc Read Only Memory), and the magnetic surface Memory may be a magnetic disk Memory or a tape Memory.
The volatile memory may be a random access memory (RAM, random Access Memory) which acts as an external cache. By way of example, and not limitation, many forms of RAM are available, such as static random access memory (SRAM, static Random Access Memory), synchronous static random access memory (SSRAM, synchronous Static Random Access Memory), dynamic random access memory (DRAM, dynamic Random Access Memory), synchronous dynamic random access memory (SDRAM, synchronous Dynamic Random Access Memory), double data rate synchronous dynamic random access memory (ddr SDRAM, double Data Rate Synchronous Dynamic Random Access Memory), enhanced synchronous dynamic random access memory (ESDRAM, enhanced Synchronous Dynamic Random Access Memory), synchronous link dynamic random access memory (SLDRAM, syncLink Dynamic Random Access Memory), direct memory bus random access memory (DRRAM, direct Rambus Random Access Memory). The computer-readable storage media described in connection with the embodiments of the present invention are intended to comprise these and any other suitable types of memory.
As shown in fig. 6, in a third aspect, the present invention provides an electronic device 10, including a processor 101 and a storage medium 102, where a computer program is stored, the computer program, when executed by the processor, implementing an explicit multicast assistance based optimal service discovery method according to the first aspect of the present invention.
In some embodiments, the Processor may be implemented in software, hardware, firmware, or a combination thereof, and may use at least one of a Circuit, a single or multiple Application-specific integrated circuits (ASIC), a digital signal Processor (DIGITAL SIGNAL Processor, DSP), a digital signal processing device (DIGITAL SIGNAL Processing Device, DSPD), a programmable logic device (Programmable Logic Device, PLD), a field programmable gate array (Field Programmable GATE ARRAY, FPGA), a central Processor (Central Processing Unit, CPU), a controller, a microcontroller, a microprocessor, or any combination thereof, so that the Processor may perform some or all of the steps in the explicit multicast assistance-based optimal service discovery method described in various embodiments of the present application.
It should be noted that, although the foregoing embodiments have been described herein, the scope of the present invention is not limited thereby. Therefore, based on the innovative concepts of the present invention, alterations and modifications to the embodiments described herein, or equivalent structures or equivalent flow transformations made by the present description and drawings, apply the above technical solution, directly or indirectly, to other relevant technical fields, all of which are included in the scope of the invention.

Claims (10)

CN202510736090.9A2025-06-042025-06-04Optimal service discovery method, medium and device based on explicit multicast assistanceActiveCN120263717B (en)

Priority Applications (1)

Application NumberPriority DateFiling DateTitle
CN202510736090.9ACN120263717B (en)2025-06-042025-06-04Optimal service discovery method, medium and device based on explicit multicast assistance

Applications Claiming Priority (1)

Application NumberPriority DateFiling DateTitle
CN202510736090.9ACN120263717B (en)2025-06-042025-06-04Optimal service discovery method, medium and device based on explicit multicast assistance

Publications (2)

Publication NumberPublication Date
CN120263717Atrue CN120263717A (en)2025-07-04
CN120263717B CN120263717B (en)2025-08-22

Family

ID=96181778

Family Applications (1)

Application NumberTitlePriority DateFiling Date
CN202510736090.9AActiveCN120263717B (en)2025-06-042025-06-04Optimal service discovery method, medium and device based on explicit multicast assistance

Country Status (1)

CountryLink
CN (1)CN120263717B (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication numberPriority datePublication dateAssigneeTitle
US20050015511A1 (en)*2003-07-022005-01-20Nec Laboratories America, Inc.Accelerated large data distribution in overlay networks
WO2006120893A1 (en)*2005-05-122006-11-16Matsushita Electric Industrial Co., Ltd.Packet relay method and home agent
CN101322355A (en)*2005-10-052008-12-10北方电讯网络有限公司 Provider Link State Bridging
CN102387203A (en)*2011-10-212012-03-21南京邮电大学SOAP (simple object access protocol)-based multicast application method in Internet of Things
CN104703243A (en)*2015-03-142015-06-10西安电子科技大学Multicasting routing method based on secondary link in wireless distributed network

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication numberPriority datePublication dateAssigneeTitle
US20050015511A1 (en)*2003-07-022005-01-20Nec Laboratories America, Inc.Accelerated large data distribution in overlay networks
WO2006120893A1 (en)*2005-05-122006-11-16Matsushita Electric Industrial Co., Ltd.Packet relay method and home agent
CN101176315A (en)*2005-05-122008-05-07松下电器产业株式会社 Packet Relay Method and Home Agent
CN101322355A (en)*2005-10-052008-12-10北方电讯网络有限公司 Provider Link State Bridging
CN102387203A (en)*2011-10-212012-03-21南京邮电大学SOAP (simple object access protocol)-based multicast application method in Internet of Things
CN104703243A (en)*2015-03-142015-06-10西安电子科技大学Multicasting routing method based on secondary link in wireless distributed network

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ABDERRAHIM BENSLIMANE 等: "EM2NET: An Energy-Saving Explicit Multicast Protocol for MANETs", IEEE GLOBECOM 2007 - IEEE GLOBAL TELECOMMUNICATIONS CONFERENCE, 26 December 2007 (2007-12-26), pages 592 - 597*
刘军;程良伦;王建华;: "一种传感器网络的分布式多播路由优化算法", 电子与信息学报, no. 10, 15 October 2013 (2013-10-15), pages 46 - 52*
周艳玲: "MPLS网络下多播技术的研究", 中国优秀硕士学位论文全文数据库 信息科技辑, 31 August 2010 (2010-08-31), pages 136 - 6*

Also Published As

Publication numberPublication date
CN120263717B (en)2025-08-22

Similar Documents

PublicationPublication DateTitle
CN101573927B (en) Path Maximum Transmission Unit Discovery in Network System
CN106375231B (en)A kind of flow switching method, equipment and system
EP3167594B1 (en)Caching data in an information centric networking architecture
US11418405B2 (en)Systems and methods for determining a topology of a network comprising a plurality of intermediary devices and paths
US9825861B2 (en)Packet forwarding method, apparatus, and system
US20150058470A1 (en)System and method for sharing vxlan table information with a network controller
US20070233832A1 (en)Method of distributed hash table node ID collision detection
US10277686B2 (en)Service discovery optimization in a network based on bloom filter
Gupta et al.Efficient and adaptive epidemic-style protocols for reliable and scalable multicast
Torres et al.An autonomous and efficient controller-based routing scheme for networking Named-Data mobility
KR101604970B1 (en)Finding services in a service-oriented architecture(soa) network
CN101529809A (en)Distributed storage of routing information in a link state protocol controlled network
US20190372906A1 (en)Preventing duplication of packets in a network
US20160134534A1 (en)Switching device, controller, method for configuring switching device, and method and system for processing packet
JP5858141B2 (en) Control device, communication device, communication system, communication method, and program
US20180205644A1 (en)Communication processing method and apparatus
WO2018214853A1 (en)Method, apparatus, medium and device for reducing length of dns message
CN108989220B (en)Routing method and routing system
CN108141463A (en)For Internet of Things resource discovering and the distributive resources list based on ICN of routing
CN120263717B (en)Optimal service discovery method, medium and device based on explicit multicast assistance
WO2012146104A1 (en)Method, device and system for updating port information
US10541914B2 (en)Data packet forwarding method and network device
US9917764B2 (en)Selective network address storage within network device forwarding table
Dong et al.ICN based distributed IoT resource discovery and routing
Zghaibeh et al.d-SHAM: a constant degree-scalable homogeneous addressing mechanism for structured P2P networks

Legal Events

DateCodeTitleDescription
PB01Publication
PB01Publication
SE01Entry into force of request for substantive examination
SE01Entry into force of request for substantive examination
GR01Patent grant
GR01Patent grant

[8]ページ先頭

©2009-2025 Movatter.jp