Low-latency content acquisition method under subscription and publication mode

Abstract

The application relates to a low-latency content acquisition method for a content subscription and publication mode in NDN. In the content subscription and publication mode establishment process, a multicast tree with a publisher as a root and covering all subscribers is established by using the subscription request information sent by the subscribers to the publisher, and key nodes in the multicast tree are selected according to the positions of the nodes in the multicast tree and the number of received subscription response packets, the subscription multicast tree is maintained through the key nodes, and the subscription information publication efficiency is improved. The strategy can make the subscription nodes obtain the required content from the key nodes or the publisher in time by constructing and maintaining the key nodes in the subscription multicast tree, so that the content acquisition latency of the subscribers is reduced.

Description

Technical Field

[0001] This invention relates to a low-latency content retrieval strategy based on a publish-subscribe model. By incorporating the construction of a subscription multicast tree rooted at the publisher and covering all subscribers into the publish-subscribe model, the content retrieval latency is reduced and the efficiency of the publisher pushing updated information to content requesters is improved. Background Technology

[0002] The publish / subscribe system, widely used in distributed computing and data synchronization scenarios, is an application- and service-oriented communication model. It's a content-based addressing model characterized by loose coupling, many-to-many relationships, asynchronous communication, and anonymity. In TCP / IP networks, implementing this model typically requires a complex middleware structure to manage subscribed content and information. Publishers categorize topics and send changes to the middleware, which then constructs a subscription directory and pushes it to subscribers. Subscribers send subscription requests to the middleware based on their own needs from the pushed message directory, and the middleware uses the subscribers' subscription information to request subscriptions from the publishers. This approach often requires a complex middleware structure to manage information between publishers and subscribers and to select the optimal route for message pushing.

[0003] NDN possesses characteristics of logical consistency between topology and context, natural suitability for multicast, intra-network caching, and multi-path forwarding, making it a better fit for the publish-subscribe model. NDN also exhibits these characteristics: logical consistency between topology and context, natural suitability for multicast communication, network caching, and multi-path forwarding.

[0004] (1) Topological logical consistency

[0005] The basic granularity of data communication in NDN is based on content names, and the logical topology for content transfer between upper and lower layers is consistent in NDN.

[0006] (2) Naturally suitable for multicast communication

[0007] In NDN, the relationship between content providers and content consumers is often many-to-many, so NDN is naturally suitable for multicast communication.

[0008] (3) In-network caching

[0009] Compared to TCP / IP, routing nodes in NDN cache the contents of data packets for a certain period of time after forwarding them, thus giving NDN a stronger intranet caching capability.

[0010] (4) Multipath forwarding

[0011] Because of the structure of the Pending Interest Table (PIT) in NDN, it is known that NDN is easier to implement multipath forwarding.

[0012] Because of the above characteristics, NDN eliminates the need for complex middleware structures to maintain the publish-subscribe pattern, thus reducing network load and improving overall network performance. Most publish-subscribe implementations in NDN employ a model where publishers push content update notifications, and subscribers "pull" the updated content. The PSync strategy is the most representative. The PSync strategy explicitly includes consumer subscription information and producer dataset state in interest / data exchange, minimizing the soft state information retained by the producer. Furthermore, it supports full synchronization among a group of participants, with the advantage that consumer subscription state is maintained by the consumer itself and offers high scalability. However, while PSync can perform basic data synchronization, it doesn't effectively optimize for duplicate requests, and data reception latency remains unreduced. Summary of the Invention

[0013] To address the aforementioned issues, a subscription multicast tree structure is added to the existing PSync strategy subscription initialization and content publishing processes. This integrates the construction and maintenance of the subscription multicast tree into the subscription initialization and content update phases, thereby improving the efficiency of publishers' content updates and subscribers' content retrieval.

[0014] To achieve the above objectives, the present invention adopts the following technical solution: on the basis of the NDN publish-subscribe PSync strategy, the construction of a subscription multicast tree structure is added, and the construction and maintenance process of the subscription multicast tree is added to the subscription initialization stage and the content update stage, thereby improving the efficiency of publisher content updates and subscriber content acquisition.

[0015] Step 1: Modify the structure of the Interest and Data packages in NDN, add the MT table, and add the KeyNode node role to the publisher and subscriber node roles in the publish-subscribe pattern:

[0016] Add the `routable_preix` field to the `Interest` and `Data` packages;

[0017] The MT table consists of four parts: the subscribed topic name, the incoming interface, the outgoing interface, and the creation time (Time stamp).

[0018] Step two: After the content requester sends an Interest packet to the network, the subscription initialization phase proceeds as follows:

[0019] (1) Construction of the Hello package: The Hello package is the Interest package used to build the publish-subscribe relationship. The subscriber uses its own node number i and " / Mhello" as the Content Name;

[0020] (2) Hello packet processing: If the node is not a producer, check if there is a corresponding entry in the MT table. If there is a corresponding entry in the MT table, forward the packet according to the corresponding entry record in the MT table; if there is no corresponding entry in the MT table, add a new entry in the MT table and forward the Hello packet as an Interest packet.

[0021] (3) Publishing list maintenance: After receiving the Hello packet, the publisher adds the subscriber information and subscription content in the Hello packet to the publishing list maintained by the publisher, and then constructs a Data packet for response based on the Content Name of the received Hello packet;

[0022] (4) Subscriber node requests subscription content: After receiving the corresponding Data packet, the intermediate node maintains the MT information according to the forwarding situation and forwards the Data packet. When the intermediate routing node meets the key node identity judgment condition, the node sets its own role as a key node.

[0023] (5) Construct a multicast tree structure:

[0024] 5.1 After receiving the Interest packet, the node determines the type of Interest packet based on the Content Name of the Interest packet. If it is a Hello packet, proceed to 5.2; if it is a sync packet, proceed to 5.3.

[0025] 5.2 After obtaining the subscription information from the Hello packet, the intermediate routing node adds the subscription type name and receiving interface number to the MT table, and then proceeds to 5.4;

[0026] 5.3 The intermediate routing node adds the subscription type name and forwarding interface number to the MT table based on the received sync packet, constructs the multicast tree structure, and forwards the sync packet according to the PT table. The multicast tree construction is completed.

[0027] 5.4 The publisher matches the subscribed content in the received Hello package with its own maintained subscription list. If the requested subscription topic does not exist, the build process ends; if a corresponding record exists, the publisher adds its relevant content to the newly added `routable_prefix` in the Data package based on the subscription list, and then returns the Data package along the original path.

[0028] 5.5 After the intermediate node responds to the Hello packet with a Data packet, it compares the content with the appearance in the MT table. If a corresponding entry exists and the source interface is not in the interface list of the Outgoing interface, the interface number is added to the Outgoing interface and the Data packet is forwarded. If there is no corresponding record in the MT, the Data packet is forwarded in the normal routing mode.

[0029] (6) Key node role election:

[0030] 6.1 Subscribing nodes construct Hello packets according to their own needs and send them to the network;

[0031] 6.2 After receiving the Hello packet, the publisher node constructs a Data packet for response and forwards it from the receiving interface;

[0032] 6.3 The intermediate routing node between the subscriber and publisher nodes records the received Hello packets and Data packets used for response based on the received packets, and maintains the KeyNode value of the intermediate node.

[0033] 6.4 Based on the number of responses received from the Hello packet and the degree of the intermediate node, intermediate nodes with two or more branches and a KeyNode greater than 2 are designated as key nodes.

[0034] (7) Maintenance of the multicast subscription tree structure:

[0035] 7.1 If the intermediate node receives an Interest packet of type Hello, the intermediate node will add the subscription type name and receiving interface number to its own MT table entry; if the received Interest packet is of type sync, the intermediate node will add the subscription type name and forwarding interface number to the MT table.

[0036] 7.2 After receiving the Hello packet, the publisher node matches the subscribed content in the Hello packet with the subscription list maintained by the publisher node. If the subscribed content in the Hello packet matches the subscription list, it constructs a Data packet to respond to the Hello packet based on the matching entry, adds its own relevant content to the routable_prefix entry in the Data packet, and forwards it to the network.

[0037] 7.3 After the intermediate node responds to the Hello packet with a Data packet, it compares the content with the appearance in the MT table. If a corresponding entry exists and the source interface is not in the interface list of the Outgoing interface, the interface number is added to the Outgoing interface and the Data packet is forwarded. If there is no corresponding record in the MT, the Data packet is forwarded in the normal routing mode.

[0038] In the Interest package, the Content Name field is the content name, the Selector field is the selector structure, and the Nonce field generates a random number. In this section, the Interest package used to build the publish-subscribe relationship is called the Hello package, and the Interest package used to synchronize published information is called the sync package. The Hello and sync packages are distinguished from ordinary Interest packages by their ContentName, and the `routable prefix` field records the field names subscribed to by subscribers.

[0039] In the Data packet, Content Name is the content name, Content is the content corresponding to the Interest received, Signature is the content signature, and the routine_preix field is a newly added structure containing subscription information.

[0040] The MT table contains the following: Subscribe name (the node's forwarding interface number for the Hello packet); Incoming interface (the node's receiving interface number); Outgoing interface (the node's forwarding interface number); and Time stamp (creating a time node for the interface to maintain the timeliness of the corresponding entry).

[0041] The beneficial effects of this invention are as follows: Adding a multicast tree structure to the publish-subscribe model enables timely and efficient push-based delivery. Subscribers send subscription information to publishers to establish forwarding paths, thereby creating a multicast shared tree rooted at the publisher and covering all subscribers. Simultaneously, the introduction of key node roles optimizes the publish-subscribe model. This eliminates the need for subscribers to poll the publisher to maintain the publisher list for the latest data, allowing publishers to focus on publishing tasks and reducing communication latency. Attached Figure Description

[0042] Figure 1 This is a diagram of the Interest package structure;

[0043] Figure 2 This is a diagram of the Data package structure;

[0044] Figure 3 This is a diagram of the MT table structure;

[0045] Figure 4 This is the overall algorithm flowchart;

[0046] Figure 5 This is a flowchart of the subscription initialization phase;

[0047] Figure 6 This is a flowchart of the content synchronization phase;

[0048] Figure 7 It is the topology of DFN;

[0049] Figure 8 It is the Deltacom topology;

[0050] Figure 9 This shows how the average push update latency in DFN changes with the number of data pushes;

[0051] Figure 10 This shows how the average push update latency in Deltacom changes with the number of data pushes.

[0052] Figure 11 This describes how the average subscription list update completion time changes with the average number of subscriptions in DFN;

[0053] Figure 12 This shows how the average subscription list update completion time changes with the average number of subscriptions in Deltacom;

[0054] Figure 13 This shows how the average delivery latency in DFN changes with the number of pushes;

[0055] Figure 14 This shows how the average delivery latency in Deltacom changes with the number of push notifications. Detailed Implementation

[0056] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0057] This patent is based on the publish-subscribe model. The construction and maintenance process of the subscription multicast tree is incorporated into the subscription initialization stage and the content update stage, which improves the efficiency of publishers in updating content and subscribers in acquiring content. By constructing the subscription multicast tree, the Msync strategy reduces the content acquisition latency of content requester nodes and increases the efficiency of publisher nodes pushing update information to content requester nodes.

[0058] This invention is achieved through the following technical solution: The Interest and Data packages in NDN are modified, and an MT table structure is added. The specific structure of the Data package is as follows... Figure 1 As shown, the specific structure of the Interest package is as follows: Figure 2 As shown, the shaded areas represent newly added fields. The MT table structure is as follows: Figure 3 .in:

[0059] In the Interest package, the Content Name field is the content name, the Selector field is the selector structure, and the Nonce field generates a random number. The Interest package used to build publish-subscribe relationships is called the Hello package, and the Interest package used for synchronizing published information is called the sync package. Hello and sync packages are distinguished from ordinary Interest packages by their Content Name. A `routable prefix` field is added to the Interest package to record the field names subscribed to by subscribers.

[0060] In the Data packet, Content Name is the content name, Content is the content corresponding to the received Interest, Signature is the content signature, and the `routable_preix` field is a newly added structure containing subscription information. After receiving the Hello packet, the content requester constructs a Data packet to respond to the subscription request based on the subscribed content in the Hello packet. The Content Name of the received Hello packet, along with the corresponding publisher's node identifier structure, is used as the Content Name for the response Data packet.

[0061] The MT table is used to construct and maintain the subscription multicast tree. In MT, the Subscribe name is the node's forwarding interface number for the Hello packet; the Incoming interface is the interface number for the node to receive the corresponding sync packet; and the Outgoing interface is the interface number for the node to receive the corresponding hello packet. The multicast tree structure is constructed through the Incoming and Outgoing interfaces.

[0062] Figure 4 This describes the overall algorithm process, which consists of three parts: the subscription initialization phase algorithm flow, the content push phase algorithm flow, and the multicast tree construction and maintenance algorithm flow. In the subscription initialization phase, the subscription multicast tree is constructed. In the content push phase, information is pushed to subscribers based on the multicast tree constructed in the initialization phase. At the same time, the multicast tree is maintained through the content push phase. Figure 5 This describes the algorithm flow during the subscription initialization phase. Figure 6 This describes the algorithm flow during the content delivery phase.

[0063] 1. Algorithm process during the subscription initialization phase

[0064] (1) During the subscription initialization phase, the subscriber constructs a Hello packet based on the subscription content and sends the Hello packet to the publisher node. The intermediate routing node between the subscriber and publisher nodes receives the Hello packet and constructs a multicast tree structure based on the information in the Hello packet. The subscriber node constructs the Hello packet according to its own needs and the subscription prefix.

[0065] (2) Describe the processing flow of the intermediate routing node between the subscriber and the publisher after receiving the Hello packet. The intermediate routing node maintains the MT based on the subscription content in the Hello packet. If a corresponding entry exists in the MT, the structure of the received Hello packet is added to the corresponding receiving interface list and the Hello packet is discarded. If a corresponding entry does not exist in the MT, a new item is added to the MT based on the subscription topic and the interface for receiving the Hello packet in the Hello packet, and the Hello packet is forwarded to the publisher.

[0066] (3) describes the response process of the publisher to the subscriber after receiving the Hello packet during the subscription initialization phase. After receiving the Hello packet, the publisher constructs a Data packet for response based on the Hello packet and sends it to the subscriber.

[0067] (4) Describe the process by which the intermediate routing node maintains the MT content after receiving the Data packet used for acknowledgment. Upon receiving the Data packet used for acknowledgment, if a corresponding entry exists in the MT, the interface that received the Data packet is added to the output interface list of the corresponding entry; otherwise, the Data packet used for acknowledgment is discarded.

[0068] (5) Describe the selection process of key nodes. After forwarding the Hello packet, the nodes construct a subscription multicast tree based on the MT structure, with the publisher as the root and covering all subscribers.

[0069] 2. Algorithm process during content delivery phase

[0070] After the subscription initialization phase is completed, subscribers obtain subscription information based on the multicast subscription tree during the subscription initialization phase.

[0071] (1) Content subscribers build a sync package based on the list of subscribed content and forward the constructed sync package to the publisher to update the subscription list.

[0072] (2) Describe the role of the key nodes established in the subscription initialization phase in the content publishing phase.

[0073] (3) If there is no entry corresponding to the received sync packet in the MT structure of an important node, the important node will forward the sync packet as a normal Interest packet. If the time interval between the most recent updates of the corresponding MT entry is too long, the sync packet will be forwarded to the content publisher to maintain the subscription multicast tree and the timeliness of the subscription list.

[0074] (4) The subscription list in the description key node does not need to be updated. The key node builds the corresponding Data package based on the content in the sync package and forwards it to the subscriber to update the subscriber's update list.

[0075] 3. Key Node Maintenance Process

[0076] (1) During the subscription initialization phase, after the key node receives the Data package built by the publisher based on the sync package, it updates the subscription list and MT based on the received information.

[0077] (2) The number of MTs is denoted as Type Number, and the number of interface numbers is denoted as Key Node. During the content publishing process, after the content of the key nodes is updated, the key nodes with a Type Number or Key Node value less than 2 are changed to ordinary intermediate routing nodes.

[0078] (3) After the subscription initialization phase is completed, a subscription multicast tree with the publisher as the root and covering all subscribers is constructed.

[0079] (4) If a subscriber node decides to exit the subscription-publish relationship, the subscriber builds a special sync package. This special sync package is based on the sync package structure, but adds " / GETOUT" to the Content Name to distinguish it from the sync package structure used for content synchronization.

[0080] (5) Describe the operation flow of key nodes in the pruning process. The interface number of the key node that receives the special sync packet is denoted as n. For all entries in the key interface list, remove interface n from the receiving interface list, and then remove any entries whose receiving interface list is empty after removing interface n.

[0081] Experimental setup and evaluation

[0082] A simulation environment was built using a simulation program to conduct simulation experiments on the Msync strategy, and the performance of the Msync strategy was evaluated based on the simulation results. This section first introduces the experimental setup, listing the experimental topology and related parameters, then introduces the relevant evaluation metrics, and finally analyzes the simulation results.

[0083] I. Experimental Setup

[0084] Based on the NDN basic communication mode simulation program, this paper simulates the node structure and the subscription initialization and content push phases, simulating the communication process between Interest and Data packets. The PSync strategy uses content names to carry producer namespace information and consumer subscription information, enabling producers to maintain a state for all consumers and allowing consumers to synchronize with any producer replicating the same data. This paper incorporates the PSync strategy, the PSync_BMS strategy (based on PSync and incorporating an NDN distributed repository), and the proposed Msync strategy into the simulation code. The PSync_BMS strategy is built upon the idea of ​​using a distributed NDN repository to store and redistribute large amounts of BMS data usable by different applications, as presented in ndnBMS-PS, and is constructed on the basis of the PSync simulation program. The simulation program is built on Windows based on the PSync implementation in the NDN codebase. The simulation program includes the PSync_BMS strategy (adding a shared BMS mechanism to PSync) and the Msync strategy proposed in this chapter. The communication process of the subscription-publish-subscribe model is still simulated using two commonly used topologies: DFN and Deltacom.

[0085] The experimental topologies used were DFN and Dletacom. Figure 7 This describes a DFN topology with 31 nodes, including three publisher nodes, seven subscriber nodes, and 22 average data streams. Publisher and subscriber nodes are evenly distributed along the edges of the DFN topology. Figure 8 This describes the Deltacom topology, which has 113 nodes. Subscriber and publisher nodes are located at the edges of the Deltacom topology. In Deltacom, publisher and subscriber nodes are evenly distributed on the periphery of the topology. The routing structure between publisher and subscriber nodes in Deltacom is more complex than that in DFN.

[0086] II. Performance Evaluation

[0087] This article compares the performance of the strategies using the following three performance metrics:

[0088] (1) Average Push Update Delay (APD): The average time interval between the start of all publishers pushing content in the topology and the last time the message used to exchange the subscription list or update list is discarded.

[0089] (2) Average Subscribe Update Delay (ASD): The average time period from the moment when all subscribers in the topology send subscription requests until the moment when the last message exchanging or updating subscription lists between the networks is dropped.

[0090] (3) Average Grant Delay (AGD): The average time interval between the time when a subscriber sends a Data packet and the time when the subscriber receives the corresponding content request Data packet in the topology.

[0091] 1 Average push update latency

[0092] Figure 9 and Figure 10 This describes the changes in the number of times content is pushed by the APD publisher per unit of time. Figure 9 This describes how the APD changes in DFN based on the number of pushes per unit time for each publisher using three simulation strategies: PSync, PSync_BMS, and Msync. Figure 10 This describes the variation of APD (Average Continuous Distance) as the number of times publisher nodes push content per unit time in a Deltacom topology using three simulation strategies: PSync, PSync_BMS, and Msync. As the number of publisher nodes pushes increases, the latency for completing the publish-subscribe activity also increases, but the extended schemes are all lower than the original protocol. This is because there are more nodes with publisher status than in the original protocol, making it more likely that subscriber nodes will obtain updated data from closer sources. Msync increases the number of nodes with publisher status by building a multicast tree, while reducing the number of update steps. PSync_BMS has a repository; when the data push frequency is low, the Msync strategy has fewer publisher nodes, and the need to maintain the multicast subscription tree increases network congestion, resulting in a slightly lower average push latency for Msync than PSync_BMS at low push frequencies. As the publisher content push frequency increases, the multicast tree data packet forwarding efficiency improves, and there are more nodes with publisher status in the multicast tree, causing the Msync content push efficiency to gradually fall below that of PSync_BMS.

[0093] 2. Average subscription list update completion delay

[0094] Figure 11 and Figure 12 This describes how ASD changes with the number of subscriptions. Figure 11This describes how the ASD changes with the number of times a content subscriber subscribes to content per unit time in DFN using three simulation strategies: PSync, PSync_BMS, and Msync. When the number of pushes and the number of data streams remain constant, an increase in the number of subscriptions means that the proportion of subscription activities in the total activities is increasing. Figure 12 This describes the variation of ASD (Advanced Distributed Memory Scale) with the number of data pushes per unit time in a Deltacom topology using three simulation strategies: Sync, PSync_BMS, and Msync. It can be seen that with a fixed number of pushes, the latency of completing the subscription and publish task increases with the number of subscriptions. However, because PSync_BMS adds a core component, `repo`, to PSync, increasing the number of nodes with content provider intelligence, its content push efficiency is superior to the PSync strategy. Msync, during the subscription initialization phase, not only increases the number of nodes with content provider functionality by selecting key nodes during multicast tree construction, but also improves the efficiency of content delivery during the push phase through the subscription tree structure. When a key node receives a forwarded update request, it directly pushes data updates through the relationships between nodes in the subscription tree, thereby reducing data transmission latency. Because the key nodes in the Msync strategy are located in key positions in the multicast tree, its content push efficiency is higher than PSync_BMS, and its content push latency is lower.

[0095] 3. Average Issuance Delay Analysis

[0096] Figure 13 and Figure 14 This describes how AGD changes with the number of subscriptions. Figure 13 This describes how the AGD changes in DFN based on the number of times a content subscriber subscribes to content per unit time using three simulation strategies: PSync, PSync_BMS, and Msync. Figure 14 This describes the variation of AGD (Automatic Gain Depth) per unit time in a Deltacom topology using three simulation strategies: PSync, PSync_BMS, and Msync. PSync_BMS and Msync perform better than PSync in terms of data delivery latency, increasing with the number of data pushes, but the former's increase is less than the latter's. The high latency of the original protocol is caused by the repeated transmission of the same data packets. PSync_BMS adds nodes with a repo component, improving the efficiency of content delivery through content replication and collection via the repo. Msync reduces the latency of the same data push by the publisher through multicast tree construction. The Msync strategy has lower data delivery latency than the PSync_BMS strategy.

Claims

1. A method for obtaining low-latency content under a publish-subscribe model, characterized by: Step 1: Modify the structure of the Interest and Data packages in NDN, add the MT table, and add the KeyNode node role to the publisher and subscriber node roles in the publish-subscribe pattern: Add the `routable_preix` field to the `Interest` and `Data` packages; The MT table consists of four parts: the subscribed topic name, the incoming interface, the outgoing interface, and the creation time (Time stamp). Step two: After the content requester sends an Interest packet to the network, the subscription initialization phase proceeds as follows: (1) Construction of the Hello package: The Hello package is the Interest package used to build the publish-subscribe relationship. The subscriber uses its own node number i and " / Mhello" as the Content Name; (2) Hello packet processing: If the node is not a producer, check if there is a corresponding entry in the MT table. If there is a corresponding entry in the MT table, forward the packet according to the corresponding entry record in the MT table. If the corresponding entry does not exist in the MT table, after adding the new entry to the MT table, the Hello packet will be forwarded as an Interest packet. (3) Publishing list maintenance: After receiving the Hello packet, the publisher adds the subscriber information and subscription content in the Hello packet to the publishing list maintained by the publisher, and then constructs a Data packet for response based on the Content Name of the received Hello packet; (4) Subscriber node requests subscription content: After receiving the corresponding Data packet, the intermediate node maintains the MT information according to the forwarding situation and forwards the Data packet. When the intermediate routing node meets the key node identity judgment condition, the node sets its own role as a key node. (5) Construct a multicast tree structure: 5.1 After receiving the Interest packet, the node determines the type of Interest packet based on the Content Name of the Interest packet. If it is a Hello packet, proceed to 5.2; if it is a sync packet, proceed to 5.

3. 5.2 After obtaining the subscription information from the Hello packet, the intermediate routing node adds the subscription type name and receiving interface number to the MT table, and then proceeds to 5.4; 5.3 The intermediate routing node adds the subscription type name and forwarding interface number to the MT table based on the received sync packet, constructs the multicast tree structure, and forwards the sync packet according to the PT table. The multicast tree construction is completed. 5.4 The publisher matches the subscribed content in the received Hello package with its own maintained subscription list. If the requested subscription topic does not exist, the build process ends. If a corresponding record exists, add the relevant content to the newly added `routable_prefix` in the `Data` package according to the subscription list, and then return the `Data` package via the original path. 5.5 After the intermediate node responds to the Hello packet with a Data packet, it compares the content with the appearance in the MT table. If a corresponding entry exists and the source interface is not in the interface list of the Outgoing interface, the interface number is added to the Outgoing interface and the Data packet is forwarded. If there is no corresponding record in the MT, the Data packet is forwarded in the normal routing mode. (6) Key node role election: 6.1 Subscribing nodes construct Hello packets according to their own needs and send them to the network; 6.2 After receiving the Hello packet, the publisher node constructs a Data packet for response and forwards it from the receiving interface; 6.3 The intermediate routing node between the subscriber and publisher nodes records the received Hello packets and Data packets used for response based on the received packets, and maintains the KeyNode value of the intermediate node; 6.4 Based on the number of responses to the received Hello packets and the degree of the intermediate node, intermediate nodes with two or more branches and a KeyNode greater than 2 are designated as key nodes. (7) Maintenance of the multicast subscription tree structure: 7.1 If the intermediate node receives an Interest packet of type Hello, the intermediate node will add the subscription type name and receiving interface number to its own MT table entry; if the received Interest packet is of type sync, the intermediate node will add the subscription type name and forwarding interface number to the MT table. 7.2 After receiving the Hello packet, the publisher node matches the subscribed content in the Hello packet with the subscription list maintained by the publisher node. If the subscribed content in the Hello packet matches the subscription list, the publisher node constructs a Data packet to respond to the Hello packet based on the matching entry, adds its own relevant content to the routable_prefix entry in the Data packet, and forwards it to the network. 7.3 After the intermediate node responds to the Hello packet with a Data packet, it compares the content with the appearance in the MT table. If a corresponding entry exists and the source interface is not in the interface list of the Outgoing interface, the interface number is added to the Outgoing interface and the Data packet is forwarded. If there is no corresponding record in the MT, the Data packet is forwarded in the normal routing mode.

2. The method for obtaining low-latency content under the publish-subscribe model according to claim 1, characterized in that: Step one, as described above In the Interest package, the Content Name field is the content name, the Selector field is the selector structure, and the Nonce field generates a random number. In this section, the Interest package used to build the publish-subscribe relationship is called the Hello package, and the Interest package used to synchronize published information is called the sync package. The Hello package and the sync package are distinguished from ordinary Interest packages by the Content Name. The routine prefix field is used to record the field name subscribed to by the subscriber. In the Data packet, Content Name is the content name, Content is the content corresponding to the Interest received, Signature is the content signature, and the routine_preix field is a newly added structure containing subscription information; The MT table contains the following: Subscribe name (the node's forwarding interface number for the Hello packet); Incoming interface (the node's receiving interface number); Outgoing interface (the node's forwarding interface number); and Time stamp (creating a time node for the interface to maintain the timeliness of the corresponding entry).

Images