JP2005532748A - Caching including packet inspection for payload inspection, alert service, digital content delivery, and quality of service management, and selective multicasting in publish-subscribe networks - Google Patents

Abstract

At the router (12) in the core of the distributed network (10), for example, digital content such as video, music, software, etc. is delivered and payload inspection is used to provide alert service based on quality of service guarantee Provides packet routing. A packet includes a subject and attributes in addition to routing information. A subject corresponds to a subscription for a particular type of content, and an attribute encapsulates data or content. A subscription may be associated with a specific quality of service guarantee or level of service. The router (12) stores a filter corresponding to the content subscription. When the router (12) receives the packet, it examines the payload section of the packet including the attributes and applies a filter for subscriptions to the content from the camera to these attributes. If the attribute satisfies the filter, the packet is routed to the next link. If the attribute does not satisfy the filter, the router deletes the packet. These route decisions are distributed between the routers (12) in the network core (10). The router (12) caches data locally in the network core (12).

Description

Related applications

  The present invention is a US Provisional Application No. 60 / 394,631, filed July 8, 2002, incorporated herein by reference, entitled “Packets via Payload Inspection for Quality of Service Control”. Claims priority over “Routing” (Packet Routing Via Payload Inspection for Quality of Service Management). This application is also filed on Jul. 19, 2002, which is incorporated herein by reference, US patent application Ser. No. 10 / 199,356, entitled “Packet Routing Via Payload Inspection”. Payload Inspection ”, US patent application Ser. No. 10 / 199,368, title of invention“ Method And Apparatus For Content-Based Routing And Filtering At ” Routers Using Channels ”, US Patent Application No. 10 / 199,439, title of invention“ Method for Sending And Receiving A Boolean Function Over A Network ”, US Patent Application No. 10 / 199,369, title of invention “evaluation, modification, reuse and distribution via network” Method for Storing Boolean Functions To Enable Evaluation, Modification, Reuse, And Delivery Over A Network ”, US Patent Application No. 10 / 199,388, entitled“ Connection-Based This is a continuation-in-part of “Efficient Implementation of Wildcard Matching On Variable-Sized Fields In Connect-Based Routing” in routing.

  In addition, US Patent Application No. 10 / 400,671, filed on March 28, 2003, which is a continuation-in-part of the above-mentioned application, is entitled “Highly reliable issuance in networks with low reliability”. Reliable Publish / Subscribe System Architecture over Unreliable Networks, US Patent Application No. 10 / 400,465, Title of Invention “Content-based packet routing using compact filters and offline precomputation” Method and Apparatus for Content-Based Packet Routing Using Compact Filter Storage and Off-Line Pre-computation ”, US Patent Application No. 10 / 400,453, entitled“ Issuance-Subscription Network, Method and Appara for realizing query response interaction (Method and Appara tus for Implementing Query-Response Interactions in a Publish-Subscribe Network), US Patent Application No. 10 / 400,462, Title of Invention “Method and Apparatus for Realizing Sustainable and Reliable Message Delivery (Method and Apparatus) for Implementing Persistent and Reliable Message DELIVERY ", US Patent Application No. 10 / 400,444, Title of Invention" Method and Apparatus for Propagating Content Filters for Issue-Subscription Network " a Publish-Subscribe Network) is also incorporated herein by reference.

  The present invention relates to a method and apparatus for routing a packet based on an inspection of a payload in the packet for providing an alert service in a network core.

  Network bandwidth is growing exponentially. However, the network infrastructure (including routers, servers, daemons, protocols, etc.) still uses relatively old technology. As a result, Internet applications and network routers cannot cope with the speed of bandwidth expansion. At the same time, devices and applications corresponding to the network are increasing. The load on the network node due to these devices and applications is significantly increased. Also, due to the increase in network load and applications, the complexity for realizing and maintaining network applications is increasing. Increased network bandwidth and the ubiquitous use of network equipment and applications has led to issues related to routing and transmission of data in older network infrastructures, especially publishing content to subscribers. Has occurred.

  The model of pushing information from a server to a client in a network is called a publish-subscribe style. In this model, the server acts as a simplified publisher of that information regardless of which clients are interested in the information or where the client is located in the network. The client becomes a subscriber of information and potentially delivers that information as it becomes available, regardless of the details of where the information was made available on the network. The network is responsible for efficiently routing published information to subscribers, collating information for active subscriptions, and performing these processes in a transparent manner for publishers and subscribers.

  In the publish-subscribe model, the server configuration is greatly simplified, so there is no distinction between a heavyweight server and a lightweight client, which can be issued to issuers, subscribers, or both. Can be integrated into the designation of peers. Various types of applications have characteristics close to publish-subscribe interaction between peers. In the issues that exist at the base of many of these applications, the published and subscribed information is provided in the form of events. For example, the stock price fluctuates as an investor purchases or sells stock. In addition, when a traffic accident occurs on a highway, a traffic jam occurs. When security holes in software systems are discovered, patches need to be developed for software users. When an internet game player uses a weapon, the other player's avatar dies. These exemplary phenomena are all events that are potentially of interest to a large number of subscribers and are propagated in the network to inform these subscribers that such events have occurred. ). That is, an event is a self-contained and succinct piece of information about something of potential interest that occurred at some point on the network at some point in time. .

  In the publish-subscribe model, a routing decision is usually made by the server or issuer to instruct the network where to send the published content. The issuer stores a subscription related to the content that the issuer issues. When the issuer receives or generates new content, the issuer compares the content with each subscription and checks for any matches. If the content (event) satisfies any subscription reservation, the publisher pushes the content to the corresponding subscriber over the network. In this conventional publish-subscribe model, especially when more devices support the network and the number of subscriptions increases, the issuer is heavily burdened.

  As the concentration of countless applications on the Internet increases, the possibilities for using event notifications are infinite. Now, because of these possibilities, it is necessary to implement a method to reduce the issuer's burden by efficiently determining the route and efficiently determining when the event satisfies the subscription. It is. Thus, the realization of a universal and persistent event notification service adds significant value to Internet applications and other applications and implementations.

  The present invention overcomes the drawbacks of the prior art described above and provides a method and apparatus for routing packets to provide alert services in a network. The method and apparatus according to the present invention can significantly reduce the network burden for processing and routing of video clips, for example. Furthermore, the present invention can reduce bandwidth requirements for routing video clips. Further, according to the present invention, local traffic can be reduced with respect to the local area network of the digital video recorder.

  To realize these advantages, one embodiment of the present invention receives a packet having a header section and a payload section that contains information related to a video clip from a particular camera. At the network core, the packet payload section is examined to determine how to route packets containing information from a particular camera to the subscriber, and packets are selectively routed based on the examination. The above and other advantages can also be realized by an apparatus comprising a module for performing these steps.

  In order to achieve these and other advantages, the present invention also provides a routing method for routing packets to provide alert services in a network. The routing method includes a receiving step for receiving a message including a header section, at least one subject, and at least one attribute associated with a video clip from a particular camera, and subject / attribute reading for reading the subject and attribute from the message. A subscription subscription reading step for retrieving a subscription subscription based on the subject, and an application step for applying attributes to the subscription subscription and determining how to route the message to the subscriber at the network core. The above and other advantages can also be realized by an apparatus comprising a module for performing these steps.

  In order to achieve these and other advantages, the present invention also provides a routing method for routing packets to provide alert services in a network. The routing method receives a packet having a header section and a payload section containing information about a particular alert service event, and how the network core routes a packet containing the alert service information to a subscriber. An inspection step that examines the payload section of the packet to determine whether to do so, and a routing step that selectively routes the packet based on the inspection. The above and other advantages can also be realized by an apparatus comprising a module for performing these steps.

Overview Internet-wide or other distributed network-wide event notification systems provide powerful and flexible publish-subscribe networking in applications. In this system, an application program uses an event notification application program interface (hereinafter referred to as API) to issue and / or subscribe to or receive notifications regarding events occurring within the network.

  Notifications in this system are given a subject, which is represented as a string or other data structure for classifying the type of information that the notification encapsulates. The notification is completed by a set of attributes including information specific to the notification. For example, the application is subject quote. You may issue the notification regarding the transaction in the New York Stock Exchange using nyse (subject quotes.nyse), an attribute symbol, and a price. For example, the application issues individual notifications with specific attribute values including SNE (Sony Corporation quote receiver symbol) and $ 85.25 stock price. Most, if not all, notification attributes are predetermined in the sense that they are found in all notifications for the same subject family. The issuer can add any attribute to the notification for each notification or in other units to add event specific information. Accordingly, some or all of the attributes may not be predefined.

  In this system, subscribers are not limited to subscribing to subjects or entire channels. Channels will be explained and defined later. A channel can include, for example, a hierarchical structure that specifies one or more levels of subject fields and associated sub-fields (sub-subjects). Therefore, the subscriber can specify the expression adjusted more precisely according to the interest by specifying the filter for each content with respect to the attribute of the notification. For example, a subscriber has a subject quote .. with a SNE symbol and a price of $ 90.00 or more. All notifications may be subscribed to nyse (eg, indicating an opportunity to sell shares owned by the subscriber). All notifications that match the subscription are delivered to the subscriber when the callback or the subscriber registers the subscription, or through other types of features identified at other times. A single subscription can be divided into multiple filters.

  Callbacks can perform a lot of processing, for example, from simple processing such as sending a message or sending an email to a terminal device, rather than selling a portion of a stock, etc. Start complex publishing and new publish-subscribe activities (for example, replace existing subscriptions with new subscriptions with a $ 75.00 share opportunity, or modify the subscriber portfolio) A more complicated process such as issuing a new notification).

  Publishing and subscription activities in the application may be supported by an agent, for example. The agent may use a proxy or may be implemented as a proxy. The agent provides a connection for delivery of sent notifications and subscriptions, and matching notifications received by subscribers. When a notification is sent to the network, the network of routers in this system propagates the notification to all subscribers whose subscriptions match the notification. One method for realizing this processing is a method in which notifications of all points in the network are broadcast and an application agent determines whether or not the notification is related to a corresponding subscriber. However, this is not necessarily a scalable technique. Typically, the network cannot function normally due to message traffic load, especially if there are a large number of active subscribers. Furthermore, even if the bandwidth is sufficiently secured, it is considered that the subscriber cannot process a huge amount of notifications.

  The network shown as an example of a system according to the present invention routes notifications very efficiently. First, the network can use multicast routing to propagate notifications, for example, at most once on all links in the network. The network can then employ a number of advanced optimization processes for filters, thereby reducing the number of notification propagations as much as possible.

  FIG. 1 is a diagram conceptually showing this intelligent routing in the network core. The issuer 14 transmits the content of the message via the edge router 16 to the network core 10 used in the issue-subscribe network. The publish-subscribe network may be any type of network for routing data or content from the publisher to the subscriber. Content is transmitted over one or more channels 18 that represent logical connections between routers or other devices. The intelligent router 12 in the network core 10 determines whether to route or forward the message. Specifically, the intelligent router 12 can determine whether the message includes content that is subscribed to by the subscriber 24.

  Each subscription reservation encapsulates a subject filter and an attribute filter. The router can extend the subject filter to a matching set of subjects, or merge attribute filters for each subject. The intelligent router evaluates the subject filter for the notification subject and the attribute filter for the attribute value in the notification. In the syntax for the subject filter, wildcards can be used, and in the syntax for the attribute filter, Boolean expressions can be used, which will be described in more detail later. The term “filter” means a set of events that a subscriber wants to receive from an publisher. The routing rule is generated from the filter, and the intelligent router performs route determination using this rule.

  Thus, if the message 26 does not satisfy the entire filter set, for example, the intelligent router 12 excludes (deletes) the message 26, which means that the message is not forwarded. If it is determined, based on the subject and attribute filter evaluation, that the message 20 satisfies a part or all of the filter set, for example, the intelligent router 12 passes through the edge router 22 and possibly other devices. To route (forward) the message 20 to the subscriber or perform other functions on the message 20 within the intelligent router 12 based on all routing and / or operating rules defined for the matched filter. . The search continues until the processing on the entire set of filters is complete or until a decision on all rules is obtained, and ends when either of these two conditions is met.

  Such intelligent content-based routing at the network core provides real-time data delivery for alerts and updates, for example. Specific examples of real-time data distribution for warning are not limited to the following, but include, for example, stock prices, traffic information, news, travel, weather, fraud detection, security, telematics, factory automation, and supply. There are chain management and network management. Specific examples of real-time data delivery for updates include, but are not limited to, software updates, antivirus updates, movie and music delivery, workflow, storage management and cache consistency. Etc. The system for distributing subscribed information can be applied to various other fields.

  Table 1 shows the subscription reservations saved for filtering, along with the subject and predicate. These may be stored in any part of the network using any kind of data structure if desired or required. As will be described later, the predicate is an element of a subscription reservation. The subscription reservation may be expressed in any format, and a specific example is shown below.

  Table 2 shows specific examples of issuance and subscription reservations for a quote server. These are merely illustrative examples for purposes of illustration, and subscriptions may include any number and type of parameters for any type of data or content.

  The predicate provides a logical expression for subscription reservation, and the subject indicates a channel related to subscription reservation. Subscription reservations can be expressed in various other ways. A logical expression is an example of such a technique, and by using this, a function for converting a subscription reservation into a subject filter and an attribute filter can be easily realized for content-based routing. Alternatively, a subscription can be expressed without referring to the subject, but by using the subject or channel (discussed in detail later), the attribute can be interpreted and the filter applied to the attribute. Context is realized.

  In the network core, route determination can be performed and distributed via the network, thereby reducing the processing burden on the issuer and subscriber devices and significantly increasing network efficiency. In FIG. 1, only a single issuer, a single subscriber, and a single intelligent router are shown for the purpose of explanation. Also good. The term intelligent router refers to a router or other entity that has the ability to determine a route by examining the payload of a packet or message at the network core or other location.

Network Infrastructure FIG. 2 is a network diagram showing an intelligent router for issuers and subscribers. For example, a routing entity 30 that provides services to a channel is effectively layered within the network infrastructure to route messages between intelligent routers, as described below. For example, publisher 32 conceptually encodes content for network transmission via channel service 30 and application 34 for receiving published content indication information, eg, a pointer to search for content. And an agent 36 for A group of logically interconnected intelligent routers 38, 40, 42, 44, 46, 48 uses the routing rules generated from the subject filters and attribute filters for subscription reservations to route content from the publisher. Route. The plurality of links 39, 41, 43, 45 logically connect the intelligent routers 38, 40, 42, 44, 46, 48. The other links 37 and 47 logically connect between the issuer 32 and the intelligent router 38 and between the subscriber 54 and the intelligent router 46, respectively. The subscriber 54 includes an agent 50 for detecting and receiving the subscribed content and an application 52 for expressing the content.

  A channel can include, for example, an associated set of logical multicast connections implemented in a distributed manner. A channel in this illustrative embodiment is a collection of logically related network resources that are shared by publishers and subscribers to exchange content. The content is classified according to the channel subject namespace, and the resources are managed, controlled, and supplied through a channel service provided by the channel manager. Multiple channels may share the same resource. Channels can provide highly scalable directory services, including but not limited to publisher and subscriber information, authentication and authorization information message types, management information, billing and payment information, etc. Is included. Also, for example, a channel can provide persistent through caching, fast data delivery mechanisms, security, user and network management, etc. that can be provided. Channels can also be used for any other purpose.

  Filtering by an intelligent router may be performed at the network core, and route determination may be distributed within the network. Furthermore, the intelligent router can function as an edge router that connects user equipment such as an issuer or a subscriber to the network core. Also, the same device connected to the network can function as both an issuer that pushes content to subscribers and a subscriber that receives pushed content based on routing decisions in the network. The intelligent routers and channels may be connected in any configuration as needed or desired in a particular embodiment, and the configuration of FIG. 2 is merely shown as an example.

  FIG. 3 shows an exemplary network infrastructure configuration for intelligent routers and conventional backbone routers, which also shows channel logical connections. The intelligent router in this embodiment uses an existing backbone router in a network such as the Internet or another distributed network, and the intelligent router is effectively layered on the backbone router. In this embodiment, Internet Service Provider (ISP) networks 58, 59, 60 each include several backbone routers for conventional routing of messages or packets. . In the ISP networks 58, 59 and 60, a plurality of intelligent routers 61 to 70 are connected to one or more backbone routers. The intelligent routers 61 to 70 are interconnected by a plurality of links 73 to 85 exemplarily showing actual links, and can also be connected to an end user device through these links. The intelligent routers 61 to 70 are controlled by one or more administrator machines such as an entity 71 and one or more virtual private network (hereinafter referred to as VPN) controllers such as an entity 72, for example. Is done. The ISP networks 58, 59, 60 may be connected to issuer devices and subscriber devices (not shown in FIG. 3). The backbone routers within and between ISPs 58, 59, 60 may be interconnected in any conventional manner within the existing network infrastructure.

  As shown in FIG. 3, the existing network infrastructure can be used to implement intelligent routers 61-70 and links 73-85, which provide content-based routing in the network core. Links 73-85 represent logical connections between intelligent routers 61-70 and can be implemented using, for example, existing network infrastructure or other equipment. The link may be realized by using a logical connection called a tunnel, for example. The tunnel includes hardware, possibly software, and network infrastructure to implement the link, and the tunnel may be an element of multiple channels. Channels facilitate content-based routing in intelligent routers by providing a logical configuration for specific types of content, thereby providing context for attributes sent over the channel . Intelligent routers can also make routing decisions without using channels, but channels improve the efficiency of content-based routing by intelligent routers in the network core.

  This exemplary embodiment includes the use of channels and links. A link represents a connection between two routers, for example intelligent routers. A channel is a network entity that includes a group (usually multiple) of routers that are statically or dynamically configured by interconnecting links to implement a one-to-many or many-to-many logical connection. In particular, a channel is the highest level logical entity that describes the essential characteristics of a channel. Many subjects may exist in one channel. Each subject forms a subnetwork (such as a multicast tree) that includes a group of interconnected routers. These subject-based sub-networks can be allocated, adapted and configured in various ways. The channels that are a collection of all the sub-networks and under which the subject is formed can be, for example, a mesh of networks.

  FIG. 4 shows a specific configuration example of the intelligent router 92, and the intelligent router 92 may correspond to any other intelligent router having a reference numeral. The network node 90 includes an intelligent router 92 connected to a conventional backbone router 95. The intelligent router 92 includes a processor 93 connected to a memory 94 and an auxiliary storage device 97 (for example, may be realized as an independent device). Both the memory 94 and the auxiliary storage device 97 are cache data. And the application program executed by the processor 93 is saved. The auxiliary storage device 97 is a nonvolatile data storage device. As will be described later, the processor 93 is controlled by software and issues a command to the backbone router 95. In response to this command, the backbone router 95 generates a routing rule generated from the subject filter and the attribute filter for the subscription reservation. The message or packet is routed (forwarded) or not routed (deleted). Here, although the intelligent router 92 is shown as an independent device controlled by the processor, the intelligent router 92 is realized as an application specific integrated circuit (ASIC) in the backbone router 95, and the hardware is realized. , An intelligent routing function may be provided, and software may be incorporated in this hardware. Alternatively, the intelligent routing function may be realized as a combination of software and hardware in one or a plurality of routing devices.

  FIG. 5 shows a specific configuration example of the issuer device and the subscriber device. The issuer device 100 or 118 is, for example, a memory 102 that stores one or more issuer applications 104 and an agent application 105, an auxiliary storage device 112 that is a non-volatile storage device, and information or commands for inputting information or commands. An input device 108 for processing, a processor 114 for executing an application stored in the memory 102 or received from another storage device, an output device 110 for outputting information, and a visual display of the information And a display device 116.

  The subscriber device 122 or the subscriber device 140, for example, inputs information or commands to a memory 124 that stores one or more applications 126 and an agent application 128, an auxiliary storage device 130 that is a non-volatile storage device, and so on. An input device 132, a processor 134 for executing an application stored in the memory 124 or received from another storage device, an output device 136 for outputting information, and a visual display of the information The display device 138 is provided. The issuer device and the subscriber device may have any configuration, may include components different from those described above, and may include more or less components than those described above.

  The issuer devices 100, 118 are connected to the subscriber devices 122, 140 via a network, such as the network 120 described above. The network 120 is a distributed routing of data or content via packets or messages at the network core. Including an intelligent router to realize. Although only two issuer devices and subscriber devices are shown here, the network 120 can be scaled to include more issuer devices and subscriber devices. The issuer device and the subscriber device may be realized as any device controlled by a processor, and these devices include, but are not limited to, for example, a server, a personal computer, a notebook computer, A personal digital assistant, telephone, mobile phone, pager, or other device is included. The network 120 including the intelligent router may be any wired or wireless distributed network that connects wired devices, wireless devices, or both. The network 120 can also be a potentially existing or conventional network infrastructure.

  FIG. 6 shows the configuration of the channel manager 150 for the intelligent router. In this embodiment, the channel manager 150 is realized by a plurality of servers 152, 154 and 156. Each server includes local storage devices 158, 160, and 162, respectively. The intelligent routers 164, 166, 168 obtain information about a specific channel from the channel manager. The channel manager can also provide data persistence, fail over functions, and other functions. This allows the channel management program to be a database or set of databases that identifies, for example, channel related information, properties for data persistence, user information for publishers and subscribers, infrastructure information, etc. at any location in the network. The infrastructure information for providing the channel service including, for example, can include identification information of intelligent routers and tunnels connecting them, channel subjects, channel attributes (name and type of each attribute), and the like. Also, the packet or message can carry channel related information including identification information of fixed attributes and variable attributes.

  The user can download the channel information while online. For example, a user can register himself using a user name and password. Once the user's logon is authenticated, the user can open (call) the channel and retrieve information about the channel from the channel manager. Publishers can use this information when publishing content, and subscribers can use this information when entering and registering subscriptions.

  The channel managers 152, 154, 156 preferably constitute a group for performing a persistent and reliable channel directory service. One of the channel managers is a primary manager, and the other channel manager is a backup channel manager. When a failure occurs in the primary channel manager, the channel manager adjacent to the primary channel manager assumes the function of a new primary channel manager, thereby maintaining the reliability of the service. Each intelligent router maintains the address of these channel managers. If there are channel managers that the intelligent router cannot access, the intelligent router searches other channel managers for information. The network device can use a command for obtaining channel information as shown in Table 3, for example. Alternatively, the intelligent router may have only a primary channel manager or may have two or more channel managers.

  FIG. 7 illustrates a specific example of a stack 180 of software components in a user device or device for connecting to a network having an intelligent router. The user device can be used as an issuer, a subscriber, or both, and the user device can include various devices illustrated above as specific examples. Stack 180 can include one or more user applications 182 that are used to receive subscriptions from users, receive channel information from publishers, or receive content or data to be published. Can do. Also, the user application 182 may include any other type of application that is executed by a user device or device.

  The stack 180 may include an agent 184, an event library 186, a cache library 188, a channel library 190, a messaging library 192, and a dispatcher library 194. Agent 184 provides network connection establishment or other functions, and Table 3 shows specific examples of commands implemented by agent 184 that may be used as proxy commands or other types of commands. Can do. The event library 186 records a log of events relating to user equipment or other events or information. The cache library 188 provides a local data caching function. The channel library 190 stores channel identification information and information related to the channel. The dispatcher library 194 provides a connection to the control path 196, the channel manager 198, one or more intelligent routers 200, and can include the functions illustrated in Table 4. Messaging library 192 provides a connection to data path 204.

  Specific examples of the messaging API written in the C programming language are shown in Tables 5 to 9. Tables 5 and 6 show specific examples of APIs for message transmission and retrieval. Tables 7 and 8 show specific examples of APIs for sending and retrieving notifications. Table 9 shows specific examples of APIs for transmitting and retrieving control messages. The APIs and other APIs, programs, and data structures that implement the particular functions or features shown here are merely exemplary, and these functions can be used for any kind of APIs written in any programming language or You may implement | achieve as another software entity.

  FIG. 8 illustrates an exemplary software component 210 for an intelligent router, such as the intelligent router described above and the intelligent router 92 shown in FIG. The software component 210 is stored in, for example, the memory 94 and can be executed by the processor 93 of the intelligent router 92. The component 210 includes, for example, a filtering daemon 212, a dispatcher 214, a routing daemon 216, and a cache manager 218. The filtering daemon 212 provides a filtering function based on routing rules in content-based routing for processing content for subscription reservation, as will be described later. The dispatcher 214 is responsible for communicating control messages that are needed to propagate the filter through the path 220, and the dispatcher 214 has a single point of entry and channel manager for the user. Provide secure sockets and improve network security. In other words, in this example, the user does not communicate directly with the channel manager. However, as a modification, the user may communicate directly with the channel manager. The dispatcher 214 obtains attributes (name-value pairs) from the channel manager using control messages.

  The routing daemon 216 provides a communication function via a data path 222 performed via a conventional backbone router or other routing device as shown in FIG. The cache manager 218 provides local caching of data at the network node that includes the corresponding intelligent router. The operation of the cache manager 218 will be described in detail later. The cache manager 218 provides a distributed caching function of data via the network core.

  Content-based routing may be implemented at the kernel level rather than the application level. The memory accessible by the kernel is independent of the memory in the application layer. In order to perform content-based routing in an application, for example, it is necessary to copy message data from the kernel storage area to the application area and switch the application context from the kernel context to the routing application context. Both of these processes cause considerable overhead. Here, if the kernel is changed to support content-based routing, the overhead described above is removed, and routing can be performed at higher speed.

  Such a content-based routing function in the kernel allows the routing daemon 216 to send or receive data directly or indirectly via the data path 222, depending on the specific example. The daemon is a process that is executed in the application layer and calculates in advance a content-based routing table to be inserted into the kernel. However, the kernel can determine a route using the routing table after the routing table is inserted. Similarly, the filtering daemon calculates a filtering table in advance and inserts the calculated filtering table into the kernel. In the kernel in this example, neither the routing daemon nor the filtering daemon interacts directly with the data path.

  FIG. 9 shows an example of a packet structure 230 for a message that can include subscription content. A packet or message used for content-based routing includes, for example, a header section and a payload section. The header section specifies routing or other information. The payload section identifies data or content or indicates data or content. The packet structure 230 includes an IP header 232, a user datagram protocol (hereinafter referred to as UDP) transmission control protocol (hereinafter referred to as TCP) header 234, a length value 238, one or more subjects. It includes a field 240 and one or more attributes 242. The packet structure 230 shows the basic structure for length values, subjects and attributes. Further, the packet used in the content-based routing can include other or different elements as shown in the embodiment of FIG. 18 to be described later. It may be configured. The attribute can include, for example, an arbitrary attribute added to the end of the message. These arbitrary attributes are temporary information added by, for example, the issuer (or router), and are information that does not necessarily need to be transmitted using the message format defined for the channel.

Publisher and Subscriber Methodologies
FIG. 10 is a flowchart of an exemplary publishing process 250 for setting up channels and publishing content by publishers. The process 250 can be realized by a software module including the agent 106 executed by the processor 114 in the issuer apparatus 100, for example. In process 250, the issuer device agent 106 receives a proxy for the channel created by the issuer (step 252). The proxy is used for communication with the network. Agent 106 determines the message format to use on the channel via the interface (step 253). Format information can be obtained, for example, from a channel manager or other entity in the network. The agent 106 sets up a proxy for the channel using the received channel information (step 254), which includes receiving a channel attribute (step 256) and creating a notification for the channel (step 258). Including. This notification provides content to devices that are “listening” for content on the channel. Attributes define notification parameters and characteristics.

  The agent 106 sends the channel and content information identifier (ID) to the intelligent router to process the subscription at the network core or elsewhere (step 260). The issuer sets an appropriate value for the notification attribute (step 261), so that the issuer can issue content related to the notification based on the channel attribute (step 262). In step 260 to 262 in this embodiment, the notification issuance is completed. This process may include other or further steps depending on the actual individual embodiment. Here, the information related to the notification in this embodiment is divided into a series of attributes based on a predetermined order. Each attribute has a name, a position (starting from 1) in the notification, a type, and a value. Have. Alternatively, the attributes may have different characteristics depending on the particular embodiment. For example, the attributes can include predetermined attributes, optional attributes, or both.

  The intelligent router can know the attribute of the corresponding channel based on the channel ID in the packet, and this attribute determines the structure or format of the packet transmitted through the channel. Specifically, each packet can include, for example, a tag associated with other header information such as a channel ID, issuer ID, and subject. This tag can be used to map a subject to a message format number, for example, as shown in FIG. This number can be a small integer value, for example a 16 bit value. Alternatively, the subject may be mapped using any other type of number or information. By mapping subjects to numbers, for example, the following advantages can be obtained. That is, this can save space in the message format and provide a uniform or standardized way to specify subjects in the message, which allows for quick identification and identification of subjects. The intelligent router may store the mapping locally, or alternatively may obtain the corresponding subject remotely by command using a number.

  Table 10 shows a structure for mapping subjects to numbers. In this specific example, integer values are used for the numbers. The subject tree parameter in Table 10 indicates that a subject can include one or more subject fields in a hierarchical relationship, for example, a subject tree can include a series of subject fields that are partitioned by a particular symbol. . Specific examples of the subject tree are shown in Table 2. For example, subject tree quotes. The nyse includes a subject “quote” and a subfield “nyse”, and these two terms are separated by a “.” (period), like a URL or other network address. Instead of using a period and URL type character string, the subject tree may be specified by any method using any character and a symbol for delimiter.

  Knowing the packet format or structure of a particular channel allows the intelligent router to quickly locate the subject and attributes in the packet or other information for content-based routing. For example, a channel can easily identify the byte positions of subjects and attributes transmitted over the channel by counting bytes in the packet. Alternatively, the intelligent router can analyze the packet to detect the location of subjects and attributes or other information.

  Table 11 shows a specific example of an issuer program written in the C ++ programming language. Table 12 shows a specific example of an API for creating a channel. Table 13 shows a specific example of the channel setting file maintained by the channel manager (see FIG. 6) and channel related information. Alternatively, the system may include a comprehensive channel manager that provides the IP addresses of geographically distributed servers that act as local channel managers to distribute the processing load.

  FIG. 11 is a flowchart of a subscription process 264 for receiving and processing subscription reservations. The process 264 can be implemented, for example, by a software module that includes an agent 128 that is executed by the processor 134 in the subscriber device 122. In the process 264, for example, a graphical user interface (hereinafter referred to as GUI) displays information indicating available channels to the user (step 266). This process is realized by the application 126. Information identifying a channel can be received, for example, from a channel manager that provides channel-related information. Any type of application 126 may be used to display information indicating the channel based on any particular technique or format. The application receives the channel selected by the user (step 268) and calls an API or other program for the selected channel (step 270). The API displays the channel subscription options for the selected option to the user (step 272). The API receives a value for the subscription from the user (step 274) and provides the subscription to the agent 128 for processing described below (step 276).

  The parameters for subscription reservation may include predicates as shown in Table 1, for example. Each channel can use its own API to process subscriptions according to specific requirements or parameters for the corresponding channel, for example. These APIs may include, for example, web-based or Java-based APIs for receiving subscriptions, receive information about subscriptions using any type of user interface and processing, and use this information for agent applications. You may forward to.

  FIG. 12 conceptually illustrates channel and subscriber screens or GUIs 278, 284, which are used in connection with process 264 for receiving a subscription. Screen 278 includes a plurality of sections 282 showing available channels selected by the user. When a particular channel is selected, a section 286 for receiving user values for subscription is displayed, as shown on screen 284. If the user selects section 288, the subscription is confirmed, or if the user selects section 290, the subscription is canceled. For example, the screens 278, 284 may be formatted as a hypertext markup language (HTML) web page, or any other format may be used. The screen may also contain any configuration of sections and content, including text, graphics, pictures, various colors or multimedia information, if necessary, for subscribers, if necessary. Provide a user-friendly and visually attractive interface. Further, the screen may include, for example, a toolbar 280 that provides a browser function similar to the conventional one.

  Table 14 shows a specific example of a subscriber program written in the C ++ programming language.

Payload Inspection and Content-Based Routing Through Channels FIG. 13 is a flowchart of a payload inspection process 300 for content-based routing. Process 300 is implemented in a software module that is executed by processor 93 in intelligent router 92, for example, represented as filtering daemon 212. Alternatively, this processing may be realized by an ASIC, or may be realized by a combination of hardware and software. The content-based routing shown as process 300 can be performed in an intelligent router in any part of the network, such as a network core or edge router, for example.

  In general, content-based routing involves examining the payload section of a packet to determine how to process the packet. This content-based routing process, for example, processes a list of subscriptions in any order (eg, using a filter), compares messages by subject and attribute based on routing rules, and routes messages. And executing processing in the network core. This rule may include any rule relating to a rule or filter that governs processing at the router. As a result, these route determinations can be transmitted to the network core. By representing the subject as a channel, the message format is determined so that the intelligent router can quickly detect the position of the attribute in the message, for example, by knowing the byte position of the attribute in a message or packet on a particular channel. become able to.

  In process 300, intelligent router 92 receives a packet for a message (step 302). The intelligent router 92 determines the channel ID of the corresponding message from the packet (step 304), and reads the channel attribute using the channel ID (step 306). In this embodiment, the type of channel (determined from the channel ID) determines the attribute position and data type in the packet. Channel attributes may be stored locally, for example, remotely read via a channel manager. The intelligent router 92 searches for a filter corresponding to the subscription reservation (step 308). The filter includes one or more attribute checks, often a group of attribute checks for subscription reservations. Intelligent router 92 applies the corresponding attribute check in the filter description to the attribute in the packet (step 310).

  If the result of all attribute checks in the filter description is affirmative (step 312), that is, if the attribute meets all attribute check conditions, the intelligent router 92 is predetermined by the rules associated with the filter. A set of processes is executed (step 314). These processes include, for example, a process of routing a packet to the next link and / or a process of executing some operation or calculation on the content of the packet in the local router. This operation or next link is specified, for example, in a data structure that specifies the corresponding subscription. If the rule is a link, the rule typically specifies the next network node to receive the packet, which includes intelligent routers, backbone routers, devices connected to the network, or other entities . Alternatively, the next link may be identified or associated with a subscription reservation in other ways.

  If the results of all attribute checks in the filter description are not positive (step 312), that is, if the attributes do not satisfy all attribute check conditions, a filter mismatch is declared (step 315). The intelligent router repeats the above processing until all attribute checks in the filter description are completed or until the first negative result is obtained, and ends when either of these two conditions is satisfied.

  The intelligent router performs all attribute checks on this filter and then determines whether there are more filters (step 316). If there are more filters, the process returns to step 308; The attribute check for the next filter is read and the check for that filter is performed. The matching process (steps 308, 310, 312, 314, 315, 316) continues until the process on the entire set of filters is completed or until all rules are determined, and either of these two conditions is met. When satisfied, it ends. If the packet does not meet the filter criteria, the filter is excluded (deleted) and not forwarded.

  The intelligent router 92 may perform a series of processes using filters in any specific order. For example, as shown in Table 15, the intelligent router 92 can store filters for subscription reservations in a file or routing table, and can sequentially read these and apply filters to attributes (perform attribute checking). . Alternatively, the routing table may include a link or pointer to the filter.

  In content-based routing, two or more techniques may optionally be used simultaneously based on application and heuristics such as switching algorithms based on traffic conditions, for example. For use in examining payload sections for content-based routing, the filters used for processing may optionally be encrypted, decrypted, transformed, and merged at routers in the network. For example, if the issue information in the application does not include currency information that is less than two digits after the decimal point, the fraction of subscription information of> 3.54122 may be rounded to> 3.54 dollars. Alternatively, foreign currency may be converted into US currency when overseas issue information reaches the first router existing in the United States.

  Instead of a linear approach, the intelligent router 92 may select filters for processing in other orders that can improve the speed and efficiency of processing or based on various algorithms. Table 16 shows a specific example of the link corresponding to the subscription reservation. In these examples, the subject is associated with a particular channel, and the subscription for the subject can be represented by a routing rule for the filter. The subject can include a network address for identifying the source of the content, such as a uniform resource locator (URL).

  FIG. 14 is a flowchart of the caching process 320. The process 320 is implemented in a software module executed by the processor 93 in the intelligent router 92, for example, represented as a cache manager 218. Alternatively, this processing may be realized by an ASIC, or may be realized by a combination of hardware and software. These may be the same physical device as the corresponding intelligent router or a different physical device. In process 320, intelligent router 92 receives a message containing data or content, a channel ID, and a subject (step 322). The intelligent router 92 adds a mark indicating the time to the data (step 324) and caches the data in a local memory such as the memory 94 or the auxiliary storage device 97 (step 326). The intelligent router 92 indexes the cached data using the channel ID, subject, and time stamp (step 328).

  When the intelligent router 92 receives a request for data (step 330), the intelligent router 92 retrieves the cached data using the index based on the request (step 332). Intelligent router 92 forwards the cached data to backbone router 95 or other routing entity, which is ultimately transmitted to the requester or other entity. The process 320 may be repeated so that data is continuously cached and the cached data can be retrieved on demand.

  FIG. 15 shows a specific example of the cache index (336) used in the process 320. The cache index (336) receives the data (338) and stores it along with the time stamp (340). When collecting data, each data is marked for each period of Δt. Here, Δt represents a time between marks, for example, a period between t2 and t1. Any other kind of index may be used for the mark representing the time.

  Table 17 conceptually shows the indexes used for the cached data. Table 18 conceptually shows data for storing a connection history for caching. Table 19 shows a specific example of a data structure used for locally cached data in a network node having an intelligent router.

  The mark indicating the time may be given at any fixed interval, or at a variable time interval. For example, data may be cached every 5 minutes and indexed. When the channel manager 218 receives a command to read cached data specifying a time and subject (eg, # .getCache), it can read the cached data corresponding to the request in step 332 using a cache index. Determine if you can.

  Each subject or channel can include, for example, its own IP address in the multicast tree and a set of intelligent routers. Table 18 shows the connection history between such routers that can be stored locally on the user equipment. If an edge router fails, the device accesses the connection history to see how the edge router can reconnect to the upstream router of the channel when it comes back online. In addition, the device can execute a command (get cache command) for acquiring cache data during a period in which the device is not connected to obtain pending content related to the subscription.

  These exemplary data structures include the following information: A subject node includes a subject identifier, a subject level, a pointer to a parent channel or subject node, a file descriptor for its own directory, a pointer to a hash table containing the next level subject node, and a data node And a pointer to The data node has a pointer to the subject parent node, a file descriptor for the data directory, a circular buffer containing data structures for data stored in each storage device, a head and tail of the buffer, And a lock to lock the data node during reading and storage. A saved time grain node is a node that represents the actual data file, and the last grain node represents a buffer that is not yet saved in the storage device but is held in memory. The caching and data storage thread in this embodiment uses the mutex of the last time grain node to prevent the last time grain node from being accessed simultaneously.

Processing at Agent FIG. 16 is a flowchart of agent processing 350 for a transmitted subscription message. The process 350 can be implemented, for example, by a software module that includes an agent 128 that is executed by the processor 134 in the user (subscriber) device 122. In the process 350, the agent 128 receives the subscription reservation generated by the process (step 352) described above with reference to FIGS. 11 and 12, for example. Agent 128 creates a string that identifies the logical expression for the subscription reservation (step 354) and parses the string to detect errors in the subscription reservation (step 356). If an error exists, agent 128 displays an error message to the user (step 360) and prompts the user to correct the error and re-enter the subscription. If the subscription does not contain any errors (step 358), agent 128 saves the representation in the data structure (step 362), as described below. The agent 128 converts the inequality operator included in the data structure into a positive form (step 364), and further converts the data structure into a corresponding disjunctive normal form (hereinafter referred to as DNF) ( Step 366). Agent 128 also simplifies the AND expression of the DNF structure so that only range filters and membership checks are included (step 368).

  DNF is a well-known standard form where a logical expression is represented as an OR (called disjunction) of one or more subexpressions, and each subexpression is represented by an AND of one or more attribute checks. For example, the equivalent DNF expression to the logical expression (price> = 10 AND (symbol = "LU" OR symbol = "T")) is ((price> = 10 AND symbol = "LU") OR (price> = 10 AND SYMBOL = "T")).

  The transformation in step 364 identifies all allowed values, replacing the expression with the “not equal” operator (represented as! = In the exemplary syntax) with one value that is not allowed. To the equivalent “positive” format. Since the router used in this example requires an expression in the positive form, this conversion is done before generating the DNF. For example, the expression (price! = 80) is converted to an equivalent positive expression (price <= 79 OR price> = 81).

  The transformation in step 368 is performed after the DNF is created and includes a process that further simplifies the AND expression generated here, thereby simplifying the processing of the router in this embodiment. Specifically, in particular, the AND of multiple attribute checks for the same attribute is a canonical “includes one lower limit, one upper limit, both lower and upper limits, and, in the case of equivalence checks, any single value. It can be simplified to “range filter”. A particular type of range filter is encoded based on, for example, Table 22.

  For example, the expression (price> = 10 AND price <= 80 AND price> = 20 AND price <= 100) can be reduced to the expression (price> = 20 AND price <= 80), which has both lower and upper limits. It is a specific example of a range filter having Other examples of values after reduction include (price> = 20) (lower limit only), (price <= 80) (upper limit only), (price = 50) (single value), and the like. In creating these range filters, any subexpression can be reduced to true or false, in which case the subexpression can be eliminated based on the laws of Boolean algebra, so that the encoding of the expression in the message is reduced. Further optimization. For example, the expression (price> = 50 AND price <= 20) can be simplified to false because there is no “price” value that satisfies the expression. In the special case where the entire filter representation is simplified to false, the agent does not need to create a message, thereby freeing the router from unnecessary work.

  If the subject filter contains wildcards, agent 128 can optionally convert them (step 370), as described below. Alternatively, any wildcard may be converted in the network rather than the user device or other device. In this illustrative example, the syntax for the subject filter is the only syntax that uses wildcards, and the syntax for the attribute filter is the only syntax that uses logical expressions. Alternatively, different or variable types of syntax may be used for the subject filter and the attribute filter.

  Agent 128 encodes the generated DNF representation into a message (step 372) and forwards the message to the intelligent router (step 374). This encoding includes the process of converting a subscription reservation into a flat message format, which means a format composed of a string of data. The forwarding process also includes the process of propagating the routing rules generated by the subject filter and attribute filter for the subscription reservation to one or more intelligent routers or other routing entities in the network. For this propagation, for example, a subscription representation can be mapped to a conventional packet structure.

  The encoding in step 372 includes converting the subscription corresponding to the channel to the messaging API messaging format for propagation through the channel. For example, the subscription reservation is subject #. Messaged internally as a notification including SUBSCRIPTION. Since there are both an arbitrary number of subject filter fields and an arbitrary number of attribute checks, in this embodiment, one set of bytes is used to store the number of subject filter fields, and another set of bytes is used to attribute. Save the number of examinations. The individual fields of the subject filter are rearranged in the order specified in the original subscription, for example, and stored in the 2-byte part of the message. The arrangement of the wild card field will be described later.

  In the attribute check array, the check operand is placed at the end of the message, similar to the placement of attribute values in the notification. Prior to placing attribute checks and operands, they are sorted in attribute order within each DNF choice by a positional order check for a given attribute followed by a name order check for any attribute. In addition, the set of relational checks for scalarally evaluated attributes within each choice can be a range filter with one limit (range open or right or left or equivalent test) or two limits (separate The closed range between the limits) is simplified to the standard form. The remaining information about the check is encoded in the same order as the operands, for example, into two byte pairs. This sequence of two byte pairs is placed in the message immediately after the sequence of 2-byte encoded data in the subject filter field. Two byte pairs can constitute one form of attribute check bit string encoded data sequence, which, apart from the two byte pairs, is also used to represent other types of encoded data. be able to. A specific example of attribute inspection will be described later.

  Table 20 shows a technique for encoding the attribute check. Table 21 shows the encoding by two byte pairs and Table 22 shows the encoding of the operator ID in two byte pairs.

  Since the two byte pairs for the test already indicate both kinds of test operands, it does not matter whether the test is applied to a given attribute or to any attribute. There is no need to organize multiple tests performed on attributes or their types individually. This method assumes that the number of predetermined attributes in the notification is 127 or less. Alternatively, the attribute check may be encoded with more bits in this design.

  This arrangement convention determines the order of attribute checking and groups them based on the attribute filter's DNF, but infrastructure elements (eg, routers) can make a comprehensive evaluation of attribute filters more efficient. The tests may be selected and evaluated in another order (eg, in an order dynamically derived from local data regarding the probability of success or failure of different tests). The subscription ID field of the message is a value generated by the agent to uniquely identify the subscription to the agent's edge router in subsequent requests and to change or cancel the subscription. Specifically, the dynamic change to the subscription reservation attribute filter is subject to #. The message format shown in the embodiment of FIG. 18 is propagated except that it is RESUBSCRIPTION and the subscription reservation ID is registered in advance and is the ID of the subscription reservation that is currently being changed. The unsubscription is, for example, that the subject is #. UNSUBSCRIPTION is used, and the subscription reservation ID is registered first, and the subscription reservation ID for which subscription stop processing is performed is propagated through the subscription reservation ID field using the message format shown in FIG.

  Hereinafter, a specific example of the conversion and encoding by the agent described above will be described. First, a specific example of the following attribute filter expression will be considered. That is, price> = 10 and (symbol == “LU” or (volume> = 1000 and volume <= 10000)). FIG. 19 shows a diagram 390 representing, in step 362, the object used by the agent to store the representation in unified modeling language (UML). The diagram 390 illustrates a hierarchical relationship for identifying subscriptions that can include variables, constants, or both. Objects in diagram 390 may be instances of filter classes, depending on the particular implementation. Each SimpleFilter object represents an attribute value that is used to store information about the corresponding attribute check of the filter expression. In the expression shown in FIG. 19, the OR filter 396 combines two AND filters 392 and 400. The AND filter 392 includes a simple filter 394 having an attribute for subscription reservation. Similarly, the OR filter 396 includes a simple filter 398, and the AND filter 400 includes simple filters 402 and 404.

  In this embodiment, attribute price (price), symbol (symbol), and volume (volume) are defined in advance as attributes of related channels, and positions 0, 1, and 2 are defined for these attributes, respectively. It is assumed that Furthermore, the type of each attribute is an unsigned integer (type code 6), a character array (type code 12), and an unsigned integer (type code 6).

  Next, a subscription reservation including the attribute filter expression described above as an attribute filter will be considered. FIG. 18 shows a specific example in which subscription reservations are arranged in a message. The data structure 386 on the left side of FIG. 18 shows the actual message content, and the data structure 388 on the right side of FIG. 18 shows a description of each part of the message. The width of each data structure in this drawing corresponds to 4 bytes. Before doing the array, the filter is converted to equivalent DNF like (price> = 10 and symbol == "LU") or (price> = 10 and volume> = 1000 and volume <= 10000) .

  The 16-bit attribute check encoded data is shown as a bit sequence having a gap separating different parts. Note that in this example, the two tests for price are in separate choices and cannot be combined, so they are in a range that does not have a right boundary (the right side is As an open range). On the other hand, the two exams for the volume can be combined because they exist in the same discourse, so they are organized as a single “closed range” exam.

  Also, certain fields are characterized as “assumed”, because in this example, the values of these fields are arbitrarily chosen and are usually independent of the ordered subscriptions. Means. In addition, the subject filter for the subscription is arbitrarily selected as “>”, which matches any subject defined by the associated channel. The specific examples described above and shown in FIGS. 18 and 19 are exemplary, and this arrangement may be used with any other type of subscription. Further, the process 350 is merely an example of the arrangement of subscription reservations, and the subscription reservations may be arranged by any other method.

  FIG. 17 is a flowchart of an agent process 376 for a transmitted message. The process 376 can be realized by the agent 128 and the application 126 in the user device 122, for example. In process 376, agent 128 receives a message corresponding to the subscription from the intelligent router (step 378). For example, the 128 agent determines the channel corresponding to the subscription reservation by the channel ID of the message (step 380), and calls the API of the channel (step 382). The API displays the data for subscription reservation in the GUI or other format at the user device (step 384). As a process for the input message, a data decoding process opposite to the above-described encoding process can be used, and this decoding (decoding) can be performed in a router or other network entity.

Wildcard Processing FIG. 20 is a flowchart of wildcard processing 410. The process 410 is an example of a process for converting a wild card into an expression for subscription reservation using a set of routing rules of the filter. Process 410 may be implemented, for example, as a software module represented by agent 128 executed by processor 134 in user device 122. Alternatively, the wild card may be processed by the intelligent router 92 or the processor 93 in the ASIC 91 having a corresponding function under software control in the network. Wildcards contain open fields or variable length fields, and Table 21 shows examples of such fields.

  In process 410, agent 128 or other entity receives a subscription that includes a wildcard (step 412). The subject length of the subscription can be specified when the issuer publishes the content, and the subject may be pre-processed in the issuer device. For example, the subject field is counted and the field count (length) is calculated by this. May be. The 128 agent counts the number of fields in the filter operand (step 414) and initializes a new rule (filter) with field length = N (step 416). The agent 128 reads the subscription reservation subfield (step 418) and determines whether the filter operand subfield 0 [i] is a wildcard (step 420). If the filter operand subfield is not a wildcard, the agent 128 adds a conjunctive clause to the rule, setting field [i] = 0 [i] (step 422). If the filter operand has additional subfields (step 424), agent 128 returns to step 418 to process this additional subfield. The parameter “i” represents a field, and i is an integer representing a field number in this embodiment.

  After processing the subfield, agent 128 determines whether the last filter operand subfield is ">" (step 426) and if the last filter operand subfield is ">", the length of The constraint condition is changed to field length> N−1 (step 428). Wildcard processing may use any kind of symbol, and “>” is just one example. In this specific example, “a.>” Causes a. b, a. c, a. d, etc. and all these sub-subjects at all levels (eg abx, acx, abxy, etc.) can be represented. Other symbols may be used as wild cards.

  If necessary, agent 128 propagates the modified rule to the intelligent router or other entity in the network (step 430). The process is repeated for all subfields, which converts wildcards into non-wildcard rules. Non-wildcard rules mean rules that do not contain wildcards. Wildcard conversion may occur anywhere in the network, for example, at a subscriber device or an intelligent router. Thus, this transformation may be performed on one entity by a transformation rule and propagated to other entities, or this transformation may be performed dynamically.

  Table 23 provides an overview of these exemplary routing rules for wildcard processing, along with specific examples. These routing rules may be generated by an intelligent router, for example, or may be generated by other network entities and propagated to the intelligent router. Furthermore, the routing rules in Table 23 are shown for illustrative purposes only, and wildcards may be converted using other routing rules.

Alert Service The intelligent content-based routing described above can be used in a variety of applications, one of which is a digital video surveillance system (hereinafter referred to as DVSS). For example, a user such as a police or security company can subscribe to a video clip from a camera at a particular location. The camera captures the digital video clips and transmits these clips over a network with content-based routing, such as the Internet, for example, and the network core processes the video clips based on the subscription. This allows the user to receive video clips of interest and these filtering can be distributed over the network. In addition to the video clip, any other type of content may be distributed, for example, to provide any type of warning for security breaches, fires, fraud detection, etc.

  As another example, the camera may have an associated motion sensor. When the motion sensor detects motion, it triggers the camera to send the video clip to the network upon imaging, and the network routes the video clip to the subscriber using content-based routing.

  In this way, the content-based routing described above can greatly reduce the network burden associated with video clip processing and routing. For example, a video signal generated by each charge coupled device (CCD) is converted by a digital video recorder (DVR) into local storage managed by DVR, global storage attached to a network, DVSS system, and IDSS management. Suppose we need to write to four different destinations, such as a server. Considering the network bandwidth for carrying such a large amount of data, the capacity of the CCD or DVR managed by the IDSS may not meet customer capability requirements. Thus, for example, bandwidth needs to be limited using technology for media or large customers. FIG. 21 shows a comprehensive architecture of a monitoring system in which each DVR can manage 4 or 16 CCDS.

Architecture overview:
FIG. 22 shows two examples of expansion that improve the capability of the monitoring system shown in FIG. 21 mainly based on the above-described technique. As shown in FIG. 22, the first extension aims to reduce the DVR backbone traffic, and the second extension is a content-based routing similar to the function for improving the data distribution efficiency as described above. A device called a z-box that provides a function is used.

Reducing local traffic on the DVR backbone:
Inefficient data distribution schemes can cause significant scalability issues. That is, when an image file generated by DVR is supplied to another box using a TCP-based protocol, the bandwidth used is proportional to the number of devices connected to the local area network (LAN). Become bigger. For example, for IDSS, the same streaming video data needs to be sent to each DVSS, which is a networked storage (SAN or NAS), IDSS monitor, and remote monitoring software.

  As one approach to solve this problem, each DVR may issue only one data stream to the LAN, and other devices connected to the network may receive this data stream as a result of the subscription. In this case, if the output rate of the DVR is 10 megabits / second (Mbps), for example, the output rate required to provide information to three subscribed devices on the network is not 10 Mbps but 10 Mbps.

  In order to realize such a publish-subscribe structure, the event notification API described above can be used in a DVR box or some other device (for example, IDSS, global storage) that uses DVR data. This API is simple but effective, where IP multicasting and recovery protocols can be used. This API can also be implemented based on the publish-subscribe model described above, so other implementations do not need to change the code and can simply be relinked to the full version of the library that provides the API. That's fine.

Proxy for DVSS:
Each DVSS can establish one connection to the DVR box (on a TCP basis) and receive streaming video data.

  As shown in FIG. 22, this approach can be described in two stages. In stage 1, which is the first stage, a proxy server (for example, z box 1) for processing all DVSS transmission data (that is, data supplied from DVR to DVSS) is prepared on the LAN side. This proxy server subscribes to all DVR data on the LAN and publishes the data to an external network (eg, the Internet). DVSS subscribes to this data. Therefore, the z-box 1 that is the proxy server includes a subscriber agent (eg, agent 128) and an issuer agent that issues this data via the publish-subscribe network such as the publish-subscribe network described above that collects data from the DVR. (For example, the agent 36).

  Stage 1 can significantly reduce traffic on the LAN side, but in some countries, typically asymmetric digital subscriber line (ADSL) has an uplink rate of 64 kilobits per second (kbps). If this is the case, the problem of traffic on the transmission link remains.

  Further referring to FIG. 22, in stage 2, the service provider's machine room is preferably borrowed or otherwise secured, and a second z-box device, eg, z-box 2 is placed there. Set up. For example, the z-box device may be disposed on a high net backbone. A single connection (tunnel) from this device to the z-box 2 can be established within the customer premises.

  In this case, the z-box 2 in the customer premises functions as a subscriber agent (eg, agent 128). The z box 2 can also function as a routing daemon (for example, the routing daemon 216). The z-box 2 subscribes to information that the DVR issues via the z-box 1 as a subscriber agent (eg, in a Hi-Net machine room). Between the z box 1 and the box 2, the publish-subscribe network as described above is constructed. Therefore, the z box 1 issues video information from the DVR, and the z box 2 subscribes to this video information in response to a request by the DVSS. As described above, the data delivery efficiency of the alert service is improved by using the event notification system disclosed herein. The z-box (eg, z-box 1 and box 2) preferably comprises a module for issuing and subscribing through this publish-subscribe network as described above.

Digital Content Delivery The intelligent content-based routing described above can be used for a variety of applications, such as video and music delivery via subscription, software updates, and the like. For example, a user can automatically receive updated software by, for example, subscribing to software updates such as virus removal software. As another example, a user may subscribe to specific video and music content and automatically receive the subscribed content. Video and music content can be received, for example, as streamed digital content. Furthermore, the processing load on the server for providing software, video, and music content can be substantially reduced by the distributed processing in the network core. Thus, network bandwidth can be effectively utilized in the same network infrastructure for providing content, along with various other advantages.

  A specific example of the architecture for realizing this routing is shown in FIG. Note that this architecture preferably assumes two levels of cache servers Cl, C2 that are located in the same facility of the network service provider. However, even if only the Cl cache server is used, the benefits of the present invention can be enjoyed. The cache servers Cl and C2 are servers that provide the distributed network caching described above (see FIGS. 14 and 15 and the corresponding description). This architecture is realized, for example, by two phases. In the first phase, assuming that no cache server C2 exists, a high-speed file transfer mechanism is used between the central distributor 450 and the cache server Cl to reduce the server load and time required to transfer large media files. Let This high-speed file transfer mechanism is preferably realized by providing a routing box (470 in FIG. 23) between the central distributor 450 and the Cl cache server. In the second phase, a routing box is provided in the cache server C2, and the above-described subscription reservation mechanism is realized between the user (for example, the user machine 460) and the C2 cache server.

Advantages of using a routing box:
The routing box 470 preferably includes a module (eg, the intelligent router 92 described above) for realizing content-based routing as described above. There are two main advantages of using the routing box 470 that implements the content-based routing described above. With these high-speed routing and file transfer solutions using the routing box 470, file transfer can be accelerated about 5 times compared to conventional file transfer protocols such as FTP and RCP. In addition, efficient multicast via a wide area network (WAN) can be realized. When sending data from a central location to a group of receivers, this routing solution uses a network multicast topology to accelerate the content delivery speed by building a multicasting tunnel over the WAN, and server load and network bandwidth. The demand can be reduced.

architecture:
Media content is distributed from the central distributor to the cache server C1. The Cl cache server stores all content files. Each Cl cache server requires a disk capacity of, for example, several tetrabytes in order to store all the contents. The user (for example, using a user machine 460 such as the subscriber machine 122) requests the content from the cache server C2 that stores only a part of the content. The cache server C2 requires a disk capacity of several hundred gigabytes, for example.

File transfer between user and C2 cache:
When a user 460 requests a media file by issuing a subscription, the file is served immediately if the requested media file to be processed by one of the C2 cache servers is already cached on the C2 server. Otherwise, the subscription is sent to the cache server C1, and the requested file is transferred from the cache server C1 to the cache server C2.

Pre-caching of media data from Cl cache to C2 cache:
The media file may be cached in advance from the cache server C1 to the cache server C2 based on a user subscription reservation or a subscription reservation pattern. For example, if the user 460 connected to the cache server C2 is mainly interested in pop music, the cache server C1 automatically sends a new pop music to the cache server C2 before the user 460 requests the music from the cache server C2. May be supplied.

Introduction phase:
The first phase includes, for example, processing for installing a high-speed file transfer mechanism that performs content routing between the distributor 450 and all the cache servers C1. Here, the cache server C2 is unnecessary. In this case, all users 460 connect directly to the cache Cl. The cache server C1 periodically receives new media files from the distributor 450. FIG. 24 illustrates the phase 1 architecture.

  In FIG. 24, the distributor 450 transmits a new media file to the routing box 470 only once based on the intelligent content-based routing technique described above. Therefore, the burden on the distributor 450 is reduced. The routing box 470 outputs a file to each cache server C1 using a high-speed file transfer mechanism. In this case, no further routing box is required on the receiver 460 side. Alternatively, another type of server may be used for the cache server C1.

  FIG. 25 shows the architecture of the phase 2 embodiment. In phase 2 shown in this embodiment, data is preferably routed and transmitted using a routing box 470 that implements the kernel. The kernel layer solution further reduces the overhead when sending files to reduce buffer copy and reduce context switch time. Further, in the phase 2 solution, as shown in FIG. 25, a cache server C2 is added to the architecture. Also, as shown in FIG. 25, a routing box 470 is preferably added at the same position in the service provider network on the C2 side. This can significantly reduce bandwidth requirements and potentially reduce bandwidth to hundreds of times.

  As shown in FIG. 25, a file transferred between the cache server C1 and the cache server C2 is transferred via a routing box 470 associated with the cache server C1 and a routing box 470 associated with the cache server C2. . Thus, using these routing boxes 470, a high-speed routing and file transfer solution is realized between the cache servers C1 and C2.

Quality of Service Management The intelligent content-based routing described above can be used, for example, for the routing of content that guarantees a specific delivery. For example, based on a service level agreement (hereinafter referred to as SLA), an ISP or a content provider reserves bandwidth to guarantee quality of service (hereinafter referred to as QoS). be able to. This is efficiently achieved by the content-based intelligent routing described above.

architecture:
There are at least two possible configurations to guarantee QoS in content distribution. In the first configuration, a plurality of links are connected to a network of one or more telephone companies (hereinafter referred to as TELCO). In the second configuration, only one network link to the TELCO network is used. In the embodiment shown in FIG. 26, two layers of routing boxes (hereinafter also referred to as R boxes) are provided. The R box 1 routes the packet to the R box 2 and the R box 3 based on the contents of the data packet. R box 2 and R box 3 route data packets to different network links (eg, L1-L4). Each link is connected to a TELCO network. To ensure bandwidth for premium customers, data packets generated for customers with the highest SLA are routed to the link with the highest bandwidth (highest priority). Guarantees a specific QoS for these customers.

  In the embodiment shown in FIG. 27, R box 1 routes data packets to R box 2 and R box 3. The R box 2 and the R box 3 route data packets to further different communication links, and these communication links are all connected to the R box 4. The R box 4 receives data packets from the four links based on the QoS level of each link. The R box 4 transmits a data packet to the Internet ISP via a network link (for example, L5). By implementing various algorithms for receiving data from each link, the system can dynamically allocate bandwidth for each link and perform better QoS management than a multilink configuration.

Technology:
For QoS guarantees, the intelligent and distributed content-based routing techniques described above can be used. Each packet that is routed is tagged for content-based routing. This solution economically enables QoS deployment for ASP / content providers, along with various other advantages.

advantage:
This solution allows Internet service providers (eg, IDCs) or content providers (eg, media on demand (MOD) service providers) to reserve bandwidth for each customer based on their SLAS.

Real-time alerts:
Alerts can have different priorities. For example, security and fire alarms can be given the highest priority and news announcements can be given a lower priority. Without QoS routing, ASP network bandwidth may be occupied by low priority alerts and communications, and top priority alerts may not reach subscribers in real time. This solution prevents this from happening. Alerts can also be sent to each customer based on their respective SLAS. Premium users may pay more to allocate more bandwidth to these users.

Real-time data distribution:
For some applications, such as, for example, video on demand (VOD), MOD, and voice transmission over IP (VoIP), bandwidth availability affects quality of service. In this solution, as described above, data packets can be routed based on the type of message by examining the contents of the packet. In applications that are greatly affected by bandwidth, these data packets may be routed to higher priority links. In addition to the message type, data packets may be routed to various subscribers based on the subscriber's SLA level. Using this solution, packets can be routed to higher level links for customers with higher SLA.

  This solution can also be used for software or anti-virus updates. For example, an audio driver file is routed to a link with a low priority, and an anti-virus file is routed to a link with a high priority, so that updates for anti-virus can be performed in real time.

Content-based filtering:
As shown in FIG. 28, the system can perform filtering and dynamic caching outside the ISP by using a collocation service and by placing the R-box inside the TELCO network. By using the R box inside the TELCO network and filtering the data based on the content filtering technique described above, traffic in the IDC / ISP network can be reduced. As a result, for example, it is possible to prevent a hacker attack such as a denial of service attack or unauthorized data access. The R-box also functions as a caching box for static and dynamic web data due to its ability to inspect the requested content. This solution has advantages such as enabling security, saving network bandwidth between TELCO and ISP, and reducing the load on the ISP server.

Caching by selective multicasting Message persistence refers to the property that a message can be stored and the stored message can be retrieved later. Many specific applications, such as e-mail, typically require long message persistence for messages communicated over a network. In ideal conditions where no network failure occurs, always-connected subscribers do not require any persistence beyond what is required in these particular applications. In reality, however, messages may be “lost” for various reasons while being transmitted over the network. The reason for this is, for example, (1) a failure or buffer overflow on the network or user side, or (2) a case where the user disconnects the network and then reconnects after a predetermined period.

  The event notification platform persistence model in this example is divided into two levels: short-term persistence and long-term persistence. Short duration restores packets lost due to network congestion or short term link failures. Long-lasting recovers lost packets due to other failures, including, for example, user connection failures, user device failures, application failures and / or failures in the network for longer periods of time. Hereinafter, specific examples of these two schemes will be described.

Short-term persistence: data retransmission and flow control In data networks, the cause of data loss can simply be categorized into two: link failure and buffer overflow. In order to provide a reliable channel for the event notification system, these problems need to be solved. For link failures, a forward error correction (FEC) scheme can be performed to correct some errors caused by link failures. Here, if the error is severe and cannot be corrected by any FEC scheme, there is a need to provide a further scheme to recover the packet. It is also necessary to prevent the occurrence of buffer overflow. In order to avoid such problems in data networks, a flow control scheme is usually used.

  In the short-term persistence scheme, the event router (for example, intelligent router 12) is preferably connected in a hop-by-hop manner using a transmission control protocol (hereinafter referred to as TCP) tunnel. There are several reasons for using a reliable layer-2 tunnel instead of using a reliable transport protocol (eg, RMTP). In the short duration scheme, preferably in the event notification system, if the message does not satisfy the filter rules, the message is ignored at the router. As a result, in many cases, the receiving router cannot detect a packet loss even if a scheme such as a source sequence number (SSN) is used. It is also undesirable for all receiving routers to acknowledge each received packet. When such a process is performed, an overload of an acknowledgment (that is, ACK explosion) occurs. Furthermore, to avoid buffer overflow, the short-lived model implements a flow control scheme that allows a router to provide message delivery to neighboring routers that send messages to itself before the router's buffer capacity is full. You can request to slow down. These schemes are covered by TCP.

TCP transmission policy:
In TCP used in the short-term persistence scheme, it is preferable to monitor the retransmitted data locally using a transmission window on the data transmission side. There are two purposes for using the send window. First, the transmission window allows the transmission side to explicitly confirm that the data has been correctly received by the receiver, and second, the transmission window can more effectively utilize the channel capacity. In TCP, each byte sent by the sender needs to be implicitly or explicitly acknowledged. The transmission window helps the sender to monitor the transmitted and acknowledged data. Since the transmission side can transmit data within the transmission window without having to stop the operation and wait for an acknowledgment regarding the previous packet, the transmission window can improve the utilization efficiency of the channel. Once the previous data is acknowledged, the window is automatically advanced.

  In TCP, the reception window is also maintained. The receive window is preferably used at the data receiving terminal to indicate the available buffer capacity. The available buffer capacity is sent to the sender, which allows the sender to know how to avoid buffer overflow at the receiver.

TCP congestion control:
Since TCP is designed as an end-to-end transport protocol, TCP utilized in the short-lasting scheme also solves the problem of buffer overflow in publish-subscribe networks. To solve this problem, the TCP used for the short-term persistence model preferably uses a third window, the congestion window. The sender can use the congestion window to estimate the maximum buffer capacity at the router along the path. In short, the size of the congestion window is reduced when the transmission side detects a packet loss, and conversely, the size of the congestion window is increased when no packet loss is detected.

Long-lasting: persistent channel caching Channels may be persistent (eg, as described above) or real-time. Real-time channels are useful only in real time and transmit data without any application specific persistence requirements. The persistent channel stores data transmitted and received over the network for a sustained time frame T. In other words, the persistence of the persistent channel is guaranteed during the time frame T. This data persistence can be achieved, for example, by caching data at each edge node for the duration of the channel, retrieving data from a cache that is transparent to the user under fault conditions, Allows data to be explicitly read from the cache, protects against router failures and establishes a reliable tunnel between routers to make the flow of data through the network persistent and replicate This is realized by protecting the channel component against failure.

  Therefore, as described below, when a subscriber's terminal fails due to a long-lasting scheme and returns again within the time frame T for the persistent channel, the subscriber registered in the persistent channel During the time frame “X” (X <T), old data cached in the network can be retrieved.

  In a long-lasting scheme, a subscriber application (eg, application 126) can preferably explicitly pull data (eg, a message) from an associated subscriber agent (eg, agent 128). As described above, the agent can use or be implemented by a proxy. After the agent or proxy recovers from a failure in the network, the agent preferably searches the cache for data corresponding to the period during which it was disconnected from the edge router. Also, the subscriber can access only the data contained in the immediately preceding T time frame in the long-lasting scheme. For this reason, the time is preferably determined for the edge router to which the agent (or proxy) is connected. The retrieved cached data is preferably delivered out-of-band and real-time delivery is not guaranteed. Examples of long-lasting schemes are for existing subscribers who have recovered from a crash or disconnected from an edge router (eg, edge router 16). New subscribers will not get the cached information.

Definition of persistence:
Timed persistence (by time frame T) for a subscriber is defined as the ability to retrieve the data contained in the previous time frame T from the publish-subscribe network. When a subscriber is disconnected from the network, any data on the persistent channel received during the absence of the subscriber is stored in the network during the time frame T (from receipt of the data). If the subscriber returns within the time frame T, the subscriber will not lose any data. However, if the subscriber returns within a period of 2T from T, the subscriber may lose data. Also, if the subscriber returns after 2T, the subscriber is preferably not guaranteed any previous data.

  According to the above definition, the publish-subscribe network tree with the subscriber as a leaf is maintained for a time frame T after the subscriber is disconnected, after which the subscriber needs to be disconnected. Thus, after the subscriber is disconnected, new data received during the time frame T is retained until the time frame T elapses.

architecture:
FIG. 29 is a block diagram illustrating a portion of a publish-subscribe network that provides persistence through caching. As shown in FIG. 29, the network includes a core routing node 548 and an edge routing node 545. Each routing node preferably comprises an intelligent router 92 (shown with an edge routing node) and a conventional backbone router (not shown), as described above with reference to FIG. Each intelligent router 92 that needs to perform caching for persistent channels comprises a cache manager 218, preferably in the same location, as shown in FIG. The cache manager 218 is as described above with reference to FIG. Intelligent router 92 preferably provides short-term persistence for retrieving lost data or recovering from a router failure. The cache manager 218 caches data to achieve long-term persistence in the channel. Cache manager 218 preferably caches this data in cache 540. Cache 540 preferably includes memory and disk (not shown).

  Providing the cache manager 218 for the intelligent router 92 to cache data for long-lasting has the following advantages, for example. An expensive operation to index the cached data can be performed by an independent processor, thus not affecting the performance of the routing and filtering processor, and periodically moving the cached data to disk Disk I / O operations can be performed by other processors, thereby preventing the cycle from being lost from routing and filtering, and eliminating the need for the edge router to perform regular input / output operations.

  29 is preferably provided in the subscriber device 122 (not shown in FIG. 25A), as described above with reference to FIG. Agent 128 communicates with cache manager 218 to retrieve data from cache 540, receive the retrieved data, and organize the retrieved data. As described above, the agent 128 can utilize or be implemented by a proxy.

  Under conditions where no failure occurs, only the edge router node 545 need have an associated cache manager 218. However, although not shown in FIG. 29, the long-lasting scheme expects a failure, and preferably each of the first level core routing nodes 548 upstream of the edge routing node 545 is the data. A cache manager 218 is stored. Upstream is the direction away from the agent 128 (ie away from the subscriber machine 122). The first level upstream core routing node means a routing node adjacent to the edge routing node 545 on the upstream side. Although the publish-subscribe network often includes multiple first level core routing nodes, FIG. 29 shows only one first level core routing node, ie, core routing node 548. Yes. As described above, the cache manager 218 realizes local caching of data in the network node where the cache manager 218 exists. Thus, for example, the operation of the cache manager 218 present in various core routing nodes, including the core routing node 548, provides distributed caching of data within the network core. This distributed caching provides a backup for edge routing node caching.

  FIG. 30 is a diagram for explaining backup caching in the upstream router (for example, the core routing node 548). In each long-lasting scheme, each cache is backed up by the next upstream router cache. The upstream cache stores all received data and serves as a backup for the cache of all downstream edge routers. Upstream cache data is preferably stored using the same mechanism as edge router caching.

  FIG. 31 illustrates an architecture for persistent channel caching, which preferably provides functionality across four different modules as follows. The cache manager 218 preferably performs server processing for storing data passing through the intelligent router 92. The router cache API 552 is preferably a library for all access related to the control from the intelligent router 92 to the cache manager 218, eg, the process of creating and clearing the cache. The agent (or proxy) cache API 554 is preferably a library for all access related to control from the agent 128 (or agent 128 proxy) to the cache manager 218, eg, retrieval of data. Agent 128 (or proxy) preferably collects the retrieved data from cache 546 and organizes this data.

  The interaction of these four modules will be described with reference to FIG. Agent 128 and intelligent router 92 preferably access the cache via cache API libraries 552, 554. Cache API libraries 552, 554 provide APIs to initialize cache 546, create and delete caches for subjects, retrieve cache addresses, and retrieve data from cache 546 as the most important function. . The routing daemon 216 preferably sends data to the cache manager 218 via the data path, not via the cache API 552. The cache APIs 552, 554 preferably use the control path for all control messages including data retrieval.

Cache Manager-Cache management:
As shown in FIG. 32, when the cache manager 218 encounters a new channel, the cache manager 218 preferably calls an information server (eg, the servers 152, 154 and / or 156 described above) and uses the channel manager for that channel. Get 150. When the cache manager 218 obtains the channel manager's 150 address, the cache manager 218 preferably retrieves channel characteristics from the channel manager 150. Channel characteristics include, for example, channel subject tree and attributes, channel persistence characteristics, channel persistence time frame (T), and caching accuracy. Before the cache manager 218 starts caching data transmitted over a channel for a given subject, the cache manager 218 needs to create a cache for that subject. The cache manager 218 waits for a cache creation message and creates a subject cache in response to the message. This subject cache is cleared, suspended or resumed on demand. FIG. 32 shows the creation of a cache for a subscription reservation.

Cache Manager-Cache data input:
The cache manager 218 is preferably able to access data entering the intelligent router 92 by various techniques as described below. That is, a solution similar to IP that sends all data on the input link of the intelligent router 92 to the cache manager 218 may be used. A sniffing mechanism may also be used (in this case, the cache manager 218 waits for all packets transmitted over the network of intelligent routers 92. After filtering, the intelligent router 92 has one Each message that needs to be propagated to these links may be provided to the cache 546. Also, the cache manager 218 may function as a subscriber for the data provided to all intelligent routers 92.

Cache Manager-Cache data storage:
As shown in FIG. 33, preferably, the cache manager 218 may include, for example, a channel ID, a subject, an issuer ID, a timestamp, a time grain (G), a primary caching attribute, a link (a special case where caching is performed due to a failure The data in the cache 546 is indexed by various other techniques. Data may be indexed and stored in a file system or hierarchical directory structure in memory. Data is preferably cached in memory and periodically moved to disk. Caching in the memory is performed only during the time gray “G” period. When time grain G elapses, all data associated with a particular branch in the tree is preferably moved to a file under that branch, overwriting the oldest file in that branch (note that each message Time grain G is preferably implemented as an absolute window, not as a sliding window, because writing to the disk individually is expensive and it is more efficient to write the G period to the disk in a single operation) . FIG. 33 shows a specific example of an index tree. When caching data for persistence, the first index tree shown in FIG. 33 is preferably used.

  As shown in FIG. 33, the subjects are preferably stored in a hierarchical structure, where “a” is the subject's subject, eg, “ab”, “ac”, “ad”, etc. Parent. Cache manager 218 stores a hash table for cache 546 that maps all subjects to corresponding file locations. In some implementations, a cache 546 has failed if an upstream router (eg, core routing node 548) detects a failure in a downstream router (eg, edge routing node 545) on that link. Under certain conditions, data must be stored. One approach to recovery is to restart the downstream router (this process can take several minutes). While the downstream router is being restarted, the upstream router needs to cache the data supplied in the downstream direction of that link. This cache (for example, shown as FM cache in FIG. 33) is preferably indexed on the output side link.

Cache Manager: Garbage Collection:
If the channel is not persistent, the cache 546 does not save the data and immediately erases the data. If the channel is persistent, the cache 546 stores the data. The duration time frame “T” of a particular channel is divided into N time grains each of size G. Caching to the memory is performed only for a period corresponding to G. If the cache manager determines that period G has elapsed, the data is moved to disk. The cache manager 218 stores the data on the disk for a sustained time frame period T.

  Data corresponding to period G is deleted from the disk when the time has passed the channel + period upper duration time frame period (T). Specifically, for example, it is assumed that the continuous time frame period T of the channel is 2 hours. Here, as an example, it is assumed that the cache manager 218 uses a time grain G of 15 minutes. In this case, the rules for deleting data from the disk are as follows. That is, when the data cached last during the period G (15 minutes) is stored for the period T (2 hours), all the data cached during the period of 15 minutes is discarded. Therefore, the data cached at the beginning of the 15-minute period is stored for more than 2 hours before being discarded. In this embodiment, the data cached in each 15 minute period is a block of data. If the duration time frame T is divided into N periods, at any time, N + 1 blocks (N in disk and 1 in memory) of data are stored in the cache 546 for each subject. .

Cache Manager-Cache data search:
As shown in FIG. 34, the agent 128 (or proxy) preferably calls a cache read process (GetCache operation), and obtains data that is back for a period T from the current time. In FIG. 34, the cache manager 218 to which the agent 128 is connected in order to call the cache read process is labeled with a portal cache. Due to a router / agent 128 failure / disconnection, the portal cache may not have all of the data requested by the agent 128. In this case, the portal cache retrieves data from all other caches (eg, upstream cache), collates the data, and returns this data to the agent 128. FIG. 34 shows a search from multiple caches (A, B, C) for different time stamps (TS1, TS2, TS3).

  The cache manager 218 preferably retrieves only blocks of time grain G data. Thus, the agent 128 may be provided with more data than expected or requested data. Further, when searching from a plurality of caches, several periods are overlapped between the caches, and the agent 128 may be supplied with duplicate data, so that the agent 128 is provided by the cache. Duplicates in the data stream need to be removed.

Interaction with other modules of the cache manager:
The cache manager 218 preferably interacts with several modules in the event notification system infrastructure, as shown in FIG. When cache manager 218 encounters a new channel (at cache creation time), cache manager 218 preferably calls information server 550 to obtain channel manager 150 for that channel. Once cache manager 218 obtains the address of channel manager 150, cache manager 218 preferably obtains information about channel characteristics from channel manager 150. The administrator module 552 is preferably capable of setting / changing several characteristics such as the degree of caching division. The administrator module 552 can also preferably create / delete channel caches manually.

Agent Cache API-Application Agent Interaction:
An application (eg, application 126) preferably calls the agent cache API 554 to obtain a cache 546 with a predetermined subject and filter. Preferably, the application can retrieve only the data from the cache 546 if the application has already subscribed to the data. The agent cache API 554 actually provides two APIs preferably.

  The first API allows an application that has not subscribed to subscribe to and search the cache 546 at the same time. If the “FIFO” flag is set, a subscription is created and sent to the edge router node 545. After agent 128 has received all the cached data, agent 128 first delivers all the cached data and monitors that data for the last sequence that all issuers could not confirm, The interrupted data is distributed from the last sequence that cannot be confirmed by each issuer.

  The second API assumes that the application subscribes to existing data and requests cached data. In this case, some non-continuous data regarding the cache data is already distributed to the application. In this specific example, the “FIFO” flag simply indicates that the data read from the cache 546 determines its own order but need not be in the same order as a normal data stream.

  Agent 128 preferably reads all events within one large block of data. After reading the data from the cache API 554, the agent 128 preferably performs the following operation on the data before invoking a callback operation (see above). This operation is the generation of a notification from the list of notifications, monitoring the last sequence number for each issuer, and filtering. When the process of passing all events to the callback by the agent 128 is completed, the agent 128 passes a cache completion event (DoneCache event) to the callback, indicating that all cached data has been delivered. At this time, if the subscription is a FIFO and normal data is suspended, agent 128 preferably delivers all suspended notifications. At this time, the agent 128 delivers only a notification whose sequence number is greater than the last sequence number in the cached data.

Agent cache API and cache interaction:
When a subscriber provides cached data, the cache API 554 on the agent 128 side preferably first looks at the history of the edge router to which the agent 128 is connected and is defined by a cache read request (GetCache request). The list is filtered using a certain period. The API 554 sends a cache read (GetCache) (channel, subject, filter, local_pubs, time_period, FIFO, router array message to the last edge cache to which the API 554 was connected. The cache manager 218 preferably has a channel ID. Pull the data based on the subject and timestamp and return this data to the agent 128. When the supply of data by the cache manager 218 is complete, the cache manager 218 passes a cache completion event (DoneCache event) to the cache API, Indicates that all data for which data transfer has been cached has been distributed.

  If the cache manager 218 cannot find the data locally, the cache manager 218 uses the “list of routers” provided by the agent 128 to retrieve the required data. When the cache manager 218 collects all the necessary data, the cache manager 218 collates the necessary data and performs deduplication and then supplies this data to the agent 128.

Cache connection history:
In order to allow retrieval of data from cache 546, cache connection history for both caches is preferably maintained at agent 128 as well as upstream caches. Since this information is needed if the agent 128 shuts down and crashes, this information needs to be stored persistently in a file. The cache connection history is preferably stored on the disk in the following file and format.

Edge cache location:
The location of the edge cache (eg, cache 546 of edge routing node 546) is preferably obtained from the channel manager / channel library. This occurs at startup and at any time following it, for example when the edge cache changes due to disconnection / reconnection, connection change, etc. The dispatcher notifies the agent 128 of all changes in the edge cache connection and these changes are communicated to the agent 128 cache library. Whenever a change occurs, that information is persisted.

Persistent storage: CACHE_ROOT / channel_id / Channel-path example for cached data The data is preferably stored in the following format:
Number of edge caches;
Edge cache 1: number of intervals, StartTime: EndTimeel, StartTime2: EndTime2,. . . ;
Edge cache 2: number of intervals, StartTime: EndTimeel, StartTime2: EndTime2,. . . ; ...
Here, the last time stamp is provided at the beginning of the list. Note that two different edge caches do not have overlapping periods (because agent 128 is connected to only one edge cache at a time). Each time a new entry is added, the old entries are checked to see if they are still valid, and if they are invalid, this entry is deleted. The period becomes invalid when time EndTime + channel duration <current time.

  An edge cache entry becomes invalid if all periods in the entry are invalid. Note that “EndTime” being 0 means that the period is currently valid.

Upstream cache location:
The location of the upstream cache (eg, cache 546 of core routing node 548) depends on the subject. Each subject has its own multicast tree, so the first level upstream cache set is a function of the subject. When a user subscribes to a subject, the intelligent router 92 always returns a list of upstream caches associated with the subject. Similarly, any change in upstream cache location due to failure or multicast tree reconfiguration is communicated to agent 128 via the control path. These changes are recorded locally in persistent memory (files).

Persistent storage: CACHE_ROOT / channel_identifier / subject (complete subject, not hierarchy)-path example for cached data The data is preferably stored in the following format:
Number of upstream caches;
Upstream cache 1: number of intervals, StartTime: EndTimel, StartTime2: EndTime2,. . . ;
Upstream cache 2: number of intervals, StartTime: EndTimeel, StartTime2: EndTime2,. . . ; ...
Again, the last time stamp is placed at the beginning of the list. Unlike the edge cache period, the agent 128 may have multiple upstream caches for a given subject, so the two upstream caches may have overlapping periods. Further, the contents of the upstream cache file are garbage collected using the same algorithm as in the edge cache.

Cache validity during data retrieval:
While agent 128 is active, agent 128 moves between different edge routers and upstream routers over the connection. The agent cache API 554 preferably stores this connection history in local memory. When the agent 128 needs to read the last T period of data from the cache 546, the agent cache API 554 preferably examines the connection history to determine the cache for accessing the data. The algorithm used for this is preferably as follows. (1) The cache library explores all edge cache periods and checks the periods included in the T time frame. (2) The list Le sorts the list Le based on the period start time. (3) For each period not covered by the edge cache in the LE, search the upstream cache, get information about all upstream cache periods that can cover this period, add the valid period to the list Lu, Lu is added to Le, Le is sorted using the period start time, and L is created.

  A cache list L is generated by this algorithm, and a period for reading data is obtained for each cache. This cache list L is then incorporated into the (4) cache read message and sent to the cache manager 218. On the cache manager 218 side, the cache manager 218 preferably takes (5) the cache period from the get cache message and reconstructs the list L sorted in the order of the start time. During each period of the list L, the cache manager 218 preferably (6) checks whether there is a gap between the previous period and the current period, and if there is a gap, the local cache of the data Request. If there is no such gap, the cache manager 218 preferably (7) instructs the associated cache to read the data. The cache manager 218 preferably (8) collates data from all caches and sends this data to the agent 128.

Router cache API:
The router cache API 552 on the intelligent router 92 side calls the cache manager 218 to create, delete, stop, and resume caching for a particular subject. The router cache API 552 also handles the initial configuration. That is, the router cache API 552 uploads the cache address from the intelligent router 92 to the channel manager 150, so that the agent 128 side (agent cache API 554) can obtain this information when necessary. In addition, the router cache API 552 reads the location of the other router's cache 546 (this location can be used, for example, in response to a subscription, and after the subject tree change, the intelligent router 92 agents the upstream cache for a given subject. 128).

Use of cache for pull:
The above discussion has focused on the use of a cache to implement persistent channels and return information by subscribers pulling data from the network. In a variant, any subscriber (new subscriber or reinstated subscriber) is saved from cache 546 (eg, the subscriber has not subscribed, but is saved in cache 546 for someone else's subscription reservation). You can pull any kind of data (including the data you have). The difference between this example and the previous example is that for restored subscribers the existence of data is guaranteed and the location of the data is known, but for new subscribers the stored data The position is unknown. A simple way to implement this variant is to issue a “FindCache” request on the channel. The cache detection request includes the channel ID, subject, filter, duration, and location of the agent 128 looking for the cache 546 with the requested cached data. All caches 546 are waiting for a cache detection request. When each cache 546 receives the request, the cache 546 checks whether the corresponding data is in its own data store, and if it stores the data, returns its location as a unicast message. . The agent 128 selects one of the caches 546 and invokes the cache 546 by a cache read process to obtain the data.

Latest data pull:
In another embodiment, a subscriber data application (eg, application 126) implements the latest data pull from which the latest message can be obtained for a given subject. This is effective, for example, for data such as stock price alerts. In this case, the user only wants information on the latest stock price, not a history.

Realization of cache manager:
In implementing the cache manager 218, preferably three types of threads are used. Data caching thread—The data caching thread preferably retrieves data from the connection to the intelligent router 92 and indexes the data and stores it in memory. Data storage thread—When the end of the period is reached, the data storage thread moves data stored in memory to disk and performs garbage collection on the expired data in this process. Data retrieval thread—The data retrieval thread preferably retrieves data from the cache 546 upon receiving a request for cached data. These three types of threads may be implemented as a single thread or as a pool of threads. Preferably, the data caching thread and the data storage thread are synchronized to the time when the data is moved to disk. By synchronizing the data storage thread and the data retrieval thread in this way, data is prevented from being erased during data retrieval.

data structure:
Specific examples of the data structure for caching are as described in Table 19 and the related description.

Data storage:
FIG. 36 illustrates a preferred directory structure used to store data files in a cache 546 called “Aquila Cache”. Each subject-level directory preferably has a set of child subject directories in addition to a data directory that stores data issued for that subject. For example, in the entertainment channel, data issued from a FOX movie is stored in a file in the directory of AquilaCache / Entertainment / FOX / Movies / Data (AquilaCache / Entertainment / FOX / Movies / Data) and is issued for the subject FOX. Is stored in a file in a directory of AQUILACACHE / entertainment / fox / data (AquilaCache / Entertainment / FOX / Data). In order to perform high-speed data storage, the directory hierarchy of a specific subject is preferably constructed when the intelligent router 92 requests the cache 546 to start caching for a predetermined channel and subject.

data search:
Data retrieval from the cache 546 needs to be done efficiently so as not to interfere with data storage and to prevent the cache 546 from being held up. In this data search, data is read from both the disk and the memory. In data retrieval, the following steps are preferably performed. (1) The position of the data node is detected. (2) Lock the data node. (3) Detect the time stamp of the data that needs to be recalled. (4) Read data and save it in memory. (5) Unlock the data node. (6) The data stored in the memory and read out are filtered, rearranged, and then pushed to the agent 128 client.

  Although the present invention has been described using exemplary embodiments, it will be apparent to those skilled in the art that these embodiments can be variously modified and the present invention includes any adaptations or variations thereof. For example, various types of issuer devices, user or subscriber devices, their channels and configurations, content-based routing and other functions can be implemented in hardware and software without departing from the scope of the present invention. is there. The invention is limited only by the claims and the equivalents thereof.

It is a block diagram which shows notionally this intelligent routing in a network core. 1 is a network diagram illustrating an intelligent router for issuers and subscribers. FIG. FIG. 2 illustrates an example network infrastructure configuration for intelligent routers and backbone routers. It is a figure which shows the hardware constitutions of an intelligent router. It is a figure which shows the structure of an issuer apparatus and a subscriber apparatus. It is a figure which shows the structure of the channel manager of an intelligent router. It is a figure which shows the structure of the software component of the user apparatus for connecting to the network which has an intelligent router. It is a figure which shows the structure of the software component for intelligent routers. FIG. 3 shows a packet structure for a message. It is a flowchart of an issuing process. It is a flowchart of a subscription process. It is a figure which shows a channel and a subscriber screen. It is a flowchart of a content-based routing process. It is a flowchart of a caching process. It is a figure which shows a cache index. It is a flowchart of the agent process for a transmission message. It is a flowchart of the agent process for a received message. It is a figure explaining the specific example of encoding of a message. It is a figure which shows the database structure for preserve | saving a subscription reservation. It is a flowchart of a wild card process. It is a figure which shows the structure of a digital video surveillance system. FIG. 2 shows a proxy for a digital video surveillance system according to a two-stage method. 1 is a diagram illustrating an architecture for digital content distribution. FIG. FIG. 2 illustrates a phase 1 architecture for digital content distribution. FIG. 2 illustrates a phase 2 architecture for digital content distribution. It is a figure which shows several outlinks for service quality management. FIG. 6 illustrates a single outlink for quality of service management. It is a figure explaining the filtering and caching outside ISP. It is a figure which shows the cache in a network. It is a figure explaining the backup caching in an upstream router. FIG. 3 illustrates an interaction between a cache having a proxy and a router. It is a figure explaining creation of the cache to a subscription reservation. It is a figure which shows an index tree. It is a figure which shows the search from several caches. It is a figure which shows interaction with a cache manager and the other module in a system. It is a figure which shows the file directory structure for a cache.

Claims (113)

In a routing method for routing packets to provide an alert service in a network,
Receiving a packet having a header section and a payload section containing information related to a video clip from a particular camera;
An inspection step inspecting a payload section of the packet to determine how to route a packet containing information from the particular camera to a subscriber at the network core;
And a routing step for selectively routing the packet based on the inspection.   2. The checking step according to claim 1, wherein, in the structure for associating the content predicate information with a corresponding network destination, the step of determining whether or not the information of the payload section matches the content predicate information. Routing method.   The routing method according to claim 1, further comprising the step of executing the inspection at a router in the network core.   The routing method according to claim 1, wherein the checking step includes a step of applying a filter to the information in the payload section.   5. The routing method according to claim 4, further comprising the step of propagating a filter used to perform said inspection to a router in said network.   The routing method of claim 1, further comprising the step of programming a router in the network to perform the receiving step, the examining step and the routing step.   The routing method according to claim 1, wherein the checking step includes a step of checking an attribute used to determine how to route the packet.   2. The routing method according to claim 1, wherein the routing step includes a step of selectively routing the packet to a digital video surveillance system.   The routing method according to claim 1, further comprising the step of executing the checking step in a local area network.   The routing method according to claim 1, further comprising the step of performing the checking step at an Internet service provider location.   The routing method according to claim 1, wherein the specific camera includes a digital video recorder and a charge coupled device.   12. The routing method according to claim 11, wherein the digital video recorder generates the packet having the header section and a payload section including information related to a video clip from the specific camera. In a routing method for routing packets to provide an alert service in a network,
Receiving a message including a header section, at least one subject, and at least one attribute associated with a video clip from a particular camera;
A subject / attribute read step for reading the subject and the attribute from the message;
A subscription reservation reading step for reading a subscription reservation based on the subject;
In the network core, an application step of applying the attribute to the subscription and determining how to route the message to a subscriber.   14. The routing method according to claim 13, wherein the subscription reservation reading step includes a step of reading a filter corresponding to the subscription reservation.   The routing method according to claim 13, further comprising the step of routing the message when the attribute satisfies the subscription.   The routing method according to claim 13, further comprising the step of deleting the message when the attribute does not satisfy the subscription. Retrieving a plurality of filters corresponding to a plurality of subscriptions;
Reading a plurality of attributes from the message;
Applying each of the attributes to each of the filters and determining whether any of the corresponding subscription reservations are satisfied;
14. The routing method of claim 13, further comprising the step of selectively routing the message based on whether any of the subscriptions are satisfied.   14. The routing method according to claim 13, further comprising the step of executing the application step in a router in the network core.   14. The routing method according to claim 13, wherein the specific camera includes a digital video recorder and a charge coupled device.   20. The routing method of claim 19, wherein the digital video recorder generates the message having the header section and a payload section containing information related to a video clip from the particular camera. In a routing method for routing packets to provide an alert service in a network,
Receiving a packet having a header section and a payload section containing information about a particular alert service event;
An inspection step inspecting a payload section of the packet to determine how to route a packet containing the alert service information to a subscriber at the network core;
And a routing step for selectively routing the packet based on the inspection. In a packet routing device for routing packets to provide an alert service in a network,
A receiving module that receives a packet having a header section and a payload section containing information related to a video clip from a particular camera;
An inspection module that inspects the payload section of the packet to determine how to route a packet containing information from the particular camera to a subscriber at the network core;
And a routing module that selectively routes the packet based on the inspection.   23. The module according to claim 22, wherein the inspection module includes a module that determines whether or not the information of the payload section matches the content predicate information in a structure that associates the content predicate information with a corresponding network destination. Routing equipment.   23. The routing device according to claim 22, further comprising a module for executing the inspection at a router in the network core.   23. The routing device according to claim 22, wherein the inspection module includes a module that applies a filter to information in the payload section.   26. The routing device of claim 25, further comprising a module for propagating a filter used to perform the inspection to a router in the network.   23. The routing device of claim 22, further comprising a module for programming a router in the network to perform the reception, inspection and routing.   23. The routing device according to claim 22, wherein the inspection module includes a module that inspects an attribute used to determine how to route the packet.   The routing device according to claim 22, wherein the routing device is arranged in a network including a digital video recorder.   The routing device according to claim 22, wherein the specific camera includes a digital video recorder and a charge coupled device. In a routing device that routes packets to provide an alert service in a network,
A receiving module that receives a message including a header section, at least one subject, and at least one attribute associated with a video clip from a particular camera;
A subject / attribute read module that reads the subject and the attribute from the message;
A subscription reading module that reads subscription subscriptions based on the subject;
In the network core, a routing device comprising: an application module that applies the attribute to the subscription reservation and determines how to route the message to a subscriber.   32. The routing device according to claim 31, wherein the subscription reservation reading module comprises a module for reading a filter corresponding to the subscription reservation.   32. The routing device according to claim 31, further comprising a module that selectively routes the message based on a quality of service guarantee if the attribute satisfies the subscription.   32. The routing device according to claim 31, further comprising a module for deleting the message if the attribute does not satisfy all subscriptions. A module that retrieves multiple filters for multiple subscriptions;
A module that reads multiple attributes from the message, and
A module that applies each attribute to each of the filters and determines whether any of the corresponding subscription reservations are satisfied;
32. The routing device of claim 31, further comprising a module that selectively routes the message based on whether any of the subscriptions are satisfied.   32. The routing device according to claim 31, further comprising a module that executes the application in a router in the network core.   32. The routing device according to claim 31, wherein the routing device is arranged in a network including a digital video recorder.   32. The routing device according to claim 31, wherein the specific camera includes a digital video recorder and a charge coupled device. In a routing system that routes packets to provide alert services in a network,
Multiple digital video cameras that produce digital video output;
A local area network (LAN) connected to the digital video camera;
An issuer agent connected to the LAN and issuing the digital video output;
An issue-subscribe network connected to the issuer agent;
A routing system comprising a digital video surveillance system (DVSS) that receives the published digital video output via the publish-subscribe network.   40. The routing system of claim 39, further comprising: a subscriber agent connected to the publish-subscribe network, subscribes to the digital video output, and pushes the subscribed digital video output to the DVSS.   40. The routing system of claim 39, wherein the publish-subscribe network comprises a plurality of intelligent routers. The above intelligent router
A receiving module that receives a packet having a header section and a payload section that includes information related to digital video content from one of a plurality of digital video cameras;
An inspection module that inspects the payload section of the packet to determine how to route a packet containing information from the digital video camera to a subscriber at the network core;
42. The routing system according to claim 41, further comprising: a routing module that selectively routes the packet based on the inspection. In a network for distributing digital content to subscribers,
Multiple user machines,
A central distributor that delivers digital content regularly;
Receiving and caching the distributed digital content, periodically receiving a user request from the user machine for any of the cached digital content, and transmitting the requested digital content to the user machine Multiple cache servers,
The distributed digital content is received as a file from a central distributor, the digital content file is issued, the user request is subscribed, and the digital content file is cached using issue-subscribe content based routing. A network with a routing box to be transferred to a server.   The routing box is a first routing box, and the network includes a second routing box disposed at the same location as the plurality of cache servers, and the first routing box includes the plurality of caches. 44. The network of claim 43, wherein the digital content file is routed to the second routing box located at the same location as at least one of the servers.   44. The network according to claim 43, wherein the plurality of cache servers are arranged in a network service provider.   44. The network of claim 43, wherein the plurality of cache servers are first level cache servers that store all digital content distributed by the central distributor.   47. The network of claim 46, further comprising a second level cache server that stores a portion of the digital content distributed by the central distributor.   The routing box is a first routing box, and the network includes a second routing box disposed at the same location as the second level cache server, the first routing box and the first routing box. 48. The second routing box transfers the digital content file from the first level cache server to the second level cache server using publish-subscribe content based routing. Network. Each of the above routing boxes
A receiving module for receiving a packet having a header section and a payload section containing information related to the digital content file;
An inspection module that inspects the payload section of the packet to determine how to route the packet;
49. The network of claim 48, further comprising: a routing module that selectively routes the packet from the first level cache server to the second level cache server based on the inspection.   48. The network of claim 47, wherein the portion of the digital content stored by the second level cache server is determined based on a history of received user requests.   The second level cache server receives the user request directly and forwards the user request to the first level cache server for digital content not stored in the second level cache server. 48. The network of claim 47. The above routing box
A receiving module for receiving a packet having a header section and a payload section containing information related to the digital content file;
An inspection module that inspects the payload section of the packet to determine how to route the packet;
44. The network of claim 43, further comprising a routing module that selectively routes the packet from the central distributor to the plurality of cache servers based on the inspection.   44. The network of claim 43, wherein the central distributor comprises one or more servers.   44. The network of claim 43, wherein the digital content includes video, music, and software. In a distribution method for distributing digital content to network subscribers,
A distribution step of distributing the digital content from a central distributor;
A content routing step for routing the distributed digital content to a plurality of cache servers on a content basis;
A caching step of caching the content-based routed digital content to the plurality of cache servers;
Receiving a user subscription for the requested cached digital content; and
And a transfer step of transferring the requested digital content from the plurality of cache servers to the user based on the received user subscription reservation. The content routing step
Receiving a packet having a header section and a payload section containing information related to the digital content file;
Examining the payload section of the packet to determine how to route the packet;
56. The distribution method according to claim 55, further comprising a routing step of selectively routing the packet based on the inspection.   57. The step of checking includes the step of determining whether the information in the payload section matches the content predicate information in a structure that associates the content predicate information with a corresponding network destination. Delivery method.   57. The delivery method according to claim 56, wherein the checking step includes applying a filter to information in the payload section.   59. The delivery method of claim 58, further comprising the step of propagating the filter used to perform the inspection to a routing box in the network.   57. The delivery method of claim 56, further comprising programming a routing box in the network to perform the receiving step, the examining step, and the routing step.   57. The distribution method according to claim 56, wherein the checking step includes a step of checking an attribute used to determine how to route the packet.   57. The distribution method according to claim 56, further comprising the step of executing the inspection step in a routing box.   The plurality of cache servers are first-level cache servers, and the distribution method further includes transferring cached digital content to the second-level cache server using content-based routing. 56. The distribution method according to claim 55.   64. The distribution method according to claim 63, further comprising the step of determining whether or not the requested digital content is stored in the second level cache server.   68. The distribution method according to claim 64, further comprising the step of transferring the received user subscription reservation to the first level cache server based on the determination.   The forwarding step forwards the cached digital content to the second level cache server using content-based routing based on the received history of user subscriptions. The delivery method according to Item 63. In a routing method for routing packets based on quality of service guarantees in a network,
Receiving a packet having a header section and a payload section;
An inspection step inspecting a payload section of the packet to determine how to route the packet at the network core;
A determination step of determining a quality of service guarantee for the packet;
And a routing step for selectively routing the packet based on the inspection and the quality of service guarantee.   68. The checking step comprises determining whether the information in the payload section matches the content predicate information in a structure associating the content predicate information with a corresponding network destination. Routing method.   68. A routing method according to claim 67, further comprising the step of performing said inspection at a router in said network core.   68. A routing method according to claim 67, wherein said examining step includes filtering information in said payload section.   The routing method according to claim 70, further comprising the step of propagating a filter used to perform said inspection to a router in said network.   68. The routing method of claim 67, further comprising the step of programming a router in the network to perform the receiving step, the checking step and the routing step.   68. A routing method according to claim 67, wherein the checking step includes the step of checking attributes used to determine how to route the packet or whether to delete the packet. In a routing method for routing messages in a network,
Receiving a message including a header section, at least one subject, and at least one attribute;
A subject / attribute read step for reading the subject and the attribute from the message;
A subscription reservation reading step for reading a subscription reservation based on the subject;
Determining a quality of service guarantee for the message;
In the network core, applying the attribute to the subscription reservation and determining how to route the message;
A routing method comprising: selectively routing the message based on the application and the quality of service guarantee.   The routing method according to claim 74, wherein the subscription reservation reading step includes a step of reading a filter corresponding to the subscription reservation.   The routing method of claim 74, further comprising the step of routing the message if the attribute satisfies the subscription.   The routing method of claim 74, further comprising the step of deleting the message if the attribute does not satisfy the subscription. Retrieving a plurality of filters corresponding to a plurality of subscriptions;
Reading a plurality of attributes from the message;
Applying each of the attributes to each of the filters and determining whether any of the corresponding subscription reservations are satisfied;
75. The routing method of claim 74, further comprising the step of selectively routing the message based on whether any of the subscriptions are satisfied.   The routing method according to claim 74, further comprising a step of executing the checking step in a router in the network core. In a routing device that routes packets based on service quality assurance in a network,
A receiving module for receiving a packet having a header section and a payload section;
At least one inspection module that inspects a payload section of the packet to determine how to route the packet at a network core;
A determination module for determining a quality of service guarantee for the packet;
A routing device comprising: a routing module that selectively routes the packet based on the inspection result and the service quality assurance obtained as a result of the determination by the inspection module and the determination module.   The inspection module is a module for determining whether or not the information of the payload section matches the content predicate information in a structure in which the content predicate information is associated with a corresponding network destination or a rule governing the corresponding in-router processing The routing device according to claim 80, comprising:   81. The routing device according to claim 80, further comprising a module that performs said inspection at a router in said network core.   81. The routing device of claim 80, wherein the inspection module further comprises a module for filtering the payload section information.   84. The routing device of claim 83, further comprising a module that propagates the filter used to perform the inspection to a router in the network.   81. The routing device of claim 80, further comprising a module for programming a router in the network to perform the reception, inspection and routing.   The routing device according to claim 80, wherein the routing device is a router. In a routing device for routing messages in a network,
A receiving module for receiving a message having a header section, at least one subject, and at least one attribute;
A subject / attribute reading module for reading the subject and the attribute from the message;
A subscription reading module that reads subscription subscriptions based on the subject;
In the network core, an application module that applies the attributes to the subscription and determines how to route the message to a subscriber;
A routing module comprising: a determination module for determining a quality of service guarantee for the packet.   88. The routing device according to claim 87, wherein the subscription reservation reading module comprises a module for reading a filter corresponding to the subscription reservation.   90. The routing device of claim 87, further comprising a module that selectively routes the message based on the quality of service guarantee when the attribute satisfies the subscription reservation.   88. The routing device of claim 87, further comprising a module that deletes the message if the attribute does not satisfy all subscriptions. A module that retrieves multiple filters for multiple subscriptions;
A module that reads multiple attributes from the message, and
A module that applies each attribute to each of the filters and determines whether any of the corresponding subscription reservations are satisfied;
88. The routing device of claim 87, further comprising a module for selectively routing the message based on whether any of the subscription reservations are satisfied.   88. The routing device of claim 87, further comprising one or more modules for performing the filtering at a router in the network core.   88. A routing device according to claim 87, wherein the device is a router. In a routing / caching method for routing and caching packets of data in a multicast network,
Receiving a packet having a header section and a payload section;
An inspection step inspecting the payload section of the packet to determine how to route the packet to a subscriber at the network core;
A routing step for selectively routing the packet based on the inspection;
A routing / caching method comprising: locally caching data from the packet in the network core.   95. The routing / caching method according to claim 94, further comprising the step of performing said inspection at a router.   95. The routing / caching method according to claim 94, wherein said examining step includes applying a filter to information in said payload section.   97. A routing / caching method according to claim 96, further comprising the step of propagating a filter used to perform said inspection to a router in said network.   95. A routing / caching method according to claim 94, further comprising the step of programming a router in said network to perform said receiving step, examining step and routing step.   95. A routing / caching method according to claim 94, wherein said checking step includes the step of checking attributes used to determine how to route said packet.   95. The routing / caching method according to claim 94, further comprising the step of marking the cached data temporally.   95. The routing / caching method of claim 94, further comprising the step of indexing the cached data. Receiving a data request;
95. The routing / caching method of claim 94, further comprising: determining whether the cached data satisfies the data request.   95. The routing / caching method according to claim 94, further comprising the step of locally caching data from said packet at an edge routing node.   95. The routing / caching method according to claim 94, further comprising the step of deleting the cached data after elapse of time frame T. In a network that routes and caches packets of data,
An edge routing node that receives a packet having a header section and a payload section, the edge routing node comprising:
In the network core, instructions for examining the payload section of the packet to determine how to route the packet to a subscriber, and for selectively routing the packet based on the examination An intelligent router for routing the received packet;
A cache manager operatively connected to the intelligent router and having instructions for caching data from the packet locally to a local cache;
A network comprising one or more core routing nodes that receive and route the packets.   An instruction operatively connected to the edge routing node for determining the location of the cached data; an instruction for reading the cached data from the local cache; and processing the read cached data 106. The network of claim 105, further comprising an agent having instructions. One of the one or more core routing nodes is upstream from the edge routing node;
The upstream core routing node is
In the network core, instructions to inspect the payload section of the packet to determine how to route the packet to a subscriber, and instructions to selectively route the packet based on the inspection An intelligent router for routing the received packet,
106. The network of claim 105, further comprising: a cache manager operably connected to the intelligent router and having instructions for locally caching data from the packets into a local cache.   106. The network of claim 105, further comprising a plurality of channel managers that provide a plurality of channel properties. The above cache manager
106. The network of claim 105, further comprising instructions for marking the cached data temporally.   106. The network of claim 105, wherein the cache manager further comprises instructions for indexing the cached data. The above cache manager
Instructions for receiving the data request;
106. The network of claim 105, further comprising instructions for determining whether the cached data satisfies the data request. In a routing / caching device for routing and caching data packets in a multicast network, the routing / caching device includes:
A processor;
Instructions for receiving a packet having a header section and a payload section;
Instructions at the network core to examine the payload section of the packet to determine how to route the packet to a subscriber;
Instructions for selectively routing the packet based on the inspection;
A routing / caching device having instructions for locally caching data from the packet in the network core. The processor
A first processor that executes instructions for checking and instructions for selectively routing;
113. The routing / caching apparatus of claim 112, further comprising a second processor that executes instructions for locally caching.

Images