KR100985237B1 - Packet routing via payload inspection for alert services, for digital content delivery and for quality of service management and caching with selective multicasting in a publish-subscribe network - Google Patents

Abstract

In the distribution of digital content, such as video, music and software, packet routing is used through payload inspection at routers in the core of the distributed network, in the provision of alerting services, and in accordance with the quality of service assurance. The packet contains subjects and attributes in addition to the routing information. Subjects correspond to particular types of subscription content, and attributes encapsulate data or content. Subscription may be associated with a particular quality of service guarantee or service level. Routers store filters corresponding to subscriptions to content. Upon receiving the packet, it examines the payload section of the packet containing the attributes to retrieve the attributes and applies them to filters for subscriptions to content from the camera. If the attribute satisfies the filter, the packet is routed to the next link. If the attributes do not satisfy the filters, the router ignores the packet. This routing decision is distributed among the routers in the network core. The router caches data locally within the network core.

Distributed Networks, Alert Services, Routers, Packets, Attributes, Filters, Digital Content

Description

PACKET ROUTING VIA PAYLOAD INSPECTION FOR ALERT SERVICES, FOR DIGITAL, A method and apparatus for packet routing, a method and apparatus for message routing, a network and method for digital content distribution, and a method and network for routing and caching. CONTENT DELIVERY AND FOR QUALITY OF SERVICE MANAGEMENT AND CACHING WITH SELECTIVE MULTICASTING IN A PUBLISH-SUBSCRIBE NETWORK}

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

[Reference to Related Applications]

This application claims priority based on US Provisional Application No. 60 / 394,631, filed on July 8, 2002 and entitled "Packet Routing Via Payload Inspection for Quality of Service Management", which is incorporated herein by reference. do. The present application also discloses US Patent Application No. 10 / 199,356, entitled "Packet Routing Via Payload Inspection," US Patent Application, entitled "Method and Apparatus For Content-Based Routing And Filtering At Routers Using Channels." 10 / 199,368, US Patent Application No. 10 / 199,439, entitled "Method For Sending And Receiving A Boolean Function Over A Network", entitled "Method For Storing Boolean Functions To Enable Evaluation, Modification, Reuse" , US Patent Application No. 10 / 199,369 entitled "And Delivery Over A Network" and US Patent Application No. 10 / 199,388 entitled "Efficient Implementation of Wildcard Matching On Variable-Sized Fields In Connect-Based Routing" Continuation-in-part (CIP), all of which were filed on July 19, 2002 and are all incorporated herein by reference.

The present application also contains some of the following U.S. patent applications, also filed on March 28, 2003, which are also part of the previously referenced applications, which are entitled "Method and Apparatus for Reliable Publishing and Subscribing in Application No. 10 / 400,671 entitled "An Unreliable Network," Application No. 10 / 400,465, titled "Method and Apparatus For Content-Based Routing Using Compact Filter Storage and Off-Line Pre-computation," Method No. 10 / 400,453, Method and Apparatus for Implementing Query-Response Interactions in a Publish-Subscribe Network, Application No. 10 / 400,462, titled "Method and Apparatus for Implementing Persistent and Reliable Message Delivery," and invention No. 10 / 400,444 entitled "Method and Apparatus for Propagating Content Filters for a Publish-Subscribe Network".

Network bandwidth is growing exponentially. Meanwhile, network infrastructure (including routers, servers, daemons, protocols, etc.) still use relatively old technologies. As a result, Internet applications and network routers cannot keep up with the pace of bandwidth growth. At the same time, more and more devices and applications are becoming network enabled. The load that these devices and applications put on network nodes has increased tremendously. Increasing network load and number of applications also complicates the implementation and maintenance of network applications. As a result, the increase in network bandwidth and the ubiquitous use of network devices and applications are particularly important for the routing and transmission of data in older network infrastructures, especially when publishing content to subscribers. Can bring about problems.

The model for allowing the network to push information from servers to clients is a publish-subscribe style. In this model, the server becomes a simplified publisher of that information, regardless of which clients may be interested in the server's information or where they are located in the network. Clients become subscribers to the information, which is delivered when it becomes available, potentially regardless of the details of where it was published in the network. The network is then responsible for efficiently routing the published information to subscribers, matching information with active subscriptions, and doing all these things in a transparent manner to publishers and subscribers. .                 

Because the complexity of the servers in the publish-subscribe model is significantly reduced, the distinction between heavyweight servers and lightweight clients may begin to disappear, rather than issuers, subscribers, or both. It may begin to integrate into the notion of a possible peer. Different types of applications have a natural affinity for publish-subscribe forms of interaction between peers. A common theme underlying these applications is that the information being published and subscribed to is in the form of events. For example, an investor buys or sells a stock, causing the price of the stock to change. Traffic accidents on the roads lead to traffic congestion on the roads. If a security hole in the software system is found, a patch can be developed for users of the software. When a player fires a weapon in an internet game, the avatar of another player dies. All these example phenomena are events of potential interest to a large number of subscribers and can be propagated across the network to notify such subscribers that such events have occurred. Thus, an event is one self-contained succinct information about something potentially interesting that occurred at a given point in time on a network.

Typically the server or publisher makes routing decisions for the network to instruct the network where to send the published content in the publish-subscribe model. The publisher stores subscriptions to the content he has published. When receiving or creating new content, the publisher compares the content with respective subscriptions to identify if there is a match. If the content (event) meets any subscriptions, the publisher pushes the content over the network to the corresponding subscriber. This traditional publish-subscribe model places enormous burden on publishers, especially as more and more devices become available in the network and the number of subscriptions increases.

As the enormous number of applications across the Internet converge more heavily, the possibilities for the use of event notifications are endless. However, such possibilities require a more efficient way of making routing decisions and determining when events meet subscriptions to offload the issuer. Thus, a pervasive, persistent event notification service can provide significant added value for Internet applications as well as other applications and implementations.

The method and apparatus provide routing of packets for use in providing alert services in a network. The method and apparatus overcome the disadvantages of the prior art. Advantages of the method and apparatus include significantly reducing the burden on the network in the processing and routing of video clips. Another advantage includes reducing bandwidth requirements for the routing of video clips. Another advantage includes reducing local traffic on a digital video recorder local area network.

In an embodiment to achieve these and other advantages, a packet having a header section and a payload section is received, the payload section containing information about a video clip from a particular camera. The payload section is inspected at the network core to determine how to route packets to subscribers related to information from a particular camera, and the packets are optionally routed based on the inspection. These and other advantages may also be achieved by an apparatus comprising modules for performing these steps, for example.

These and other advantages can also be achieved by, for example, a method for routing messages in a network that provides alert services. The method includes receiving a message having a header subscription, at least one subject, at least one attribute associated with a video clip from a particular camera, retrieving the subject and attributes from the message, Retrieving a subscription based on, and applying an attribute to the subscription at the network core to determine how to route packets to subscribers related to information from a particular camera. These and other advantages can also be achieved by an apparatus comprising modules for performing these steps, for example.

Similarly, these and other advantages can be achieved, for example, by a method for routing packets for use in providing alert services in a network. The method comprises the steps of receiving a packet with a payload subscription and a header subscription containing information about an event for a particular alert service, and at the network core to determine how to route the packet to subscribers involved in the alert service information. Checking the payload subscription of the packet, and selectively routing the packet based on the checking. These and other advantages can also be achieved by an apparatus comprising modules for performing these steps, for example.

1 illustrates intelligent routing in a network core.

2 is a network diagram illustrating intelligent routers for publishers and subscribers.

3 illustrates a network infrastructure for intelligent routers and backbone routers.

4 is a diagram of hardware components of an intelligent router.

5 is a diagram of publisher and user devices.

6 shows channel managers of intelligent routers.

7 illustrates a software component of a user machine for interfacing the user machine with intelligent routers.

8 illustrates software components for an intelligent router.

9 illustrates a packet structure for a message.

10 is a flow chart of a publisher method.                 

11 is a flow diagram of a subscriber method.

12 shows channel and subscriber screens.

13 is a flow diagram of a content-based routing method.

14 is a flow chart of a caching method.

FIG. 15 illustrates a cache index. FIG.

16 is a flow chart of an agent method for an outgoing message.

17 is a flow diagram of an agent method for an incoming message.

18 illustrates an example of message encoding.

Fig. 19 illustrates a database structure for storing subscriptions.

20 is a flow chart of a wildcard method.

21 illustrates a digital video surveillance system.

FIG. 22 illustrates a proxy for a digital video surveillance system in a two-stage approach.

Fig. 23 is a diagram showing a structure for digital content delivery.

FIG. 24 illustrates a phase 1 architecture for digital content delivery.

FIG. 25 illustrates a phase 2 archtecture for digital content delivery. FIG.

FIG. 26 illustrates a number of out-links for quality of service management. FIG.

27 illustrates a single out link for service management quality.

FIG. 28 illustrates filtering and dynamic caching outside an ISP.

FIG. 29 illustrates a cache in a network. FIG.

FIG. 30 illustrates a backup persistent cache at an upstream router. FIG.

FIG. 31 illustrates the interaction of a router with a cache and a proxy. FIG.

32 illustrates cache generation on a subscriber.

FIG. 33 illustrates an indexing tree. FIG.

34 illustrates a retrieval from multiple caches.

FIG. 35 illustrates the interaction of a cache manager with other modules in the system. FIG.

36 shows a file directory structure for a cache.

The accompanying drawings are included in and constitute a part of this specification and together with the embodiments illustrate the advantages and principles of the present invention.

summary

Event notification systems on the Internet scale or other distributed network scale provide applications that provide powerful and flexible implementations of publish-subscribe networking. In such a system, an application program uses event notification APIs for issuing notifications and / or for subscribing to and receiving notifications about events that occur within the network.

Notifications in the system are given a subject, which is a string or other structure that identifies the type of information that the notification encapsulates. In addition, a notification is completed with a set of attributes that contain information specific to the notification. For example, an application may issue notifications about transactions in the New York stock market using the theme quotes.nyse and the symbol and price attributes. The application may issue an individual notification with specific attribute values, such as a symbol corresponding to SNE (Stock Breaking Symbol for Sony) and a price corresponding to 85.25. In the sense that attributes are found in all notifications for the same family of subject, most but not all of the notifications are predefined. However, publishers may add any attributes on a per-notification or other basis to provide specific information for additional events. Thus, not all or arbitrary attributes need to be predefined.

In such a system, subscribers are not limited to subscribing only to topics or entire channels. Channels will be further described and defined below. They may include, for example, a hierarchical structure specifying a subject field and one or more levels of related subfields (sub-topics). Therefore, subscribers can provide more finely tuned expressions of interest by specifying content-based filters on the nature of the notification. For example, a subscriber may subscribe for all notifications on the subject of quotes.nyse with a symbol corresponding to SNE and a price corresponding to 90.00 (possibly representing an opportunity to sell for a block of shares owned by the subscriber). . All notifications that match the subscription may be delivered to the subscriber through a callback or other type of method provided by the subscriber at the time the subscriber registers for its subscription or at other times. One subscription can be divided into many filters.

Callback can be a complex task of starting to sell a block of shares from a simple task, such as writing a message or sending an email to a terminal, and replacing an existing subscription with a new subscription (eg Many operations can be performed, including a much more complicated task of starting a new publish-subscribe activity (issuing a new notification that a portfolio of has changed).

Applications can, for example, benefit from agents in their publishing and subscription activities. Agents can be implemented using or using proxies. When an agent is used, the agents provide network connectivity for outgoing notifications and subscriptions, and delivery of incoming calls consistent with the notification to subscribers. When a notification enters the network, the router's system network propagates the notifications to all subscribers whose subscription matches the notification. One way to do this would be to broadcast a notification to every point in the network and allow the application agents to determine whether the notification is related to their subscribers. However, this is not a scalable approach, since the network is usually overwhelmed by the load of message traffic, especially when there are a large number of active and generating traffic. Although sufficient bandwidth is not a problem, subscribers will be overwhelmed by having to handle too many notifications.

The example network of the present system is much more efficient in the way of routing notifications. First, it may use multicast routing to ensure that the notification is propagated only once for any link in the network, for example. Second, it can use a number of sophisticated optimizations on the filters to reduce the propagation of notifications as much as possible.

1 conceptually illustrates such intelligent routing in a network core. The publisher 14 sends the content in the message via an edge router 16 to the network core 10 used in the publish-subscribe network. A publish-subscribe network for routing data or content from a publisher to subscribers includes any type of network. Content is transmitted over one or more channels 18 representing logical connections between routers and other devices. The intelligent router 12 of the network core 10 determines whether to route or forward the message. In particular, intelligent router 12 may determine whether the message contains content as subscribed by subscriber 24.

Each subscription can encapsulate a topic filter and an attribute filter. Routers may extend the subject filter to a set of matching subjects and merge attribute filters on a per-subject basis. The intelligent router evaluates the subject filter against the subject of the notification and evaluates the attribute filter against the attribute value of the notifications. The syntax for subject filters can use wildcards, and the syntax for attribute filters can use Boolean expressions, all of which are described further below. The term "filter" is used to describe a set of events that a subscriber wishes to receive from publishers. Routing rules are generated from the filters and used by intelligent routers to make routing decisions.

Thus, for example, if the entire set of filters is not satisfied by message 26, intelligent router 12 discards (discards) message 26, which means that the message is not forwarded. For example, if any filter in the entire set is satisfied by the message 20 by evaluation of the subject and attribute filters, then the intelligent router 12 may subscribe the message 20 via the edge router 22 and other devices to the subscriber 24. The router 12 performs other functions internally for the message 20 in accordance with all routing and / or operational rules defined for the corresponding filter. This search continues until either a complete review of the entire set of filters or a determination of all the rules is made first.

This type of intelligent content-based routing in the network core provides, for example, real-time data delivery of alerts and updates. Examples of real-time data delivery for alerts include stock quotes, traffic, news, travel, weather, fraud detection, security, telematics, factory automation, supply chain management, and network management. However, the present invention is not limited thereto. Examples of real-time data delivery for updates include, but are not limited to, software updates, anti-virus updates, movie and music delivery, workflows, storage management, and cache consistency. Many other applications are possible for conveying information about subscriptions.

Table 1 shows the storage of subscriptions including subjects and predicates for filtering. They can be stored anywhere in the network, in any data structure, upon request and need. As explained below, predicates are components of a subscription. Subscriptions may be expressed in any manner, an example of which is provided as follows.

TABLE 1 Join1 Topic 1 Predicate 1 ... Join N Topic N Predicate N

Table 2 provides an example of subscription and publication for a quote server. This example is provided for illustrative purposes only, and the subscription may include any number and any type of parameters relating to any type of data or content.

TABLE 2 Cited Server Example Topic tree
Quotes.NYSE
Quotes.AMEX
Quotes.NASDAQ publish
Topic = Quotes.NYSE
property
Symbol = SNE
Price = 51
Volume = 1000000 property
Symbol
Price
Volume join
Topic = Quotes.NYSE
filter
(Symbol = SNE) &(Price> 55)

The predicate provides a boolean expression in terms of subscription and the subject provides a channel marker for subscription. Subscriptions can be expressed in many different ways. Using boolean expressions is one example and provides the ability to easily convert subscriptions to subject and attribute filters for content-based routing. Alternatively, subscriptions may be expressed without reference to a subject. However, the use of channels (described later) or subjects provides a context for the application and interpretation of filters on attributes.

Routing decisions are made at the network core and distributed throughout the network, reducing the processing burden on the issuer and subscriber machines and greatly enhancing the efficiency of the network. 1 illustrates one issuer, one subscriber, and one intelligent router for illustrative purposes only, and may be implemented with multiple issuers, multiple subscribers, and multiple intelligent routers. The term intelligent router refers to a router or other entity that has the ability to make routing decisions by examining the payload of packets or messages at the network core or elsewhere.

Network infrastructure

2 illustrates a network showing intelligent routers for issuers and subscribers. The routing entity 30 that provides the channel service is effectively layered on the network infrastructure to route messages between intelligent routers, for example, as described below. Conceptually, the issuer 32 may, for example, have an application 34 that transmits a beacon (e.g., a pointer for content retrieval) of the published content and encodes the content for network transmission via the channel service 30. Agent 36. The collection of logically interconnected intelligent routers 38, 40, 42, 44, 46 and 48 routes content from the publisher using routing rules generated from subject filters and attribute filters on subscriptions. A plurality of links 39, 41, 43, 45 provide logical connections between the intelligent routers 38, 40, 42, 44, 46, 48. Another link 37, 47 provides a logical connection between the issuer 32 and the intelligent router 38, and between the subscriber 54 and the intelligent router 46, respectively. Subscriber 54 includes an agent 50 for detecting and receiving subscribed content, and an application 52 for presenting content.

The channel may include, for example, a group of related logical multicast-type connections, implemented in a distributed fashion. In this example embodiment the channel is a collection of logically related network resources used to support the community of publishers and subscribers exchanging content. Content is classified according to the channel topic namespace, and resources are managed, controlled, and supplied through channel services provided by the channel manager. Multiple channels can share the same resource. Channels can provide, but are not limited to, highly scalable directory services such as issuer and subscriber information, credentials and authentication information, message types, management information, and accounting and billing information. The channel may also provide persistence, high speed data transfer mechanisms, security, and user and network management, for example through caching. The channel can also be used for any other purpose.

Filtering by intelligent routers can occur at the network core to distribute routing decisions. Intelligent routers also function as edge routers connecting user devices such as publishers and subscribers with the network core. In addition, the same device connected to the network can function as an issuer to push content to subscribers through routing decisions in the network and also serve as a subscriber to the received delivery content. Intelligent routers and channels may be connected in any configuration, as required and required for a particular implementation, and the configuration shown in FIG. 2 is provided for illustrative purposes.

3 illustrates an exemplary network infrastructure for an intelligent router and a conventional backbone router, showing a logical connection for a channel. The intelligent router in this embodiment uses an existing backbone router in a network, such as the Internet or other distributed network, so that the intelligent router is effectively layered on the backbone router. In this embodiment, each of the Internet Service Provide (ISP) networks 58, 59, and 60 includes several backbone routers for conventional routing of messages or packets. The plurality of intelligent routers 61-70 are connected with one or more backbone routers in the ISP network 58, 59, 60. In addition, the plurality of intelligent routers 61-70 are interconnected by a plurality of links 73-85 (representing examples of links), and can also be connected to end user devices by such links. The intelligent routers 61-70 may be controlled by one or more administrator machines, such as entity 71, and one or more virtual private network (VPN) controllers, such as entity 72, and the like. ISP networks 58, 59, 60 will also be connected to the issuer and subscriber machines (not shown in FIG. 3). Backbone routers within ISPs 58, 59, and 60, and between each other, are interconnected in any conventional manner within existing network infrastructure.

Intelligent routers 61-70 and links 73-85 can be implemented using existing network infrastructure, as shown, which provides content-based routing in the network core. Links 73-85 represent logical connections between intelligent routers 61-70 and may be implemented, for example, using existing network infrastructure or other devices. Links may be implemented using, for example, logical connections called tunnels. The tunnel will include hardware, the network infrastructure that implements the link, and possibly software, and a tunnel can be part of multiple channels. Channels enable content-based routing in intelligent routers by providing a logical connection for certain types of content and thus providing a context for attributes transmitted over the channel. Intelligent routers may make routing decisions without channels, but channels increase the efficiency of content-based routing by intelligent routers within the network core.

This example embodiment involves the use of channels and links. A link is a connection between two routers (intelligent routers). A channel comprises a group of routers (usually large) and is static or configured to interconnect links to form a one-to-many or many-to-many logical connection. Dynamically configured network entity. Specifically, a channel is a top level logical entity that represents the essential characteristics of that channel. Under one channel, there may be a large number of subjects. Each subject will form one sub-network (eg, multicast tree) that contains a group of interconnected routers. These subject-based sub-networks can be allocated, adapted and configured in different ways from each other. A channel may be similar to a network mesh, for example, because it is a collection of all sub-networks formed for the topics under that channel.

4 illustrates exemplary hardware components of an intelligent router 92, which may correspond to any other intelligent router referenced. The network node 90 may include an intelligent router 92 connected with a conventional backbone router 95. Intelligent router 92 includes a processor 93 connected to memory 94 and secondary storage 97, each of memory 94 and secondary storage 97 capable of storing and caching data, In addition, an application executable by the processor 93 may be stored. The secondary storage device 97 provides a nonvolatile data storage function. As described below under software control, the processor 93 may cause the backbone router 95 to route messages or packets to the backbone router 95 in accordance with routing rules generated from the subject filter and attribute filters relating to subscriptions. Command to forward or not route (discard). Although shown as being implemented as a separate processor-controlled device, the intelligent router 92 is otherwise implemented as an application specific integrated circuit (ASIC) within the backbone router 95 and, where possible, hardware with embedded software to provide intelligent routing functionality. You can also provide Alternatively, the intelligent routing function may also be implemented as a combination of software and hardware in one or multiple routing devices.

5 illustrates an example issuer and subscriber machine. The publisher machines 100 and 118 may include a memory 102 storing one or more publisher applications 104 and an agent application 105, an auxiliary storage device 112 providing a nonvolatile data storage function, and input information or commands. An input device 108, a processor 114 for executing an application stored in the memory 102 or an application received from another storage device, an output device 110 for outputting information, and a visual display of the information. The display device 116 may be included.

Subscriber machines 122 and 140 may include a memory 124 that stores one or more applications 126 and agent applications 128, an auxiliary storage device 130 that provides non-volatile data storage functionality, and input information or commands. Providing an input device 132, a processor 134 for executing an application stored in the memory 124 or an application received from another storage device, an output device 136 for outputting information, and a visual display of the information. The display device 138 may be included. Alternatively, the publisher and subscriber machines may, in any configuration, include more or fewer components, or may include different components.

Publisher machines 100 and 118 are connected to subscriber machines 122 and 140 via network 120, such as the networks described above. Network 120 includes an intelligent router that provides distributed routing of content or data within the network core by packet or message. Although only two publisher and subscriber machines are shown, the network 120 can be scaled to include more publisher and subscriber machines. Publisher and subscriber machines may be implemented with any processor controlled device, such as, but not limited to, servers, PCs, notebook computers, PDAs, phones, cellular phones, pagers, other devices, and the like. The network 120 with the intelligent router may include a wired device, a wireless device, or any wired or wireless distributed network that connects both devices. Network 120 can also potentially use existing conventional network infrastructure.

6 illustrates a channel manager 150 for an intelligent router. In this embodiment, the channel manager 150 is implemented to include a number of servers 152, 154, 156. Each server has its own local storage 158, 160, 162. Intelligent routers 164, 166, and 168 connect with channel managers for information about a particular channel. Channel managers can also be prepared for data persistence, fail over functions, and other features. Therefore, the channel manager may provide a channel service that includes a database or set of databases at any location in the network that specifies, for example, channel-related information, attributes about data persistence, user information for publishers and subscribers, and infrastructure information. to provide. The infrastructure information may include, for example, an identifier of the intelligent router and a corresponding tunnel connecting the intelligent routers, a subject for the channel, and an attribute (name and type for each attribute) for the channel, and the like. The packet or message may also carry channel-related information, including the identification of invariant and variable attributes.

When online, the user can download channel information. For example, a user can register using a username and password. Once the user's logon is confirmed, the user can open (call) the channel and get information about the channel from the channel manager. The issuer can use the information in the context of the publication and the subscriber can use the information in connection with entering and registering a subscription.

Channel managers 152,154 and 156 preferably form groups to perform persistent, reliable channel directory services. One of the channel managers will be the primary channel manager and the other will be the backup channel manager. If the primary channel manager fails, the neighboring channel manager of the primary channel manager takes over and becomes a new primary channel manager to keep the service reliable. Each intelligent router holds the address of these channel managers. If there is one channel manager and the intelligent router cannot contact the channel manager, the intelligent router will look for something else to retrieve the information. Devices in the network may use, for example, instructions to retrieve channel information, examples of which are provided in Table 3. In contrast, an intelligent router may have only a primary channel manager or three or more channel managers.

FIG. 7 is a diagram illustrating exemplary software components in stack 180 in a user machine or device that connects the user machine to a network including an intelligent router. The user machine can be used as a publisher, a subscriber, or both, and can include the example devices identified above. Stack 180 may include one or more user applications 182, which are prepared for receiving subscriptions from users, receiving channel information from publishers, or receiving published content or data. Can be. User application 182 may also include any other type of application that the user machine or device will execute.

In addition, the stack 180 may include, for example, an agent 184, an event library 186, a cache library 188, a channel library 190, a messaging library 192, and a dispatcher library 194. It may include. Agent 184 provides for establishing a network connection or other functions, and Table 3 provides examples of commands implemented by agent 184 that may use proxy commands or other types of commands. . The event library 186 records events relating to user machines or other events or information. Cache library 188 provides local caching of data. The channel library 190 stores the identification of the channel and information about it. Dispatcher library 194 provides a connection with control path 196, channel manager 198, and one or more intelligent routers 200, and may include the example functionality shown in Table 4. The messaging library 192 provides a connection to the data path 204.

Tables 5-9 show examples of messaging APIs in the C programming language. Tables 5 and 6 show examples of APIs for sending and extracting messages. Tables 7 and 8 show examples of APIs for sending and extracting notifications. Table 9 shows examples of APIs for sending and extracting control messages. These APIs and other APIs, programs, and data structures herein are provided as examples for implementing particular functions or features, and implementations may refer to any type of API or other software entity in any programming language. It may include.

TABLE 3 Agent Command Example command function pc.chn.open Open channel, extract all information for the channel, and local caching pc.chn.close Close channel pc.chn.getRouterInfo Extract Information for Routers on Channels pc.chn.getAttributeInfo Extract Information for Channel Attributes pc.chn.getProperties Feature Extraction for Channels

Table 4 Dispatcher function Server side Listen for connection (waiting to accept). Create a thread to handle each connection. The thread is responsible for receiving and processing all requests coming from the connection. Client side Create a thread that is responsible for initiating a connection and receiving and processing all data coming into the connection.

8 is a diagram of an example software component 210 for an intelligent router such as the intelligent router 92 identified above and presented in FIG. 4. For example, software component 210 may be stored in memory 94 for execution by processor 93 in intelligent router 92. For example, component 210 includes a filtering daemon 212, a dispatcher 214, a routing daemon 216, and a cache manager 218. The filtering daemon 212 provides filtering so that content-based routing can process content for subscriptions in accordance with routing rules as described below. Dispatcher 214 provides communication of control messages such as those required to propagate filters through path 220, and also provides one entry point for users and one secure socket for channel managers. It can enhance security. In other words, the user does not directly contact the channel manager in this example, even if it is an alternative implementation. Dispatcher 214 uses a control message to obtain attributes (name-value pairs) from the channel manager.

Routing daemon 216 provides communication with data path 222, which may occur via the conventional backbone router or other routing device shown in FIG. 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 is described in more detail below and provides distributed data caching across a network core.

Content-based routing can be implemented at the kernel level as a replacement for the application level. The memory accessible by the kernel is separate from that at the application level. In order for content-based routing to run in an application, for example, message data is copied from the kernel memory area to the application area, and the context of the application is exchanged from the kernel to the routing application. Both cause significant loads. If instead the kernel is modified to support content-based routing, routing can be performed faster with the above-mentioned load removed.

As a feature of content-based routing in the kernel, the routing daemon 216 may or may not be able to directly send and receive data through the data path 222, which is implementation dependent. Daemons are processes that operate at the application level, precomputing content-based routing tables introduced into the kernel. But once introduced, routing tables can be used by the kernel to make routing decisions. Similarly, the filtering daemon precomputes the filtering table and introduces it into the kernel. In this kernel implementation, neither the routing daemon nor the filtering daemon interacts directly with the data path.

9 is a diagram of an example packet structure 230 for a message that may contain content for subscription. Packets or messages for use in content-based routing include, for example, a header section and a payload section. Header subscriptions specify routing or other information. The payload section specifies the data, content or representation of the data or content. Packet structure 230 includes an IP header 232, a User Datagram Protocol (UDP) Transmission Control Protocol (TCP) header 234, a length value 238, one or more subject fields 240, and one or more subject fields. Attribute 242 is included. Packet structure 230 shows the basic structure for length values, subjects and attributes. Packets used for content-based routing may also include other elements, such as shown in the example of FIG. 18 described below, and packets for content-based routing may be configured in any manner. In addition, the attribute may include, for example, any attribute that is appended to the end of the message. This optional attribute is, for example, ad-hoc information added by the issuer (or router) without having to be delivered using the message format defined for the channel.

Publisher and Subscriber Methodology

10 is a flow chart of an example publisher method 250 for use by publishers to set up channels and publish content. For example, method 250 may be implemented as a software module including an agent 106 for execution by processor 114 of publisher machine 100. In method 150, agent 106 of the publisher machine receives the publisher creation of the proxy for the channel (step 252). The proxy provides communication with the network. The agent 106 determines the message format for the channel via the interface (step 253), and the format information can be obtained, for example, from the channel manager or other entity in the network. Agent 106 uses the received channel information to establish a proxy for the channel (step 254), which is to receive an attribute for the channel (step 256) and to generate a notification to the channel (step). 258). The notification provides the content for the device to "listening" the content of the channel. The attribute defines the characteristics and parameters for the notification.

Agent 106 sends the channel's identifier (ID) and content information to the intelligent router of the network core for use in processing subscription (step 260). The publisher can populate the notification attribute to an appropriate value (step 261) and then publish the content to the notification in accordance with the channel attribute (step 262). In this example, steps 260 through 262 complete the issuance of a notification that may involve different or additional steps depending on the particular implementation. Thus, in this example, the information related to the notification is divided into an ordered sequence of attributes, each of which is a name, a position within the notification (starting at 1), a type, and a value. Alternatively, the attribute may have other characteristics depending on the particular implementation. For example, an attribute can include a predefined attribute, any attribute, or both.

The intelligent router may use the channel ID of the packet to obtain an attribute for the corresponding channel that determines the structure or format for the packet transmitted over the channel. In particular, each packet may contain tags associated with the channel ID and other header information such as, for example, issuer ID. The tag can be used to map a subject to a number of message formats, an example shown in FIG. Small integer values, for example 16-bit values, can be used as numbers. Alternatively, any other type of number or information can be used to map the subject. Mapping subjects to numbers can offer special advantages; For example, space can be saved in the message format, and a uniform or standard way of specifying the representation of the subject in the message can be made to quickly find and identify the representation. The intelligent router may store the mapping locally or use the numbers differently to obtain the corresponding subject remotely via command.

Table 10 shows the structure for mapping numbers to subjects, in this example using integer values. The subject tree parameter in the table indicates that a subject can include one or more subject fields in a hierarchical relationship; For example, the subject tree may include a string of subject fields separated by special symbols. Examples of subject trees are provided in Table 2. As an example, the subject tree quotes.nyse includes two terms, the subject "quotes" and the sub-field "nyse", which are distinguished by "." Found in other network addresses or URLs. Apart from using periods and specifying URL-type strings, the subject tree can be specified in any way using any symbol and character to distinguish it.

Table 10 number Subject tree Integer value 1 Topic tree 1 Integer value 2 Topic tree 2 … Integer value N Topic tree N

Thus, knowing the packet format or structure for a particular channel, intelligent routers can quickly assign subjects, attributes, or other information to packets for content-based routing. For example, the channel can be made easy to specify by the counting byte of the packet, so that the byte position of the subject and attribute sent over the channel can be found. Alternatively, the intelligent router may parse the packet to find the subject and attribute or other information.

Table 11 provides examples of publisher programs in the C ++ programming language. Table 12 provides an example of an API for creating a channel. Table 13 provides channel related information as shown and provides an example of a channel configuration file maintained by the channel manager (see Figure 6). The system may alternatively have a global channel manager that provides the IP addresses of geographically dispersed servers that serve as local channel managers to distribute the processing load.

11 is a flow chart of a subscriber method 264 for use in receive and subscription processing. For example, the method 266 may be implemented as a software module including an agent 128 for execution by the processor 134 of the subscriber machine 122. In method 264, for example, a graphical user interface (GUI) gives the user an indication of the channels available (step 266), which can be accomplished by the application 126. Information indicating a channel may be received from, for example, a channel manager providing channel related information. Any type of application 126 can be used to identify the channel in a particular method or format. The application receives the user's channel selection (step 268) and calls an API or other program for the selected channel (step 270). The API gives the user a subscription option for the channel according to the selected option (step 272). The API receives a value for a subscription from the user (step 274) and sends a subscription to the agent 128 for processing as described below (step 276).

The parameter for subscription may include a predicate as shown in Table 1, for example. Each channel may use its API, for example, to process subscriptions according to specific needs or parameters for the corresponding channel. These APIs may include, for example, web-based or Java-based APIs for subscribing, processing for receiving information about the subscription and passing it along with the agent application. You can use any type of user interface.

12 is a diagram conceptually illustrating channel and subscriber screens or GUIs 278 and 284, which may be used in connection with the method 264 for receiving a subscription. Screen 278 includes a number of sections 282 that identify available channels for selection by the user. Depending on the selection of a particular channel, screen 284 may be displayed to receive a user's value for subscription in section 286. The user may select section 288 to submit a subscription or select section 290 to cancel a subscription. Screens 278 and 284 may be formatted, for example, in a hypertext generation language (HTML) web page or any other format. In addition, the screen may include any configuration of content and sections, possibly including text, graphics, photographs, various colors or multimedia information, to provide a user friendly or visually appealing interface for the subscriber. The screen may also include a toolbar 280 that provides, for example, a conventional browser function.

Table 14 provides an example of a subscriber program in the C ++ programming language.

Payload inspection and content-based routing through channels

13 illustrates a flow chart of payload inspection and content-based routing method 300 over a channel. The method 300 may be implemented, for example, in an execution software module by the processor 93 in the intelligent router 92, which is represented by a filtering daemon 212. Alternatively, the method 300 can be implemented in a single ASIC or a combination of hardware and software. The content-based routing described in method 300 may be executed in an intelligent router anywhere in the network, whether at the core or edge router of the network.

Collectively, content-based routing means examining the payload section in a packet to determine how to handle the packet. In this content-based routing method, for example, processing a list of subscriptions (for example, using a filter) in some order, comparing messages by subject and by attribute according to routing rules to determine the routing of the message, and It may include such things as performing processing in the network core. The rules may include rules that govern in-router processing or any rules related to filters. These routing decisions can then be distributed throughout the network core. Once the message format is determined using the subject represented by the channel, the intelligent router quickly locates the attributes within the message. For example, the byte position of the attributes in a message or packet of a particular channel is known.

In method 300, intelligent router 92 receives a packet for a message (step 302). The channel ID for the corresponding message in the packet is determined (step 304) and the attributes for the channel are extracted using the channel ID (step 306). In this example, the type of channel (determined by channel ID) determines the location and data type of attributes in the packet. Attributes for a channel can be stored locally or extracted remotely through a channel manager. Intelligent router 92 extracts a filter corresponding to one subscription (step 308). This filter includes one or more attribute tests, usually one attribute test group for a subscription. Intelligent router 92 applies attributes in the packet to the corresponding attribute test (s) in the filter description (step 310).

If the result of all the property test (s) in the filter description is positive (step 312), i.e. if the properties satisfy all the property test (s), then the intelligent router performs a series of methods indicated by the rules associated with the filter. do. This method may include, for example, routing the packet to the next link and / or performing some action or calculation on the content of that packet at the local router as indicated in the rule. The action or next link can be identified, for example, in a data structure specifying the corresponding subscription. If the rule is one link, it typically identifies the node of the next network to receive the packet, which may include an intelligent router, backbone router, networked equipment, or other equipment. Alternatively, the next link may be assigned or associated with the subscription in other ways.

If the result of all the attribute test (s) in the filter description is not positive (step 312), that is, if the attributes do not satisfy all the attribute test (s), the filter is declared inconsistent (step 315). The intelligent router repeats the above procedure until either all of the attribute tests in the filter technology have been completed or the first to encounter negative results, whichever comes first.

Once all attribute tests for the filter have been performed, the intelligent router determines if there is a filter remaining (step 316). If there are remaining filters, return to step 308 to extract the attribute test (s) for that filter to process the attributes for the next filter. The matching procedure continues (steps 308, 310, 312, 314, 315, and 316) until either all filter sets have been performed or the result or routing rules for all actions can be determined first. . If a packet does not satisfy any filter, it will be aborted and discarded.

Intelligent router 92 may sort the filters in any particular order. For example, you can store a filter for a subscription in a single column or routing table, as shown in Table 15, and apply attributes to the filter (attribute tests) while sweeping the filter in a straight line. Alternatively, the routing table may include a pointer or link to the filter.

Content-based routing can use one or more methods simultaneously at the same time, depending on the application and performance-enhancing heuristics, such as algorithmic exchange depending on traffic conditions. Filters for processing may be arbitrarily encrypted, translated, translated, and merged at one router in the network to perform payload section checks required for content-based routing. For example, the price> $ 3.54122 would be cut off at the price> $ 3.54. This is because issuance in applications is known not to include currency attributes with less than two decimal places. Also, for example, when a father's issuance from a foreign country first arrives at a router located in the United States, the foreign currency may be translated into US currency.

As an alternative to sweeping the filters in a straight line, the intelligent router 92 may select filters for processing according to different orders or possibly various algorithms that may improve processing speed and efficiency. Table 16 shows examples of subscriptions and corresponding links; In this example, topics are associated with a particular channel, and subscriptions to that topic can be represented by routing rules for filters. Topics may include, for example, network addresses such as Uniform Resource Locators (URLs) that identify the source of the content.

Table 15 Channel 1 join link Filter 1a Link 1a Filter 2a Link 2a … … Filter Na Link na … Channel N join link Filter 1N Link 1a Filter 2N Link 1b … … Filter NN Link 1n

Caching at Network Nodes

14 shows a flow chart of the caching method 320. The method 320 may be implemented, for example, in an execution software module by the processor 93 in the intelligent router 92, which is represented as the cache manager 218. Alternatively, the method 320 may be implemented in one ASIC or in a combination of hardware and software, either on the same or different physical device as the corresponding intelligent router. In method 320, intelligent router 92 receives a message containing data or content, a channel ID, and subjects (step 322). Intelligent router 92 marks the time with data (step 324) and caches (stores) it locally in memory 94 or secondary storage 97 (step 326). Intelligent router 92 indexes the cache data by, for example, channel ID, subjects and time stamp (step 328).

If the intelligent router 92 receives a request for data (step 330), it retrieves the cached data using the index according to the request (step 332). Intelligent router 92 forwards cache data to backbone router 95 or other routing device for ultimate transmission to the requestor or others. The method 320 can be repeated to continue cache data retrieval for data caches and requests.

15 is a diagram illustrating the cache index 336 used in the method 320. Cache index 336 receives data 338 and stores it with time stamp 340. Once data is collected, it is marked every delta t hours. Here delta t represents the time interval between marks, for example t ₂ -t ₁ . No matter how you mark time, you can use other types of indexes as an alternative.

Table 17 conceptually describes the index of cache data. Table 18 conceptually describes the data structure that stores the connection history for the cache. Table 19 shows examples of data structures used to cache data locally at network nodes including intelligent routers.

The spacing of the time marks can be fixed or varied regardless of the length. For example, data can be cached and indexed every 5 minutes. When a command for retrieving cache data (such as # .getCache) is received that specifies a time and subject, the cache manager 218 can retrieve the cache data corresponding to the request using the cache index in step 332. Determine whether there is.

Each subject or channel may include, for example, its own IP address within one multicast tree and one set of intelligent routers. Therefore, Table 18 represents the connection history between routers that can be stored locally on the user machine; If the edge router goes down, the machine can access the connection history to determine how to reconnect the upstream router for that channel when the edge router comes back on-line. The machine may also execute a get cache command, for example, to get some content pending for the subscription during the disconnected time.

Table 17 t ₁ Channel ID 1 Topic 1-n Pointer to cache data 1 t ₂ Channel ID 2 Topic 1-n Pointer to cache data 2 t _n Channel ID 4 Topic 1-n Pointer N to cache data

Table 18 Connection history time router Network address t ₁ R2 UR2 UR3 t ₂ R2 UR2 UR3 …

Table 19 Example of Cache Data Structure for an Intelligent Router Channel node

Topic node

Data node

Saved Time Grain Node

Last time grain node

This representative data structure contains the following information: One topic node contains one topic identifier, topic level, pointer to a parent channel or topic node, a file descriptor for its own directory, and a next level topic node. Pointers to hash tables and pointers to data nodes. One data node contains a pointer to its subject parent node, a file descriptor for its data directory, a circular buffer containing the data structure for the data stored on each storage device, and the head of the buffer. Tails, and locks to lock data nodes during retrieval and storage. The stored time grain node is the node representing the current data file, and the last time grain node represents the last buffer that is not yet stored in storage, but kept in memory. In this example, cache and data storage threads use the mutex of the last time grain node to prevent concurrent access to the last time grain node.

Agent processing

16 shows a flow chart of an agent method 350 for an outgoing subscription message. The method 350 may be implemented, for example, in a software module represented by the agent 128 for executing the processor 134 on the user (subscriber) machine 122. In method 350, agent 128 receives one subscription via the method described in FIGS. 11 and 12, etc. (step 352). Agent 128 creates a string that specifies a Boolean expression for the subscription (step 354) and parses the string to detect if there is an error in the subscription (step 356). If there is an error, the agent 128 may submit an error message to the user (step 360) to allow the user to correct the error and re-enter the subscription. If there is no error in the subscription (step 358), the agent 128 stores the expression in one data structure, such as the example described below (step 362). Agent 128 converts the not-equal expression in the data structure to positive form (step 364), and converts the data structure to the corresponding disjunctive normal form (DNF) structure (step 366). . Agent 128 also simplifies the AND expressions of the DNF structure to include only range filters and membership tests (step 368).

DNF is well known in its basic form, where a Boolean expression represents one or more sub-expressions, called disjuncts, as an OR, with each sub-expression testing one or more attributes. Are expressed as an AND. For example, a Boolean expression (price> = 10 AND ((symbol == "LU" OR symbol == "T")) has the equivalent DNF expression: ((price> = 10 AND symbol) == "LU") OR (price> = 10 AND symbol == "T")).

The conversion in step 364 means the conversion of the "not equal" operator (typically represented by the symbol! =) To an equivalent "positive" form, that is, a form that specifies all allowed values rather than one disallowed value. It is. This conversion is done before the creation of the DNF, because this requires that routers in this example require a positive equation. For example, the expression (price! = 80) may be converted into an equivalent positive expression (price <= 79 OR price> = 81).

In step 368, the transformation is performed after the DNF is generated, which further simplifies the resulting AND expression. This is also done to simplify the router operation in this example. In particular, the representation of multiple attribute tests for the same attribute in a single AND can be simplified to one basic "range filter," which has only one lower or upper limit, all upper and lower bounds, or the identity test. In this case, it is one value. Special types of range filters are then encrypted according to Table 22.

For example, the expression (price> = 10 AND price <= 80 AND price> = 20 AND price <= 100) can be simplified to the expression (price> = 20 AND price <= 80), which is both upper and lower bounds. This is an example of a range filter. Examples of other types after simplification are: (price> = 20) (lower limit only); (Price <= 80) (upper limit only); And (price == 50) (one value). While creating this range filter, it is possible that some subexpressions can be simplified to true or false, in which case the subexpressions can be eliminated according to the Boolean algebraic law, thus further encrypting the expressions in the message. For example, the expression (price> = 50 AND price <= 20) is simplified to false because no value for "price" can satisfy this expression. In the special case where the entire filter expression is simplified to false, the agent does not need to generate all of the messages, thus reducing unnecessary work on the router.

If the subject filter contains wildcards, agent 128 may arbitrarily change it as shown below (step 370). Wildcards, on the other hand, can change on the network than on your computer or other device. For example, the syntax of the subject filter is the only syntax that uses wildcards, and the attribute filter is the only syntax that uses Boolean expressions. Instead, implementations may use different or different forms of syntax in subject filters or attribute filters.

Agent 128 encrypts the resulting DNF representation into a message (step 372) and moves the message to an intelligent router (step 374). The encryption process involves converting a subscription into a flat message form, which means that it constitutes a string of data. This forwarding process includes forwarded routing rules resulting from subject filters and attribute filters to subscribe to one or more intelligent routers or other routing devices on the network. For example, for delivery, a subscription representation can be mapped to a typical packet structure.

The encryption process of step 372 involves arranging subscriptions for one channel in a messaging API format to propagate over one channel. Subscriptions are communicated internally, for example with # .SUBSCRIPTION. Because there are both important subject filter fields and important attribute tests, one pair of bytes is used to store the number of subject filter fields and the other pair of bytes is the number of attribute tests in this example ( the number of attribute test). For example, the fields of each subject filter are sorted consecutively in the order specified in the original subscription, and are each sorted into the 2-byte portion of the message. Wildcard fields can be sorted as described below.

In ordering an attribute test, the operand of the test is sorted at the end of the message, just as it would sort the attribute values of the notification. Prior to sorting the attribute test and operands, they are sorted in attribute order by testing for pre-set attributes in position order under separate DNFs, and then tested according to any attribute in order of name. Furthermore, tests for a set of related scalar-valued attributes under each declaration can range from one limit (left-or right-open range or equality test) or two limits (closed range between separate boundaries). Is simplified to the canonical form of the filter. The other information in the test is encrypted in two-byte pairs in the same order as the operands, for example. This two-byte pair is placed in the message immediately following the two-byte cipher sequence in the Subject Filter field. The two-byte pair constitutes one form of bit-string encryption continuation of the attribute test, which can also be used to represent other cipher forms and the two-byte pair as a matter. An example of an attribute test is provided below.

An overview of the encryption process for attribute tests is given in Table 20. Table 21 describes how to encrypt a two-byte pair, and Table 22 describes how to encrypt an operator ID (ID) of a two-byte pair.

Table 20 Encryption rules One A 0 in the D bit indicates the start of a new declaration in DNF, and a 1 in the D bit indicates an additional declaration in the current declaration. 2 A value of 1 for all of the notification attribute locations indicates the location of a predefined attribute (defined according to the notification aspect of the channel) to which the test applies. ; The operators of the test are ordered as in the example depicted in FIG. 3 A value of all 1 of the notification attribute location indicates that the test is applied to any attribute. In this case, the length of the name and the name of the attribute to which the test applies are organized by operator. 4 The bits of the operator type ID are encrypted in one of the predefined forms of the attribute. 5 The bits in the operator ID are encrypted with the operator used in the test, as defined in Table 22.

Table 21 First byte 0 One 2 3 4 5 6 7 D Notification Attribute Location Second byte 0 One 2 3 4 5 6 7 Operator type ID Operator id

Table 22 Operator Operator id Left opening range 000 Wu opening range 001 Closed range 010 Identity test 011 Positive qualification test 100 Negative qualification test 101

Since the two-byte pair for a test already points to both the operator form of the test and whether the test applies to a predefined or arbitrary property, separate sorting of multiple tests performed on any property or aspect thereof There is no need to marshall it. This design assumes that there are no more than 127 predefined attributes in the notification. Instead, this design can use more bits to encrypt attribute tests.

While the marshall convention of attribute filters like this ordered and grouped attribute tests according to DNF, subsystem elements (such as routers) could be ordered differently (perhaps in different orders) to make all attribute filter evaluations more efficient. You can choose to evaluate the test based on the local data obtained dynamically for the probability of success or failure of the test. The subscription ID field of the message is generated by the agent to change or unsubscribe the subscription under continuing requests to fully match the subscription with the agent's edge router. Is a value. In particular, a dynamic change to the attribute filter of a subscription is delivered using the message form shown in the example of FIG. 18 except that the subject is # .RESUBSCRIPTION, where the subscription ID is the subscription ID of the pre-registered changed subscription. The unsubscription is, for example, the subject is # .UNSUBSCRIPTION and is delivered using the message form of FIG. 18 through the subscription ID field, and the subscription ID is a subscription ID of a preregistered unsubscribed subscription.

The following describes an example of the conversion and encryption by the agent described above. Consider the following example of an attribute filter expression: Price> = 10 and (sign = "LU" or (volume> = 1000 and volume <= 10000)). FIG. 19 illustrates an integrated modeling language (UML) scheme 390 that describes the objects used by the agent of step 362 for storing this representation. This diagram illustrates a hierarchical relationship for specifying subscriptions that include variables, constants, or both. An object in the schematic may be an example of a filter type according to a particular implementation. Each SimpleFilter object represents the value of the attribute used to store information about the attribute test of the matching filter expression. According to the representation of FIG. 19, one OR filter 396 is connected to two end filters 392 and 400. End filter 392 includes simple filter 394 with attributes for subscription. In the same way, OR filter 396 includes simple filter 398 and end filter 400 includes simple filters 402 and 404.

For the use of this example, the attribute price, sign and volume are assumed to be predefined attributes of the connected channel, and are defined at positions 0, 1 and 2, respectively. Moreover, the aspect of the attribute is assumed to be an unsigned integer (type code 6), a character array (type code 12) and an unsigned integer (type code 6), respectively.

Next, consider a subscription that contains an example of an attribute filter expression as an attribute filter. 18 illustrates sorting subscriptions into messages. Scheme 386 shown on the left side of FIG. 18 represents the content of the actual message, while scheme 388 on the right side provides a sign for another portion of the message. The width of each diagram in this example is 4 bytes. Before sorting, the filter is transformed into an equivalent DNF. (Price> = 10 and sign = "LU") or (price> = 10 and volume> = 1000 and volume <= 10000).

The 16-bit attribute test cipher is represented as a sequence of bits, with the spacing separating it into different parts. It should be noted that the two tests for price in this example cannot be combined because they are in disjuncts, so they are separated and aligned in a range with no right border (right open area). On the other hand, two tests for volume can be combined because they are in the same area, and can be aligned together in one closed area test.

Finally, it should be noted that some fields may be characterized as "assumed." This means that the values in these fields are chosen arbitrarily for example and are generally independent of the ordered subscription. In addition, the subject filter of the subscription is arbitrarily selected as ">", which matches any subject defined by the connected channel. The examples described above and shown in FIGS. 18 and 19 are provided for illustrative purposes only, and alignment may be used for any other aspect of the subscription. Also, method 350 shows only one example of sorting subscriptions, and they can be sorted in any other way.

17 is a flowchart of an agent method 376 for incoming messages. The method 376 may be implemented by the agent 128 and the application 126, for example, on the user machine 122. In method 376 agent 128 receives a message from an intelligent router that matches the subscription (step 378). Agent 128 selects a channel according to the subscription (step 380), and calls the channel's API in the example according to the channel ID of the message (step 382). The API represents data about the subscription of the GUI or another aspect of the user machine (step 384). The processing procedure for incoming messages uses a decryption process that is the reverse of the encryption process described above, which decryption (as opposed to encryption) can be performed at a router or other network device.

Wildcard Procedure

20 is a flow chart of a wildcard method 410. This method illustrates an example of applying a set of routing rules for a filter used to replace wildcards with a representation for subscription. The method 410 may be implemented in a software module, represented by the agent 128, for example for execution by the processor 134 of the user machine 122. Instead, wildcards may be performed in the network by the processor 93 under software control of the corresponding functions included in the intelligent router 92 or the ASIC 91. Wildcards include open or variable length fields, examples of which are provided in Table 21.

In method 410, agent 128 or another device is provided with a subscription with a wildcard (step 412). The subject length of the subscription can be specified by the publisher when publishing the content. And, for example, to count the field of the subject and get its field count (length), the region subject can be preprocessed at the publisher machine.

Agent 128 counts the number of fields in the filter operator (step 414) and initializes a new rule (filter) with field length = N (step 416). Agent 128 retrieves the subfield of the subscription and determines whether the filter operator subfield O [i] is a wildcard (step 420). If the filter operator subfield is not a wildcard, the agent 128 inserts a conjunctive clause into the rule, field [i] = O [i] (step 422). If the filter operator has more subfields (step 424). Agent 128 returns to step 418 to process additional subfields. The parameter i represents the fields in this example, where "i" is an integer representing the field number.

After processing the subfield, the agent 128 determines whether the last filter operator subfield is ">" (step 426), and if so, changes the length limit to field length> N-1 (step 428). . Wildcard procedures can use any form of sign, and ">" is just an example. In this example, "a.>" Means a.b, a.c. a.d and so on, and all subtopics at all levels (eg a.b.x, a.c.x, a.b.x.y, etc.). Other symbols may be used in other implementations of wildcards.

If necessary, agent 128 forwards the forwarded rule to an intelligent router or device on another network (step 430). Thus, the method is repeated for subfields to process subfields to convert wildcards to non-wild rules (meaning rules that do not include wildcards). The conversion of wildcards can happen anywhere on the network, for example on the subscriber's machine or intelligent router. Thus, a transformation occurs in one entity, and the transformed rule can be passed to another entity, which can be done dynamically.

Table 23 summarizes examples with examples of routing rules for handling wildcards. Such routing rules can be generated, for example, by intelligent routers or other network entities and propagated to intelligent routers. In addition, the routing rules in Table 23 are for illustrative purposes only and other routing rules for converting wildcards are possible.

Table 23

Alarm service

The intelligent content based routing described above can also be used for other devices, one of which is the Digital Video Surveillance System (DVSS). For example, a user, such as a law enforcement or security agency, subscribes to video clips from a camera at a particular location. The camera can capture digital video clips, process video clips upon subscription in the network core and send these clips over a network such as the Internet with content-based routing. Thus, the user receives the corresponding video clip and their filtering is distributed over the network. In addition to video clips, any other type of content may be distributed to provide for any type of alert including, for example, security breach, fire and fraud arrest.

As another example, a particular camera may include an associated motion sensor. Upon motion detection, the motion sensor triggers the camera to send video clips captured simultaneously to the network using content-based routing to route the video clips to subscribers.

Thus, the content-based routing described above can significantly reduce the network burden in processing and routing video clips. For example, video signals generated by all Charge Coupled Devices (CCDs) can be stored in four different destinations by a Digital Video Recorder (DVR), namely, local storage managed by a DVR, global storage attached to a network, and a DVSS system. This needs to be recorded on the iDSS management server. Considering the network bandwidth required to carry such large data volumes, the total amount of CCDs or DVRs managed by iDSS does not meet the capacity requirements of consumers. As a result, the required bandwidth is limited, for example, using techniques for medium or large consumers. FIG. 21 shows an overall architecture diagram of one surveillance system in which each DVR manages four or sixteen CCDs.

Architecture Overview :

FIG. 22 illustrates two enhancements based primarily on the techniques described above, in order to improve the capacity of the surveillance system shown in FIG. 21. As shown in FIG. 22, the first enhancement focuses on a method of reducing DVR backbone traffic, and the second enhancement provides content-based routing functions such as those described above to increase data transfer efficiency. Use the device referred to as z-box.

Local traffic reduction for the DVR backbone :

Inefficiencies in data distribution schemes cause serious scalability problems. That is, because the image file generated by the DVR is delivered to another box using a TCP based protocol, the bandwidth consumption increases linearly with the number of devices attached to the local area network (LAN). In one aspect of iDSS, the same streaming video data needs to be sent to each DVSS, which is networked storage (SAN or NAS), iDSS monitor, and remote monitoring software.

One approach to solving this problem is for each DVR to issue only one data stream on the LAN and allow other network attached devices to receive the same data stream as a result of the subscription. Thus, if the DVR's output rate is 10 megabits per second (Mbps), to have three subscribing devices on the same network requires only 10Mbps, not 30Mbps, from the network.

To achieve this goal, the above-described publish-subscribe event communication API can be used on any DVR box and any device using DVR data (eg, iDSS, global storage). The API is simple but efficient, which can take advantage of IP multicasting and recovery protocols. The API can follow the publish-subscribe model described above, so that other implementations do not need to change the code, but simply relink with the full version of the library providing the API.

Proxy for DVSS :

Each DVSS can make one connection (TCP-based) with the DVR box to receive streaming video data. Scalability presents the same issue as described above.

Referring to FIG. 22, this approach may be described as two stages, for example. In the first stage, Stage 1 on the LAN side, a proxy server (eg, z-box 1) may be provided to manipulate all DVSS outgoing data (ie, data going from the DVR to DVSS). This proxy server subscribes to all DVR data for the LAN and publishes this data on an external network (eg, the Internet). DVSS subscribes to this data. Thus, the proxy server, z-box 1, is a subscriber agent (e.g., agent 128) that collects data from the DVR, and a publisher agent that publishes such data through a publish-subscribe network, such as the publish-subscribe network described above. For example, agent 36 is provided.

Although traffic at stage 1 can be greatly reduced on the LAN side, the traffic is particularly outgoing in any country, when a typical asymmetric digital subscriber line (ADSL) has only 64 kilobits per second (kbps) uplink rate. Continue to jam the link.

With continued reference to FIG. 22, stage 2 preferably involves leasing or acquiring a connection in the service provider's machine room and locating a second z-box device, such as z-box 2. For example, a z-box device can be placed on a Hi-Net backbone. A single connection (tunnel) from such a device to z-box 2 can be established at the consumer premise.

In this case, z box 2 at the consumer facility acts as a subscriber agent (eg, agent 128). Z-box 2 also acts as a routing daemon (eg, routing daemon 216). As a subscriber agent, z-box 2 (eg, in the Hi-Net machine room) preferably subscribes to the DVR publishing through z-box 1. Between z-box 1 and z-box 2 there is a publish-subscribe network as described above. Accordingly, z-box 1 publishes the video from the DVR and subscribes to the video required by the DVSS. In this way, the data delivery efficiency of the alert service is increased using the event notification system described herein. The z-boxes (eg z-box 1 and z-box 2) preferably comprise modules for publishing and subscribing via such a publish-subscribe network as described above.

Digital content delivery

The intelligent content-based routing described above can be used in a large number of implementations, including routing video, music, and software updates through subscriptions. For example, a user can subscribe to software updates, such as anti-virus software, and have updates that are automatically routed to the user. As another example, a user may subscribe to specific video and music content and also have such subscription content automatically routed to the user. Video and music can be received, for example, when streaming digital content. In addition, distribution processing at the network core substantially reduces the processing burden on servers providing software, video and music content. Thus, network bandwidth can be efficiently increased using the same network infrastructure to provide content, among other benefits.

One particular architecture that implements such routing is shown in FIG. Note that this architecture preferably assumes two levels of cache servers C1 and C2 that reside in the co-location office of the network service provider. However, this can only be achieved when the C1 cache server is available. The terms C1 and C2 cache servers refer to servers providing distributed network caching as described above (see FIGS. 14-15 and related description). The architecture is deployed in two states, for example. A first state that assumes no C2 cache server exists is to reduce server load and the time required to transfer large media files using a fast file transfer mechanism between central distributor 450 and C1 cache server. This fast file transfer mechanism is preferably achieved by adding a routing box (470 in FIG. 23) between the central distributor 450 and the Cl cache server. The second state is to add a routing box at the C2 cache server and the aforementioned subscription mechanism between the user (eg, user machine 460) and the C2 cache server.

Advantages of using a routing box :

The routing box 470 preferably includes a module for implementing the content-based routing described above (eg, the intelligent router 92 described above). There are two main advantages to using the routing box 470 that implements the content-based routing described above. Rapid routing and file transfer solutions utilizing these routing boxes 470 accelerate file transfers up to five times over conventional file transfer protocols such as FTP or RCP. Efficient multicast over a WAN can also be achieved. When data is sent from a central location to a group of receivers, the routing solution uses network multicast topologies and accelerates content delivery by configuring multicast tunnels over the WAN, reducing server load and network bandwidth requirements.

Architecture

Media content is delivered from the central distributor to the Cl cache server. The C1 cache stores all content files. Each C1 cache server, for example, requires terabytes of disk space to store all content. A user (eg, using a user machine 460, such as subscriber machine 122) requests content from a C2 cache server that stores only a portion of the content. C2 cache servers, for example, require hundreds of gigabytes of disk space.

File transfer between user and C2 cache :

When user 460 requests a media file by issuing a subscription, this request is handled by one of the C2 cache servers. If the requested media file is already cached on the C2 server, the file is delivered immediately. If not, the subscription is sent to the C1 cache server and sent from the C1 cache server to the C2 cache server.

Precaching media data from C1 cache to C2 cache :

Based on the user subscription or the pattern of subscription, the media file is precached from the C1 cache server to the C2 cache server. For example, if the user 460 connecting to the C2 cache server is primarily interested in pop songs, the C1 cache server may push new pop songs to the C2 cache server even before any user 460 on the C2 cache server requests a song. Can be.

Implementation state :

The first state involves, for example, installing a fast file transfer mechanism with content routing between distributor 450 and the C1 cache server. No C2 cache server is required. In this case, all users 460 are directly connected to the C1 cache. The C1 cache server regularly receives new media files from the distributor 450. State-1 architecture is shown in FIG.

In FIG. 24, the distributor 450 sends the new media file only once to the routing box 470 enhanced by the intelligent content-based routing technique described above. Thus, the load on dispenser 450 is reduced. The routing box 470 transfers the file to each C1 cache server using a fast file transfer mechanism. In this case, no additional routing box is required at the receiver 460 end. Alternatively, other types of servers may be used for the C1 cache server.

Referring to FIG. 25, an architecture of one embodiment for implementing state 2 is shown. State 2 in this example preferably uses a kernel implementation routing box 470 for routing and transmitting data. Kernel layer solutions further reduce the overhead of file transfers because they require less buffer copying and context switching time. The state 2 solution also adds a C2 cache server to the architecture as shown in FIG. As such, as shown, routing box 470 is preferably added to the C2 site using a common location in the service provider network. This potentially reduces bandwidth requirements significantly with hundreds of times the bandwidth reduction.

As shown in FIG. 25, a file transferred between a C1 cache server and a C2 cache server is passed through routing boxes associated with a routing box 470 associated with a C1 cache server and a routing box 470 associated with a C2 cache server. In this way, a fast routing and file transfer solution between C1 and C2 cache servers is achieved using these routing boxes 470.

Quality of Service Management

The aforementioned intelligent content based routing may be used for content routing with specific delivery guarantees, for example. For example, based on a service level agreement (SLA), an ISP or content provider may have a bandwidth to guarantee quality of service (QoS). This can be efficiently achieved by the content-based intelligent routing described above.

Architecture :

There are at least two possible configurations for guaranteeing QoS in content delivery. The first configuration connects a large number of links to one or more telephone company (TELCO) networks. The second configuration uses only one link to the TELCO network. In the example shown in FIG. 26, there are two layers of routing boxes (R-boxes). R-box 1 routes packets to R-box 2 and R-box 3 based on the contents of the data packets. R-Box 2 and R-Box 3 route data packets to other network links (eg, L1-L4), each linking to a TELCO network. To retain the bandwidth for premium consumers, data packets generated for the top SLA consumers are routed to the link with the top bandwidth (top priority) to ensure specific QoS for those consumers.

As an example shown in FIG. 27, R-box 1 routes data packets to R-box 2 and R-box 3. R-Box 2 and R-Box 3 connect to R-Box 4, which routes data packets to other communication links. R-Box 4 picks up data packets from four links based on the QoS level of each link. R-box 4 then sends a data packet to the Internet ISP via a network link (eg, L5). By implementing various algorithms for picking up data on each link, the system can dynamically allocate bandwidth for each link for better QoS management than multiple link configuration.

Technology :

QoS guarantees can leverage the intelligent, distributed content-based routing techniques described above. Each packet to be routed is tagged for content based routing. The solution does, among other possible advantages, develop QoS for economically affordable ASP / content providers.

Advantages :

Solutions can be provided to Internet service providers (eg IDCs) or content providers (eg media on demand) to retain bandwidth based on their SLAs for different consumers.

Real time alert :

Alerts can have different priorities. For example, security and fire alerts may be given a top priority and news alerts may be given a lower priority. Without QoS routing, the top priority alerts will not be able to reach their subscribers in real time because the ASP's network bandwidth may be occupied by low priority alerts and communications. This solution prevents this from happening. In addition, alerts may be sent to each consumer based on the SLA. Premium consumers pay more, and more bandwidth is allocated to them.

Real time data delivery :

In some applications, such as voice on demand (VOD), MOD, or voice over IP (VoIP), bandwidth availability affects the quality of the application. This solution can route data packets based on the message type by examining the contents of the packet as described above. In bandwidth sensitive applications, these data packets can be routed to higher priority links. Data packets can be routed to multiple subscribers based on their SLA level as well as their message type. Higher SLA consumer packets can be routed to higher priority links using this solution.

Software or anti-virus updates can take advantage of this solution. For example, antivirus files are routed to the top priority link to ensure antivirus updates, and audio driver files are routed to the lower priority link.

Content based filtering :

Using the co-location service and placing the R-box in the TELCO network, the system can perform filtering and dynamic caching outside the ISP as shown in FIG. R-boxes in TELCO can be used to filter data based on the content filtering techniques described above to reduce traffic to IDC / ISP networks. It can be used to block hacker attacks such as DOS attacks or unauthorized data access. By examining the required content, the R-box can be a cache box for static and dynamic web data. The benefits of such a solution include, for example, security, reduced network bandwidth between TELCO and ISP, and reduced load on the ISP server.

Caching of optional multicasting

Message persistence is the ability to store a message and later retrieve it. Many specific applications, such as e-mail, generally require great message persistence for messages going through the network. Under ideal conditions, unless there is a network failure, always-connected subscribers should not exceed any persistence required for these particular applications. In practice, however, a message may be due to a number of reasons, such as (1) a failure or buffer overflow occurring in the network or on the user's side, or (2) the user makes an implicit disconnect from the network and reconnects after a period of time. Thus, it may be "lost" while traveling over the network.

The persistence model of the event notification system described above is divided into two levels: short-term and long-lived. Short term persistence is designed to recover from packet loss due to network congestion or short link failure. Long-term persistence is designed to recover from other failures, including, for example, loss of user connections or ISP network failures, user machine failures, long-term network failures, and / or other failures. Examples of these two schemes are described below.

Short-term persistence: data retransmission and flow control

In a data network, the cause of data loss can simply be classified as link failure and buffer overflow. In order to provide a reliable channel for the event notification system, this issue needs to be addressed. For link failures, it is possible to have some forward error correction (FEC) schemes to correct some errors caused by link failures. However, it is still necessary to provide a scheme to recover packets in case the error is so severe that the FEC scheme cannot correct it. For buffer overflow, it is necessary to prevent the buffer flow from occurring. Flow control schemes are typically used in data networks to avoid this problem.

In a short term persistence scheme, a Transmission Control Protocol (TCP) tunnel is preferably used to connect event routers (eg, intelligent routers 12) hop-by-hop. The reasons for relying on reliable layer-2 tunnels instead of using reliable transport protocols (eg RMTP) vary. In the short term persistence scheme of the event notification system, if the message does not meet the filter rules, the message may be preferably filtered by the router. As a result, the receiving router cannot generally detect the loss of a packet using a scheme such as the source sequence number. Similarly, it is not desirable for every receiving router to acknowledge each packet it receives because it would cause an overload of acknowledgment (ie, ACK-explosion). In addition, to avoid buffer overflows, the short-term persistence model implements a flow control scheme so that routers can request neighboring routers to deliver messages to them before they run out of buffer space. These schemes are covered by TCP.

TCP Transmission Policy : In TCP, which is used for short term persistence schemes, the transmission window is preferably used locally for the data transmitter to track the retransmitted data. The purpose of the transmission window is twofold. First, the transmission window ensures that the transmitter clearly knows that the data has been correctly received by the receiver, and secondly, allows the transmission window to better use the channel capacity. In TCP, each byte sent by the transmitter is required to be identified implicitly or explicitly. The transmission window helps the transmitter keep track of the transmitted and confirmed data. The transmission window also improves channel utilization since it allows the transmitter to transmit data within the transmission window without waiting for the transmitter to stop and acknowledge previous packets. Once the previous data has been verified, the window automatically advances.

Receiver windows are also managed in TCP. The receiver window is preferably used to indicate the buffer space available at the data receiver end. The available buffer space value is transmitted to the transmitter so that the transmitter knows how to avoid overflow of the buffer at the receiver side.

TCP congestion control : Because TCP is designed as an end-to-end transport protocol, TCP used in short-term persistence schemes also resolves buffer overflows inside publish-subscribe networks. . To solve this, TCP used in the short term persistence model preferably uses a third window, i.e. a congestion window. The congestion window is used by the transmitter to estimate the maximum buffer space on routers along the path. In other words, the congestion window size is reduced when the transmitter detects a packet loss and vice versa.

Long-term persistence: cache for persistent channels

The channel (eg, described above) can be persistent or real time. Real-time channels generally transmit data that is useful only in real time and does not have any application-specific persistence requirements. The persistent channel stores data traversing over the network during the duration frame T. In other words, the persistence during the sustain channel is guaranteed during the time frame T. This persistence of data is achieved through: For example, the cache of data at each edge node for the duration of the channel, the retrieval of data from the cache transparent to the user under fault conditions, the user explicitly retrieving the data from the cache, protects against router failures By establishing a reliable tunnel between the networks, the flow of data through the network is continued, and the channel components are protected against failures through replication.

Therefore, as will be described below, the long-term persistence scheme is preferably used when the subscriber registered with the persistent channel collides and returns back within the time frame T for the persistent channel, where the subscriber has a final " X " time frame (X < T). While retrieving cached old data from the network.

In a long term persistence scheme, the subscriber application (eg, application 126) preferably explicitly pulls data (eg, a message) from the relevant subscriber agent (eg, agent 128). can do. As mentioned above, an agent may use a proxy or be implemented as a proxy. After the agent or proxy has recovered from a network failure, the agent preferably retrieves data transparently from the cache for a period of time disconnected from the edge router. In addition, the subscriber is preferably allowed to access only data up to the last T timeframe in the long term persistence scheme. For this purpose, it is desirable to determine the time for the edge router to which the agent (or proxy) is connected. Preferably, the retrieved cache data is sent out of band and does not need to guarantee real time. Embodiments of the long-term persistence scheme are aimed at existing subscribers whose connections have been broken (crashes and comes back up again) or lost connection with the edge router after the connection with the edge router (eg, edge router 16) has been interrupted. . New subscribers may not be able to obtain cached information.

Definition of persistence : Timed persistence (timeframe T) for a subscriber is defined as the ability to retrieve data of the last timeframe T from the publish-subscribe network. If the subscriber leaves the network, the data of the persistent channel received in the absence of the subscriber remains in the network for a timeframe T [from the receipt of the data]. If the subscriber returns during the timeframe T, no data is lost. However, if the subscriber returns between the T and 2T timeframes, the data will be lost. Also, if the subscriber returns after a 2T timeframe, it is desirable not to guarantee access to previous data.

In this definition, the publish-subscribe network tree formed on the subscriber side is timeframe T after the subscriber's departure so that new data received during timeframe T after the subscriber leaves can be maintained until the expiration time of timeframe T is reached. It is required to be able to retain it for a while and then remove it.

Architecture : FIG. 29 is a block diagram illustrating some components of a publish-subscribe network that provides persistence through caching. The network includes a core routing node 548 and an edge routing node 545 as shown. These routing nodes preferably have an intelligent router 92 (shown with the edge routing node) and a conventional backbone router (not shown) as described in FIG. Intelligent router 92, which wishes to perform caching for persistent channels, preferably includes cache manager 218 co-located as shown in FIG. The cache manager 218 has already been described with reference to FIG. 8. Intelligent router 92 is preferably responsible for the short term persistence of retrieving lost data or recovering from a router failure. The cache manager 218 caches the data to provide the long term persistence of the channel. The cache manager 218 preferably caches this data in the cache 540. The cache 540 preferably includes a memory and a disk (not shown).

On behalf of the intelligent router 92, having the cache manager 218 cache the data for long-term persistence, computationally intensive operations of indexing the cached data can be performed on a separate processor, thereby allowing routing and The performance of the filtering processor is unaffected and disk I / O operations can be performed by another processor that regularly moves cached data to disk, eliminating cycles for routing and filtering, and allowing edge routers to There is no need to devote to performing I / O operations.

An agent 128 is shown in FIG. 29, which is preferably present in the subscriber machine 122 (not shown in FIG. 29) as already described in FIG. 5. Agent 128 communicates with cache manager 218 to retrieve data from cache 540 and receives retrieved data to organize the retrieved data. As discussed above, the agent 128 may use or be implemented as a proxy.

In the absence of a failure, the cache manager 218 is connected only to the edge router node 545. Although not shown in FIG. 29, the long-term persistence scheme is considered for failure, so the upstream core routing node 548 of the first rank from the edge routing node 545 preferably includes a cache manager 218 that stores data, respectively. Do. Upstream is the direction away from agent 128 (ie, subscriber machine 122). The upstream core routing node of the first rank refers to the routing node immediately upstream of the edge routing node 545. The publish-subscribe network often includes a plurality of first rank upstream core routing nodes, but FIG. 29 illustrates one first rank upstream core routing node, namely core routing node 548. As mentioned above, cache manager 218 provides local caching for data at the network node where it is located. Thus, for example, distributed caching of data throughout the network code is realized by the operation of the cache manager 218 located at various core routing nodes, including the core routing node 548. This distributed caching provides a backup for caching at edge routing node 545.

30 illustrates backup caching at an upstream router (eg, core routing node 548). In the long term persistence scheme, each cache is preferably backed up by the cache of the next upstream router. The upstream cache stores all incoming data and acts as a backup for all downstream downstream edge router caches. The data in the upstream cache is preferably stored according to the same mechanism as the edge router cache.

Referring now to FIG. 31, an architecture for caching persistent channels preferably provides the ability to span across four different modules. Four other modules include:

Cache manager 218-preferably a server process responsible for storing data passing through intelligent router 92;

Router cache API 552—preferably creating and destroying a library, such as a cache, which is responsible for all control plane accesses from intelligent router 92 to cache manager 218;

Agent (or proxy) cache API 554—preferably, retrieves a library, such as data, that is responsible for all control plane accesses from agent 128 (or agent 128 proxy) to cache manager 218; And

Agent 128 (or proxy) —preferably in charge of collecting and organizing the data retrieved from cache 546.

31 illustrates the interaction of these four modules. Both agents 128 and intelligent routers 92 preferably access the cache through cache API libraries 552 and 554. Cache API libraries 552 and 554 provide APIs for initializing to cache 546, creating and destroying caches for a subject, retrieving cache addresses, and most importantly retrieving data from cache 546. . The routing daemon 216 preferably sends data to the cache manager 218 via a data path that does not pass through the cache API 552. Cache APIs 552 and 554 preferably use a control path for all control messages, including data retrieval.

Cache Manager-Cache Management: Referring to FIG. 32, when the cache manager 218 encounters a new channel, the cache manager 218 may acquire an information server (eg, the aforementioned servers) to obtain a channel manager 150 for the channel. (152, 154, and / or 156)). Once cache manager 218 obtains the address of channel manager 150, cache manager 218 preferably retrieves channel characteristics from channel manager 150. The channel characteristics preferably include, for example, channel subject tree and attributes, the permanent characteristics of the channel, the permanent time frame T of the channel, the granularity of the cache, and the like. Before the cache manager 218 can begin to cache data flow through a channel of a given subject, that subject's cache needs to be created in the cache manager 218. The cache manager 218 waits for a cache generation message and then generates a subject cache in response to this message. This subject cache can then be destroyed, suspended, or resumed upon request. 32 illustrates cache generation according to a subscription.

Cache Manager-Cache Data Input :

The cache manager 218 preferably accesses data entering the intelligent router 92 in a number of ways. For example, an IP like solution in which all data on the incoming link of intelligent router 92 is also passed to cache manager 218; Using a sniffing mechanism (where the cache manager 218 pays attention to all packets moving on the network of intelligent router 92); After filtering, the intelligent router 92 forwards each message to the cache 554 that requires propagation to one or more links; The cache manager 218 behaves like a subscriber to all data entering the intelligent router 92.

Cache Manager-Cache Data Storage : Referring to FIG. 33, cache manager 218 can be configured in a number of ways, eg, channel id, subject, publisher id, time stamp, time grains (G), primary caching. The data in cache 546 is indexed using a primary cachingg attribute, a link (in the special case where caching is performed on failures), or other means. Data is indexed and stored in a hierarchical directory structure in the file system or in memory. Data is cached in memory and then periodically moved to disk. Caching in memory is only for the duration of the "G" time grain. After the time G expires, all data related to a particular branch in the tree is preferably moved under that branch to a file that overwrites the earliest file for that branch. (G is not implemented as a sliding window, but is preferably implemented as an absolute window, which results in an increase in cost if each message is written to the disk individually. This is because recording the whole is more efficient.) Fig. 33 is a diagram showing a typical indexing tree. When caching data for persistence, the first indexing tree of FIG. 33 is preferably used.

With continued reference to FIG. 33, subjects are preferably stored in a hierarchy, where "a" is a parent of subjects such as "ab", "ac" "ad", etc., cache manager 218 is the subject of all subjects. It is desirable to maintain a hash table for the cache 546 that maps them to their corresponding file locations. In some cases, the cache 546 detects that the upstream router (eg, core routing node 548) has detected a failure of a downstream router (eg, edge routing node 545) on one of its links. It may be required to store data under fault conditions. The first approach to recovery is to restart the downstream router (which may take several minutes). If the downstream router is restarting, the upstream router will need to cache the data being passed down the link. Such a cache (eg, the so-called FM Cache in FIG. 33) is preferably indexed on outgoing links.

Cache Manager-Garbage Collection : If the channel is not persistent, the cache 546 immediately releases the data without storing it. If the channel is persistent, cache 546 will store the data. The duration frame "T" for a particular channel is divided into N time grains of size G, respectively. Caching of memory is only for the period of G. After the Cache Manager determines that the time interval G has passed, it moves the data to disk. Cache manager 218 stores the data on disk for the duration of the sustained time frame interval T.

Data corresponding to the time interval G is deleted from the disc once the time is greater than the continuous timeout T for the upper limit of the channel + interval. To better understand this, assume that the channel has a T of 2 hours. As an example, cache manager 218 uses a time granularity G of 15 minutes. In order to delete data from the disk, a policy preferably used is that if the last data cached for a time interval G (15 minutes) was stored for T (2 hours), the entire cached data during that 15 minute interval would be discarded. It is. In this example, the data cached during each 15 minute interval is a block of data. If the persistent time frame T is divided into N intervals, there will be N + 1 blocks of data in cache 546 (N on disk and one in memory) for each subject at any point in time.

Cache Manager-Cache Data Retrieval : Referring now to FIG. 34, agent 128 (or proxy) preferably invokes a GetCache operation to cause data to return from the current time to time "T". The cache manager 218 to which the agent 128 connects to invoke the GetCache operation is labeled Portal Cache in FIG. 34. Due to the failure / disconnection of the router or agent 128, the portal cache may not have all the data requested by the agent 128. In this case, the portal cache is responsible for retrieving data from all other caches (eg, upstream caches), collating the data and returning it to the agent 128. 34 shows a search from multiple caches A, B and C for different time stamps TS1, TS2 and TS3.

Cache manager 218 may preferably retrieve only data of blocks of time unit G. So agent 128 may get more data than it expects or requests. Also, during retrieval from multiple caches, there may be some overlapping gaps between caches, so agent 128 will see a copy of the data, and agent 128 will copy against the data stream provided by the cache. It must be restrained.

Interaction with Cache Manager and Other Modules : Cache manager 218 preferably interacts with several modules of the event notification system infrastructure, as shown in FIG. When the cache manager 218 encounters a new channel (at the creation cache time), it preferably calls the information server 550 to obtain the channel manager 150 for that channel. Once cache manager 218 has the address of channel manager 150, cache manager 218 preferably obtains channel characteristics from channel manager 150. Manager module 552 is preferably allowed to set / change some properties, such as units of caching. The manager module 552 is preferably also allowed to manually create or delete the channel cache.

Agent Cache API-Application-Agent Interaction : The application (e.g., application 216) preferably calls the agent cache API 554 to obtain a cache 546 with a given subject and filter. Preferably, the application can only retrieve data from cache 546 if it has already subscribed to that data. Agent cache API 554 preferably provides practically two APIs.

The first API allows non-subscribed applications to simultaneously subscribe and retrieve cache. If the "fifo" flag is set, a subscription is created and sent to the border router node 545. However, the subscription preferably enters the "pause" mode immediately. After agent 128 has received all cached data, agent 128 first passes all cached data, remembers the last sequence not shown for all publishers of the data, and then each Pass paused data from the final sequence not shown for the publishers of the.

In the second API, it is assumed that the application has already subscribed to some data and is requesting cache data. In this case, some data has already been passed that cannot be listed in order for the cache data. Therefore, the "fifo" flag in this case only indicates that the data retrieved from the cache 546 must be listed in sequence within itself, and not necessarily over a regular data stream.

Agent 128 preferably retrieves all events of one large block of data. After retrieving the data from the cache API 554, the agent 128 preferably needs to perform the following operations on the data before invoking the callback operation (see above): creating a notification from the notification list; Remember and filter the final sequence number for each issuer. When agent 128 pushes all events into the callback, it preferably sends a DoneCache event to the callback, indicating that all cached data has been delivered. In this regard, if the subscription is a FIFO and the regular data is paused, the agent 128 preferably sends all paused notifications. Agent 128 only delivers notifications whose sequence numbers are greater than the final sequence number of the cache data.

Agent Cache API vs. Cache Interaction : In the case where a subscriber requests cached data, the cache API of the agent 128 endpoint 554 preferably first looks up the history of the border routers to which the agent 128 was connected and obtains the GetCache Filter the list using the time interval provided in the request. API 554 then sends a GetCache (channel, subject, filter, local_pubs, time_period, fifo, array of routers) message to the last boundary cache to which it is connected. Cache manager 218 preferably retrieves data based on channel id, subject, and timestamp, and returns the data to agent 128. When the cache manager 218 has finished pushing data, it sends a DoneCache event to the Cache-API to indicate that the data transfer is complete.

If the cache manager 218 does not find the data locally, the cache manager 218 uses the "list of routers" provided by the agent 128 to place the necessary data. Once the cache manager 218 has collected all the necessary data, the cache manager 218 collates the necessary data and performs copy suppression on it before sending it to the agent 128.

Cache Connection History : In order to be able to retrieve data from cache 546, it is desirable that cache connection history be maintained at agent 128 for both the upstream cache as well as the edge. Since this information is needed over agent 128 shutdown and crash, this information must be kept in a file continuously. The cache connection history on disk is preferably stored in the following files and formats.

Edge Cache Locations: The location of the edge cache (eg, cache 546 at the edge routing node 546) is preferably obtained from the channel manager / channel library. This occurs at boot time and at any subsequent time the edge cache changes, i.e. the time of connection loss / recovery, the time the connection is moved. The dispatcher notifies the agent 128 of any changes in the edge cache connection and these changes are then passed to the agent 128 cache library. Whenever a change occurs, the change is maintained.

Persistent storage: CACHE_ROOT / channel_id / Channel-exemplary path for cached data.

The data is preferably stored in the following format.

Number of Edge Caches;

Edge Cache1: Number of time intervals, StartTime1: EndTime1, StartTime: EndTime2, ...; And

Edge Cache2: Number of time intervals, StartTime1: EndTime1, StartTime: EndTime2, ...

The most recent timestamp is at the beginning of the list. Note that two different edge caches do not have overlapping intervals (because agent 128 is only connected to one edge cache at a time). Each time a new entry is added, the previous entries are checked to see if they are still valid; If it is invalid, the entry is discarded. The time interval becomes invalid in the following cases.

Interval EndTime + channel's persistent timeout <current time

If all intervals of an entry become invalid, the edge cache entry becomes invalid. Note that "EndTime" of zero means that the interval is currently active.

Upstream Cache Locations: The location of the upstream cache (eg, cache 546 in core routing node 548) depends on the subject. Since each subject has its own multicast tree, the first level of upstream cache set is a function of the subject. When a user subscribes to a topic, it is desirable for the intelligent router 29 to return a list of upstream caches associated with that topic. Likewise, any change in upstream cache locations due to failure or reorganization in the multicast tree is preferably communicated to the agent 128 via the control channel. These changes are documented locally in the permanent storage store (file).

Persistent storage: CACHE_ROOT / channel_identifier / subject-example path for cached data.                 

The data is preferably stored in the following format.

Number of Upstream Caches;

Upstream Cache1: Number of time intervals, StartTime1: EndTime1, StartTime2: EndTime2, ...; And

Upstream Cache2: Number of time intervals, StartTime1: EndTime1, StartTime2: EndTime2, ...

Again, the most recent timestamp is at the beginning of the list. Unlike the edge cache interval, two upstream caches can have overlapping intervals, because agent 128 can have multiple upstream caches for a given subject. In addition, the contents of the upstream cache file are waste collected using the same algorithm as in the edge cache.

Cache Validity During Data Retrieval : During the lifetime of agent 128, the agent experiences connection with different edge routers and upstream routers. Agent cache API 554 preferably stores this connection history in a local store. If agent 128 needs to retrieve the last T data intervals from cache 546, agent cache API 554 preferably examines the connection history to determine the cache to access the data. A good algorithm to use for this is as follows: 1) The cache library examines all edge cache intervals and checks intervals that are within the T timeframe. If the interval is in the time frame, it is added to the list L _e of valid edge caches. 2) The list L _e is stored using the interval start time. 3) For each interval not covered by the edge caches in L _e , examine the upstream cache to get all upstream cache intervals that may include this interval and add valid intervals to the list L _u . Create L by adding L _u to L _e and aligning L _e using the interval start time.

This algorithm provides a list L of caches and a time interval for retrieving data for each cache. The list L of these caches is then marshalled into a get cache message and sent to the cache manager 218. On the cache manager 218 side, the cache manager 218 preferably 5) un-marshalls the cache intervals from the acquired cache message and regenerates the sorted list L in increasing order of start time. For each interval in the list L, the cache manager 218 checks 6) to see if there is an interval between the previous interval and the current interval, and if there is an interval, it is desirable to request data from the local cache. If there is no gap, the cache manager 218 preferably 7) prompts the appropriate cache to acquire the data. Cache manager 218 preferably 8) collates data from all caches and sends it to agent 128.

Router Cache API : The router cache API 552 in the intelligent router 92 functions to call the cache manager 218 to create, destroy, suspend and resume caching for a particular subject. The router cache API 552 also handles the initial configuration, by uploading the cache address from the intelligent router 92 to the channel manager 150, so that the agent 128 side (agent cache API 554), if necessary, can do so. Information is retrieved, and the location of the caches 546 for other routers is retrieved (this is the case for example when the subscription response and after the subject tree has changed, the intelligent router 92 caches an upstream cache for a given topic). Is used when it wants to notify the agent 128).

Use of Cache for Pulling : The discussion above focuses on using the cache to implement persistent channels and for returning subscribers to obtain data from the network. Another embodiment may be for any subscriber (new or return) to cache any kind of data (e.g., including data that is not already subscribed to a subscriber but is in cache 546 because of someone else's subscription). 546). The difference between this embodiment and the preceding embodiment is that the data is now guaranteed for the returning subscriber and the location of the data is known but the location of the stored data is not known for the new subscriber. A simple way to implement this alternative embodiment is to issue a "FindCache" request on the channel. The "FindCache" request includes the channel id, subject, filter, time interval and location of the agent 128 searching the cache 546 with the requested cache data. All caches 546 receive a "FindCache" request. When each cache 546 receives a request, the cache 546 checks whether the corresponding data is in its data store, and then sends its own location back in a unicast message. Agent 128 selects one of caches 546 and invokes a GetCache operation on it to obtain data.

Final data pull : Another embodiment includes a final data pool, a feature that allows a subscriber application (eg, application 126) to obtain a final message for a given subject. This is useful for data such as stock quote alerts, and the user wants to know the final stock price, not history.

Implementation of the cache manager : For example, the cache manager 218 implementation preferably has three types of threads. That is, a data caching thread-the data caching thread preferably picks up data from the connection to the intelligent router 92 and indexes the data and stores it in memory-the data storage thread-upon reaching the end of the time interval, the data storage thread is preferably To move the data stored in memory to disk and to perform a garbage collection of expired data in the process as well. The data retrieval thread The data retrieval thread preferably picks up requests for cache data and 546) responsible for retrieving data from the data. These three types of threads can be implemented as a single thread or as a pool of threads. Preferably, the data caching thread and the data storage thread are synchronized while data is being moved to disk. Synchronization between the data storage thread and the data retrieval thread prevents data from being removed while the data is being retrieved.

Data Structures : Examples of data structures for caching are provided in Table 19 above and the accompanying description.

Data Storage : FIG. 36 illustrates a preferred directory structure used to store data files in a cache 546 named "Aquila Cache." Each subject level directory preferably has a set of child subject directories as well as a data directory that stores data published for that subject. For example, data published for Fox.Movies on the entertainment channel is delivered to files in the directory AquilaCache / Entertainment / Fox / Movies / Data and data published for the subject Fox is sent to files in the directory AquilaCache / Entertainment / Fox / Data. do. To increase the data storage speed, a directory hierarchy for a particular subject is preferably created when intelligent router 92 requests cache 546 to start caching for a given channel and subject.

Data Retrieval : Data retrieval from cache 546 must be efficient so as not to interfere with data storage and cache 546. Data retrieval retrieves data from both disk and memory. The steps taken for data retrieval are preferably as follows: 1) locate the data node, 2) lock the data node, 3) locate the time stamp of the data that needs to be retrieved, and 3) the data. Retrieve the data and store the data in memory, 4) unlock the data node, and 5) filter and sequence the search data stored in memory before issuing to the agent 128 client.

While the invention has been described in conjunction with exemplary embodiments, it will be apparent to those skilled in the art that many changes are possible and this application is intended to cover any adaptations or variations. For example, hardware and software implementations of various types of publisher machines, user or subscriber machines, channels and their configurations, and content-based routing and other functions may be used without departing from the scope of the present invention. The invention is limited only by the claims and the equivalents thereof.

Claims (113)

A method for routing packets at a router in a network used to provide an alert service, the method comprising: Receiving a packet having a header section and a payload section containing information about a video clip from a particular camera; Examining the payload section of the packet at a network core for use in determining how to route the packet to subscribers associated with information from the particular camera; Selectively routing the packet based on the check Packet routing method comprising a. The method of claim 1, And the checking step includes determining whether information of the payload section matches the content predicate information in a structure in which content predicate information is associated with a corresponding network destination. The method of claim 1, And performing the checking step at a router in the network core. The method of claim 1, The checking step includes applying a filter to the information in the payload section. The method of claim 4, wherein Propagating the filter to a router in the network for use in performing the inspection. The method of claim 1, Programming a router in the network to perform the receiving step, the checking step, and the routing step. The method of claim 1, The inspecting step includes inspecting an attribute for use in determining how the packet is routed. The method of claim 1, Selectively routing comprises selectively routing the packet to a digital video surveillance system. The method of claim 1, And performing the checking step in a local area network. The method of claim 1, Performing the checking step at an internet service provider location. The method of claim 1, Wherein said particular camera comprises a digital video recorder and a charge coupled device. The method of claim 11, The digital video recorder generates the packet comprising the header section and the payload section, wherein the payload section includes information about the video clip from the particular camera. A method for routing messages in a router in a network providing an alert service, the method comprising: Receiving a message comprising a header section, at least one subject, and at least one attribute relating to a video clip from a particular camera; Retrieving the subject and the attribute from the message; Searching for a subscription based on the topic; Applying the attribute to the subscription at the network core to determine how to route the message to a subscriber related to the information from the particular camera Message routing method comprising a. The method of claim 13, Retrieving the subscription comprises retrieving a filter corresponding to the subscription. The method of claim 13, Routing the message if the attribute satisfies the subscription. The method of claim 13, Discarding the message if the attribute does not satisfy the subscription. The method of claim 13, Retrieving a plurality of filters corresponding to the plurality of subscriptions, Retrieving a plurality of attributes from the message; Applying each of the attributes to each of the filters to determine which of the corresponding subscriptions is satisfied; Selectively routing the message based on which one of the plurality of subscriptions is satisfied Message routing method further comprising. The method of claim 13, And performing the applying step at a router in the network core. The method of claim 13, Wherein said particular camera comprises a digital video recorder and a charge coupled device. The method of claim 19, And the digital video recorder generates the message including the header section, the at least one subject, and the at least one attribute regarding a video clip from a particular camera. A method for routing packets at a router in a network for use in providing an alert service, the method comprising: Receiving a packet having a header section and a payload section containing information about an event for a particular alert service; Examining the payload section of the packet at a network core for use in determining how to route the packet to subscribers involved in the alert service information; Selectively routing the packet based on the check Packet routing method comprising a. An apparatus for routing packets within a network for use in providing an alert service, the apparatus comprising: A receiving module for receiving a packet having a header section and a payload section containing information about a video clip from a particular camera; An inspection module for inspecting the payload section of the packet at a network core for use in determining how to route the packet to subscribers associated with information from the particular camera; Routing module for selectively routing the packet based on the check Packet routing device comprising a. The method of claim 22, The inspection module is adapted to match the content predicate information to information in the payload section in a structure in which content predicate information is associated with corresponding network destinations or corresponding rules governing in-router processing. And a module for determining a packet routing apparatus. The method of claim 22, And a module for performing the inspection at a router in the network core. The method of claim 22, The inspection module comprises a module for applying a filter to the information in the payload section. The method of claim 25, And a module for propagating the filter to a router in the network for use in performing the inspection. 23. The apparatus of claim 22 further comprising a module for programming a router in the network to perform the receiving, inspecting and processing. 23. The apparatus of claim 22 wherein the inspection module includes a module for inspecting attributes for use in determining how to route the packet. 23. The apparatus of claim 22, wherein the packet routing apparatus is located in a network including a digital video recorder. 23. The apparatus of claim 22, wherein the particular camera comprises a digital video recorder and a charge coupled device. A device for routing messages in a network providing an alert service, A receiving module for receiving a message having a header section, at least one subject, and at least one attribute related to a video clip from a particular camera; A module for retrieving the subject and attribute from the message; A module for retrieving a subscription based on the subject; And Application module to apply the attribute to the subscription at the network core to determine how to route the message to subscribers related to information from the particular camera Message routing device comprising a. 32. The apparatus of claim 31 wherein the module for retrieving a subscription comprises a module for retrieving a filter corresponding to the subscription. 32. The apparatus of claim 31 further comprising a module for selectively routing the message if the attribute satisfies the subscription and based on a guarantee of quality of service. 32. The apparatus of claim 31 further comprising a module for discarding the message if the attribute does not satisfy all subscriptions. The method of claim 31, wherein A module for retrieving a plurality of filters corresponding to the plurality of subscriptions; A module for retrieving a plurality of attributes from the message; A module that applies each of the attributes to each of the filters to determine which of the corresponding subscriptions is satisfied; And A module for selectively routing the message based on whether one of the plurality of subscriptions is satisfied Message routing device further comprising. 32. The apparatus of claim 31, further comprising one or more modules to perform the application at a router in the network core. 32. The message routing device of claim 31 wherein the message routing device is located in a network including a digital video recorder. 32. The apparatus of claim 31 wherein the particular camera comprises a digital video camera and a charge coupled device. A system for routing packets in a network used to provide alert service, A plurality of digital video cameras for generating digital video outputs; A local area network (LAN) connecting the digital video cameras; A publisher agent connected to the LAN to issue the digital video output; A publish-subscribe network connected to the publisher agent; And Digital Video Surveillance System (DVSS) for receiving the published digital video output via the publish-subscribe network Packet routing system comprising a. 40. The system of claim 39, further comprising a subscriber agent connected to the publish-subscribe network, subscribing to the digital video output, and pushing the subscribed digital video output to the DVSS. 40. The system of claim 39 wherein the publish-subscribe network comprises a plurality of intelligent routers. 42. The system of claim 41 wherein the intelligent router is A receiving module for receiving a packet having a header section and a payload section containing information related to digital video content from one of the plurality of digital video cameras; An inspection module for inspecting the payload section of the packet at a network core for use in determining how to route the packet to subscribers associated with the information from the digital video camera; And Route module to selectively route the packet based on the check Packet routing system comprising a. A network for distributing digital content to subscribers, A plurality of user machines; A central distributor that regularly distributes digital content; A plurality of cache servers that receive and cache the distributed digital content, the cache server periodically receiving user requests for a portion of the cached digital content from a user machine, and receiving the requested digital content to the user machines Sent box; And A routing box that receives the distributed digital content from the central distributor as files and transmits the digital content files to the plurality of cache servers using publish-subscribe content-based routing; the digital content file is publications. , The user request is subscriptions- Digital content distribution network comprising a. 44. The system of claim 43, wherein the routing box is a first routing box, and wherein the network further comprises a second routing box located with the plurality of cache servers, wherein the first routing box includes the plurality of digital content files. And route to the second routing box located with at least one of the cache servers in the server. 44. The digital content distribution network of claim 43 wherein the plurality of cache servers is located at a network service provider. 44. The digital content distribution 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 digital content distribution network of claim 46 further comprising second level cache servers that store a portion of the digital content distributed by the central distributor. 48. The system of claim 47 wherein the routing box is a first routing box and the network further comprises a second routing box located with the cache servers of the second level. The box transmits the digital content files from the first level cache servers to the second level cache servers using publish-subscribe content-based routing. The method of claim 48, wherein each of the 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 for examining the payload section of the packet for use in determining how to route the packet; And A route module for selectively routing the packet from the first level cache servers to the second level cache servers based on the check Digital content distribution network comprising a. 48. The digital content distribution network of claim 47 wherein a portion of the digital content stored at the second level of cache servers is determined based on a history of received user requests. 48. The cache server of claim 47, wherein the second level cache servers directly receive the user request and wherein the second level cache servers receive user requests for digital content not stored by the second level cache servers. Digital content distribution network for transmission. The method of claim 43, wherein the 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 for inspecting the payload section of the packet for use in determining how to route the packet; And A route module for selectively routing the packet from the central distributor to the plurality of cache servers based on the check Digital content distribution network comprising a. 44. The digital content distribution network of claim 43 wherein the central distributor comprises one or more servers. 44. The digital content distribution network of claim 43 wherein the digital content comprises video, music and software. A method of distributing digital content to subscribers in a network, Distributing digital content at a central distributor; Content-based routing the distributed digital content to a plurality of cache servers; Caching the content-based routed digital content at the plurality of cache servers; Receiving user subscriptions for the requested cached digital content; And Based on the received user subscriptions, sending the requested digital content from the plurality of cache servers to users. Digital content distribution method comprising a. 56. The method of claim 55, wherein the content based 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 for use in determining how to route the packet; And Selectively routing the packet to the plurality of cache servers based on the check Digital content distribution method comprising a. 59. The method of claim 56 wherein the inspecting step includes determining whether information in the payload section matches the content predicate information in a structure associating destinations corresponding to the content predicate information. 59. The method of claim 56 wherein the inspecting step includes applying a filter to information in the payload section. 59. The method of claim 58 further comprising propagating the filter from the network to a routing box for use in performing the inspection. 59. The method of claim 56 further comprising programming a routing box in the network to perform the receiving, inspecting and routing steps. 59. The method of claim 56 wherein the inspecting step includes inspecting attributes for use in determining how to route the packet. 59. The method of claim 56 further comprising performing the inspecting step in a routing box. 56. The method of claim 55, wherein the plurality of cache servers is a first level cache server, and the method further comprises transmitting cached digital content to a second level cache servers using content based routing. Digital Content Distribution Method. 64. The method of claim 63 further comprising determining whether the requested digital content is at the second level of cache servers. 65. The method of claim 64, further comprising sending received user subscriptions to the first level cache servers based on the determination. The method of claim 63, wherein And wherein said transmitting step transmits the cached digital content to said second level cache servers using content based routing based on the history of received user subscriptions. A method of routing packets at routers in a network in relation to a quality of service guarantee. Receiving a packet having a header section and a payload section, Examining the payload section of the packet at a network core for use in determining how to route the packet; Determining a quality of service guarantee for the packet; Selectively routing the packet based on the check and the quality of service guarantee Packet routing method comprising a. The method of claim 67, And the checking step includes determining whether the content predicate information matches the information in the payload section in a structure in which content predicate information is associated with a corresponding network destination. The method of claim 67, And performing the checking step at a router in the network core. The method of claim 67, The inspecting step includes matching a filter to information in the payload section. The method of claim 70, Propagating the filter to a router in the network for use in performing the inspection. The method of claim 67, Programming a router of the network to perform the receiving, inspecting, and routing steps. The method of claim 67, The inspecting step includes inspecting attributes for use in determining how to route the packet or in determining whether to drop all of the packets. A method of routing messages at routers in a network, Receiving a message having a header section, at least one subject, and at least one attribute, Retrieving the subject and attribute from the message; Searching for a subscription based on the topic; Determining a quality of service guarantee for the message; Applying the attribute to the subscription at a network core to determine how to route the message; Selectively routing the message based on the application and the quality of service guarantee Message routing method comprising a. The method of claim 74, wherein Retrieving the subscription comprises retrieving a filter corresponding to the subscription. The method of claim 74, wherein Routing the message if the attribute satisfies the subscription. The method of claim 74, wherein Discarding the message if the attribute does not satisfy the subscription. The method of claim 74, wherein Retrieving a plurality of filters corresponding to the plurality of subscriptions, Retrieving a plurality of attributes from the message; Matching each of the attributes to each of the filters to determine which of the corresponding subscriptions is satisfied; Selectively routing the message based on whether one of the plurality of subscriptions is satisfied Message routing method further comprising. delete A device for routing packets in a network in connection with quality of service, A module for receiving a packet having a header section and a payload section; At least one module for examining a payload section of the packet at a network core for use in determining how to route the packet; A module for determining a quality of service guarantee for the packet; A module for selectively routing the packet based on the QA and inspection result determined above Packet routing device comprising a. The method of claim 80, The checking module is configured to determine whether the content predicate information matches the information of the payload section in a structure in which content predicate information is associated with corresponding network destinations or corresponding rules governing in-router processing. Packet routing device comprising a. The method of claim 80, And a module for performing the checking step at a router in the network core. The method of claim 80, The inspection module comprises a module for matching a filter to information in the payload section. 84. The method of claim 83, And a module for propagating the filter to routers in the network for use in performing the inspection. The method of claim 80, And a module for programming the routers of the network to perform the receiving, inspecting, and routing. The method of claim 80, The packet routing device is a router. A device for routing messages in a network, A module for receiving a message having a header section, at least one subject, and at least one attribute; A module for retrieving the subject and attribute from the message; A module for searching for subscriptions based on the topic; A module for matching the attribute to the subscription at a network core to determine how to route the message; Module for determining a quality of service guarantee for said message Message routing device comprising a. 88. The method of claim 87 wherein The module for retrieving the subscription includes a module for retrieving a filter corresponding to the subscription. 88. The method of claim 87 wherein And if the attribute satisfies the subscription, and based on the quality of service guarantee, selectively routing the message. 88. The method of claim 87 wherein The subscription is retrieved from subscriptions stored on the device, and the device further comprises a module to discard the message if the attribute does not satisfy any of the subscriptions stored on the device. 88. The method of claim 87 wherein A module for retrieving a plurality of filters corresponding to the plurality of subscriptions; A module for retrieving a plurality of attributes from the message; A filtering module for matching each of the attributes to each of the filters to determine which one of the corresponding subscriptions is satisfied; And A module for selectively routing the message based on whether any one of the plurality of subscriptions is satisfied Message routing device comprising a. 88. The method of claim 87 wherein And at least one module for executing a filtering step at a router in the network core. 88. The apparatus of claim 87 wherein the message routing apparatus is a router. A method of routing and caching packets of data at a router in a multicast network, the method comprising: Receiving a packet having a header section and a payload section; Examining the payload section of the packet at a network core for use in determining how to route the packet to a subscriber; Selectively routing the packet based on the check; And Local caching of data from the packet at the network core Routing and caching method comprising a. 95. The method of claim 94, further comprising performing the checking step at a router. 95. The method of claim 94 wherein the inspecting step includes applying a filter to information in the payload section. 97. The method of claim 96 further comprising propagating the filter to a router in the network for use in conducting the check. 95. The method of claim 94, further comprising programming a router of the network to perform the receiving, inspecting, and routing steps. 95. The method of claim 94 wherein the inspecting step includes inspecting attributes for use in determining how to route the packet. 95. The method of claim 94, further comprising time marking the cached data. 95. The method of claim 94, further comprising indexing the cached data. 95. The method of claim 94, Receiving a data request; And Determining if the cached data satisfies the request Routing and caching method further comprising. 95. The method of claim 94, further comprising locally caching data from the packet at an edge routing node. 95. The method of claim 94, further comprising, after expiration of time frame T, removing the cached data. A network for routing and caching packets of data, An edge routing node for receiving and routing packets having a header section and a payload section; And At least one core routing node for receiving and routing the packet, The edge routing node, An intelligent router for routing the received packet; And A cache manager operatively associated with the intelligent router, The intelligent router, Inspecting the payload section of the packet at the network core for use in determining how to route the packet to subscribers; And Instructions for selectively routing a packet based on the inspection, The cache manager includes instructions for locally caching data from the packet into a local cache. 107. The system of claim 105, operatively connected to the edge routing node, Instructions for determining a location of cached data; Instructions for retrieving cached data from the local cache; And Commands for Processing Retrieved Cached Data The routing and caching network further comprises an agent comprising. 107. The system of claim 105, wherein one of the one or more core routing nodes is directly upstream from the edge routing node, The direct upstream core routing node is An intelligent router for routing the received packet; And A cache manager operatively associated with the intelligent router, The intelligent router, Inspecting the payload section of the packet at a network core for use in determining how to route the packet to a subscriber; And Instructions for selectively routing a packet based on the inspection, The cache manager includes instructions for locally caching data from the packet into a local cache. 107. The routing and caching network of claim 105, further comprising a plurality of channel managers providing characteristics for the plurality of channels. 107. The routing and caching network of claim 105, wherein the cache manager further includes instructions for time marking cached data. 107. The routing and caching network of claim 105, wherein the cache manager further includes instructions for indexing cached data. 107. The cache manager of claim 105, wherein the cache manager is Instructions for receiving a data request; And Instructions for determining if the cached data satisfies the request The routing and caching network further includes. An apparatus for routing and caching packets of data in a multicast network, the apparatus comprising: Including a plurality of processors, The plurality of processors, Instructions for receiving a packet having a header section and a payload section; Inspecting the payload section of the packet at a network core for use in determining how to route the packet to a subscriber; Selectively route the packet based on the check; And Local caching of data from the packet of the network core Routing and caching devices configured to run. 118. The system of claim 112, wherein the plurality of processors comprises a first processor and a second processor, the first processor to execute the check and selective routing instructions, and the second processor to execute the local caching instructions. And caching devices.

Images