WO2003083703A1 - Method and apparatus for reliable and efficient content-based routing and query and response in a publish-subscribe network - Google Patents

Abstract

A method and apparatus provide for executing publish-subscribe operations over unreliable networks (10). A method and apparatus provide for propagating filters in a publish-subscribe network (118, 140). A method and apparatus provide for content-based routing of packets in a publish-subscribe network (118, 140). A method and apparatus provide for implementing query-response interactions on a publish-subscribe network (118, 140). A method and apparatus provide for persistent caching of methods delivered via a publish-subscribe network (118, 140).

Description

Method and Apparatus for Reliable and Efficient Content-Based Routing and Query and Response in a Publish-Subscribe Network

REFERENCE TORELATEDAPPLICATIONS

The present application incorporates by reference and claims the priority of U.S. Provisional Application No. 60/368,833, entitled "Reliable Publish/Subscribe System Architecture over Unreliable Networks," filed March 28, 2002, U.S. Provisional Application No. 60/369,105, entitled "Methods for Propagating Content Filters for a Publish/Subscribe Network," filed March 28, 2002, U.S. Provisional Application No. 60/368,831, entitled "Practical Method for Content-Based Packet Routing in a Publish/Subscribe Network," filed March 28, 2002, U.S. Provisional Application No. 60/368,870, entitled "Implementing Query-Response Interactions On a Publish- Subscribe Infrastructure By Mapping Data Advertisements as Subscriptions and Queries as Notifications," filed March 28, 2002, U.S. Provisional Application No. 60/369,832, entitled "Method and Apparatus for Implementing Persistent and Reliable Message Delivery," filed April 3, 2002, and U.S. Provisional Application No. 60/447,782, entitled "Propagating Content Filters, Content-Based Packet Routing Using Compact Filter Storage and Off-Line Pre-computation, Reliable Publishing and Subscribing, Implementing Persistent and Reliable Message Delivery, and Implementing Query- Response Interactions By Mapping Data Advertisements as Subscriptions and Queries as Notifications in a Publish-Subscribe Network," filed February 19, 2003.

The present application also incorporates by reference U.S. Patent Application No. 10/199,356, entitled "Packet Routing Via Payload Inspection," U.S. Patent Application No. 10/199,368, entitled "Method And Apparatus For Content-Based Routing And Filtering At Routers Using Channels," U.S. Patent Application No. 10/199,439, entitled "Method For Sending And Receiving A Boolean Function Over A Network", U.S. Patent Application No. 10/199,369, entitled "Method For Storing Boolean Functions To Enable Evaluation, Modification, Reuse, And Delivery Over A Network," and U.S. Patent Application No. 10/199,388, entitled "Efficient Implementation of Wildcard Matching On Variable-Sized Fields In Connect-Based Routing," all filed July 19, 2002. BACKGROUND OF THE INVENTION

Network bandwidth is increasing exponentially. However, the network infrastructure (including routers, servers, daemons, protocols, etc.) is still using relatively old technologies. As a result, Internet applications and network routers cannot keep up with the speed of the bandwidth increase. At the same time, more and more devices and applications are becoming network enabled. The load that these devices and applications put on the network nodes have increased tremendously. The increase of network load and number of applications also makes the complexity of implementing and maintaining network applications much higher. As a result, the increase of network bandwidth and the ubiquitous use of network devices and applications can cause problems for routing and transmission of data in the old network infrastructure, particularly when publishing content to subscribers.

A model for having networks push information from servers to clients is the publish-subscribe style. In this model, the server becomes a simplified publisher of its information, without regard to which clients may be interested in that information or where they are located in the network. The clients become subscribers for information, with information delivered as it becomes available, potentially without regard to details about where in the network it was published. The network is then responsible for efficiently routing published information to subscribers, for matching information to active subscriptions, and for doing all of this in a way that is transparent to the publishers and subscribers.

Because the complexity of the server is greatly reduced in the publish-subscribe model, the distinction between a heavyweight server and a lightweight client can begin to disappear, or rather to merge into the notion of a peer that can be either publisher, or subscriber, or both. Numerous kinds of applications have a natural affinity for publish- subscribe-style interaction between peers. A common theme underlying many of these applications is that the information being published and subscribed for is in the form of events. For example, an investor buys or sells a stock, causing the price of the stock to change. A traffic incident occurs on a freeway, causing traffic on the freeway to back up. A security hole in a software system is discovered, causing a patch to be developed for the users of the software. A player fires a weapon in an Internet game, causing another player's avatar to die. All of these exemplary phenomena are events that are potentially of interest to large numbers of subscribers and can be propagated over a network to notify those subscribers that the events happened. An event is thus simply a self-contained, succinct piece of information about something potentially interesting that happened at some point in time at some place on the network. Another example involves a scheduled broadcast, which has differing characteristics from applications involving only asynchronous events where the time of events is unpredictable and random. First, the event is scheduled to take place at a known time. Secondly, an event does not need to be a succinct piece of information. Instead, it could be a massive amount of data. Directing this massive load of data to the parts of the network where interested subscribers are found requires substantial server processing.

Typically the server or publisher performs the routing decisions for the network in order to instruct the network on where to send published content in the publish- subscribe model. The publisher stores the subscriptions for content that it publishes. Upon receiving or generating new content, the publisher compares the content with each of the subscriptions to identify any matches. If the content (event) satisfies any subscriptions, the publisher pushes the content to the corresponding subscriber via the network. This conventional publish-subscribe model places a tremendous burden on the publishers, particular as more devices become network-enabled and as the number of subscriptions increases. A complementary approach can be just as odious — a subscriber evaluates its own subscriptions on all published events.

With greater convergence of untold numbers of applications across the Internet, the possibilities for exploiting event notification become endless. However, those possibilities require a more efficient way to make routing decisions and determine when events satisfy subscriptions, alleviating the burden on the publishers. Thus, a pervasive, persistent event notification service could provide tremendous value-added benefit for Internet applications, as well as other applications and implementations.

SUMMARY OF THE INVENTION

A method and apparatus provide for propagating filters in a publish-subscribe network. A plurality of filters relating to subscriptions to content in the network are received. A number of the filters is reduced based upon particular criteria, and the reduced number of filters are propagated for use in satisfying the subscriptions.

A method and apparatus provide for implementing query-response interactions on a publish-subscribe network. An advertisement relating to a data set and a query representing a logical expression are received. The advertisement is mapped to a corresponding subscription. The query is mapped to a corresponding notification. The subscription and the notification are used for implementing of the advertisement and the query in the network.

A method and apparatus provide for providing persistence of messages transmitted via a network. Messages are received via the network. The messages are stored for later retrieval. Persistent and reliable delivery of the messages is provided in response to failures relating to the network.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings are incorporated in and constitute a part of this specification and, together with the description, explain the advantages and principles of the invention.

FIG. 1 is a diagram illustrating intelligent routing in a network core.

FIG. 2 is a network diagram illustrating intelligent routers for publishers and subscribers. FIG. 3 is a diagram illustrating a network infrastructure for intelligent routers and backbone routers.

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

FIG. 5 is a diagram of publisher and subscriber machines.

FIG. 6 is a diagram of channel managers for intelligent routers. FIG. 7 is a diagram of software components in a user machine for interfacing the machine with intelligent routers

FIG. 8 is a diagram of software components for an intelligent router.

FIG. 9 is a diagram of a packet structure for a message.

FIG. 10 is a flow chart of a publisher method. FIG. 11 is a flow chart of a subscriber method.

FIG. 12 is a diagram of channel and subscriber screens. FIG. 13 is a flow chart of a content-based routing method.

FIG. 14 is a flow chart of a caching method.

FIG. 15 is a diagram illustrating a cache index.

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

FIG. 18 is a diagram illustrating an example of encoding of a message.

FIG. 19 is a diagram of a database structure for storing subscriptions.

FIG. 20 is a flow chart of a wildcard method.

FIG. 21 is a flowchart of a method for reliable transmission of notifications in a publish-subscribe network.

FIG. 22A is a flow chart of a filter propagation method.

FIG. 22B is a flow chart of a filter reduction method.

FIG. 22C is a flow chart of another filter propagation method.

FIG. 22D is a diagram of a publish-subscribe network topology. FIG. 23 A-23B are flow charts of a content-based routing method using pre- computation.

FIG. 24A is a flowchart of a query-response method using publish-subscribe.

FIG. 24B is a sequence diagram further illustrating the method of FIG. 24 A.

FIG. 24C is a flowchart of another query-response method using publish- subscribe.

FIG. 24D is a sequence diagram further illustrating the method of FIG. 24C.

FIG. 24E is a flowchart of another query-response method using publish- subscribe.

FIG. 24F is a sequence diagram further illustrating the method of FIG. 24E. FIGs. 24G and 24H are flowcharts of another query-response method using publish-subscribe.

FIG. 241 is a sequence diagram further illustrating the method of FIG. 24G and 24H.

FIG. 25 A is a block diagram illustrating components of a persistent publish- subscribe network.

FIG. 25B is a diagram illustrating embodiments of cache manager routines.

FIG. 25C is a flowchart of a persistent caching method.

FIG. 25D is a flowchart of a persistent message retrieval method. DETAILED DESCRIPTION

Overview

An Internet-scale, or other distributed network-scale, event notification system provides applications with a powerful and flexible realization of publish-subscribe networking. In this system, an application program uses event notification application program interfaces (APIs) to publish notifications and/or to subscribe for and receive notifications about events occurring inside the network.

A notification in the system is given a subject, which is a string or other structure that classifies the kind of information the notification encapsulates. Also, a notification is completed with a set of attributes containing information specific to the notification. For example, an application might publish notifications about transactions on the New York Stock Exchange using the subject quotes.nyse and attributes symbol and price. The application might publish an individual notification having specific attribute values, for example with symbol equal to SNE (the stock ticker symbol for Sony Corporation) and price equal to 85.25. Most if not all of the attributes in a notification are predefined, in the sense that they are found in all notifications for the same family of subjects. However, publishers can add discretionary attributes on a per-notification or other basis in order to provide additional event-specific information. Therefore, not all or even any attributes need be predefined.

In this system, subscribers are not restricted to subscribing only for subjects or whole channels. Channels are further explained and defined below. They can include an hierarchical structure specifying, for example, a subject field and one or more levels of related sub-fields (sub-subjects). Thus, subscribers can provide much more finely-tuned expressions of interest by specifying content-based filters over the attributes of notifications. For example, a subscriber might subscribe for all notifications for the subject quotes.nyse having symbol equal to SNE and price greater than 90.00 (indicating perhaps a sell opportunity for a block of shares owned by the subscriber). All notifications matching the subscription can be delivered to the subscriber via a callback or other type of function that the subscriber provides at the time it registers its subscription or at other times. One subscription can be broken down into many filters. The callback can perform many computations, including something as simple as writing a message to a terminal or sending an e-mail, to something more complex such as initiating the sale of a block of shares, and to something even more complex that initiates new publish-subscribe activity (for example, replacing the existing subscription with a new subscription for a buy opportunity at a price of 75.00, or publishing a new notification that the subscriber's portfolio has been modified).

Applications are aided in their publishing and subscribing activities by agents, for example. The agents can possibly make use of or be implemented with proxies. The agents, when used, provide network connectivity for outgoing notifications and subscriptions and delivery of incoming matching notifications to subscribers. Once a notification enters the network, the system's network of routers propagate the notifications to all subscribers whose subscriptions match the notification. One way of accomplishing this would be to broadcast the notification to all points of the network and then let the application agents decide whether the notification is relevant to their subscribers. However, this is not necessarily a scalable approach — the network would usually be quickly overwhelmed by the load of message traffic, especially in the presence of large numbers of active and verbose publishers. And even if sufficient bandwidth were not a problem, the subscribers would be overwhelmed by having to process so many notifications. The system's exemplary network is much more efficient in the way it routes notifications. First, it can use multicast routing to ensure that a notification is propagated, for example, at most once over any link in the network. Second, it can employ a large number of sophisticated optimizations on filters to reduce as much as possible the propagation of notifications. FIG. 1 is a diagram conceptually illustrating this intelligent routing in a network core. A publisher 14 transmits content in messages via an edge router 16 to a network core 10, used in a publish-subscribe network. A publish-subscribe network includes any type of network for routing data or content from publishers to subscribers. The content is transmitted via one or more channels 18 representing logical connections between routers or other devices. An intelligent router 12 in network core 10 determines whether to route or forward the message. In particular, intelligent router 12 can determine if the message includes content as subscribed to by a subscriber 24. Each subscription encapsulates a subject filter and an attribute filter. Routers can possibly expand a subject filter to the set of matching subjects and merge attribute filters on a per-subject basis. An intelligent router evaluates the subject filter against the subject of notifications, and evaluates the attribute filter against the attribute values in notifications. The syntax for subject filters can possibly use wildcards, and the syntax for attribute filters can use Boolean expressions, both of which are further explained below. The term "filter" is used to describe a set of events that a subscriber is interested in receiving from publishers. Routing rules are generated from the filters and are used by intelligent routers to make routing decisions. Therefore, if the entire filter set is not satisfied by a message 26, for example, intelligent router 12 drops (discards) message 26, meaning that the message is not forwarded. If any filter of the entire set is satisfied by a message 20 according to the evaluations of subject and attribute filters, for example, intelligent router 12 routes (forwards) message 20 via edge router 22 and possibly other devices to a subscriber 24, or performs other functions internal to router 12 with message 20, according to all the routing and/or action rules prescribed for the matching filter. The search will continue until either the entire set of filters has been exhausted, or decisions about all the rules have been obtained, whichever comes first.

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

Table 1 illustrates storing of subscriptions with subjects and predicates for the filtering. They can be stored in any type of data structure, as desired or necessary, anywhere in the network. As explained below, the predicates are components of subscriptions. The subscriptions can be expressed in any way, examples of which are provided below.

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

Table 2

Quote Server Example

Subject Tree Publication

Quotes.NYSE subject = Quotes.NYSE

Quotes.AMEX Attributes

Quotes.NASDAQ Symbol = SNE Price = 51 Volume = 1000000

Attributes Subscription

Symbol Subject = Quotes.NYSE

Price Filter

Volume (Symbol = SNE) & (Price > 55)

The predicates provide the Boolean expressions for the subscription and the subjects provide an indication of a channel for the subscription. Subscriptions can be expressed in many different ways. Use of Boolean expressions is one such example and provides an ability to easily convert the subscription into a subject filter and an attribute filter for content-based routing. Subscriptions can alternatively be expressed without reference to a subject; however, use of a subject or channel (further explained below) provides a context for interpreting and applying filters to attributes.

The routing decisions can be accomplished in the network core and distributed throughout the network, alleviating processing burdens on publisher and subscriber machines, and significantly enhancing the efficiency of the network. FIG. 1 illustrates one publisher, one subscriber, and one intelligent router for illustrative purposes only; implementations can include many publishers, subscribers, and intelligent routers. The term intelligent router refers to a router or other entity having the ability to make routing decisions by inspecting the payload of a packet or message in a network core or other locations.

Network Infrastructure

FIG. 2 is a network diagram illustrating intelligent routers for publishers and subscribers. A routing entity 30 providing channel services is, for example, effectively layered on a network infrastructure, as explained below, for routing messages among intelligent routers. A publisher 32 conceptually includes, for example, an application 34 to receive an indication of published content, such as a pointer for retrieving the content, and an agent 36 to encode the content for network transmission via channel services 30. A collection of logically interconnected intelligent routers 38, 40, 42, 44, 46, and 48 route the content from the publisher using routing rules generated from subject filters and attribute filters for subscriptions. A plurality of links 39, 41, 43, and 45 provide the logical connections between intelligent routers 38, 40, 42, 44, 46, and 48. Other links 37 and 47 provide, respectively, logical connections between publisher 32 and intelligent router 38, and between a subscriber 54 and intelligent router 46. Subscriber 54 includes an agent 50 to detect and receive the subscribed content, and an application 52 to present the content.

A channel can include, for example, a related set of logical multicast connections implemented in a distributed manner. A channel in this exemplary embodiment is a logically related collection of network resources used to serve a community of publishers and subscribers exchanging content. The content is classified according to the channel subject namespace, and the resources are managed, controlled, and provisioned via channel services provided by channel managers. Multiple channels may share the same resources. Channels can provide a highly scalable directory service such as, but not limited to, the following examples: publisher and subscriber information, authentication and authorization information, message types, management information, and accounting and billing information. Channels can also provide, for example, persistence through caching, a fast data delivery mechanism, security, and user and network management. Channels can be used for any other purpose as well. The filtering by the intelligent routers can occur in a network core to distribute routing decisions. In addition, intelligent routers can also function as edge routers connecting a user device, such as a publisher or subscriber, with the network core. Also, the same device connected to the network can function as both a publisher to push content to subscribers via routing decisions in the network and as a subscriber to received pushed content. The intelligent routers and channels can be connected in any configuration, as necessary or desired for particular implementations, and the configuration shown in FIG. 2 is provided for illustrative purposes only.

FIG. 3 is a diagram of an exemplary network infrastructure for intelligent routers and conventional backbone routers, also illustrating logical connections for channels. The intelligent routers in this example use existing backbone routers in the network, such as the Internet or other distributed network, and the intelligent routers are thus effectively layered on the backbone routers. In this example, Internet Service Provider (ISP) networks 58, 59, and 60 each include several backbone routers for conventional routing of messages or packets. A plurality of intelligent routers 61-70 are connected with one or more backbone routers in ISP networks 58, 59, and 60. Intelligent routers 61-70 are also interconnected by a plurality of links 73-85, representing examples of links, and can be connected to end user devices by the links as well. Intelligent routers 61-70 can be controlled by one or more administrator machines such as an entity 71, and one or more virtual private network (VPN) controllers such as an entity 72. The ISP networks 58, 59, and 60 would also be connected to publisher and subscriber machines (not shown in FIG. 3). The backbone routers in and among ISPs 58, 59, and 60 are interconnected in any conventional way within the existing network infrastructure.

The intelligent routers 61-70 and links 73-85, as illustrated, can be implemented using existing network infrastructure, and they provide for content-based routing in the network core. The links 73-85 represent logical connections between intelligent routers 61-70 and can be implemented using, for example, existing network infrastructure or other devices. A link, for example, can be implemented using a logical connection called the tunnel. A tunnel includes the hardware, and possibly software, network infrastructure for implementing a link, and one tunnel can be a component of multiple channels. The channels facilitate content-based routing in the intelligent routers by providing logical configurations for particular types of content and thus providing a context for attributes transmitted over the channels. Although intelligent routers can perform routing decisions without channels, the channels enhance the efficiency of content-based routing by the intelligent routers in the network core. This exemplary embodiment includes use of channels and links. A link is a connection between two routers-albeit intelligent routers. A channel is a network entity encompassing a (typically large) collection of routers, configured statically or dynamically by the interconnecting links to achieve one-to-many or many-to-many logical connections. In particular, a channel is a top-level logical entity describing the essential characteristics of the channel. Under one channel, there could be many subjects. Each subject will form a sub-network (such as a multicast tree) involving a collection of interconnected routers. These subject-based sub-networks can be allocated, oriented, and configured in different manners. The channel, being a collection of all the sub-networks formed for the subjects under it, may resemble a mesh of networks, for example.

FIG. 4 is a diagram of exemplary hardware components of an intelligent router 92, which can correspond with any of the other referenced intelligent routers. A network node 90 can include intelligent router 92 connected with a conventional backbone router 95. Intelligent router 92 includes a processor 93 connected to a memory 94 and a secondary storage 97 (possibly implemented with a detached machine, for example), either of which can store data, as well as cache data, and store applications for execution by processor 93. Secondary storage 97 provides non- volatile storage of data. Under software control as explained below, processor 93 provides instructions to backbone router 95 for it to route (forward) or not route (discard) messages or packets based upon routing rules generated from subject filters and attribute filters for subscriptions. Although shown as implemented in a separate processor-controlled device, intelligent router 92 can alternatively be implemented in an application specific integrated circuit (ASIC) within backbone router 95 to provide the intelligent routing functions in hardware possibly with embedded software. The intelligent routing functions can also be alternatively implemented in a combination of software and hardware in one or multiple routing devices.

FIG. 5 is a diagram of exemplary publisher and subscriber machines. A publisher machine 100 or 118 can include the following components: a memory 102 storing one or more publisher applications 104 and an agent application 105; a secondary storage device 112 providing non- volatile storage of data; an input device 108 for entering information or commands; a processor 114 for executing applications stored in memory 102 or received from other storage devices; an output device 110 for outputting information; and a display device 116 for providing a visual display of information.

A subscriber machine 122 or 140 can include the following components: a memory 124 storing one or more applications 126 and an agent application 128; a secondary storage device 130 providing non- volatile storage of data; an input device 132 for entering information or commands; a processor 134 for executing applications stored in memory 124 or received from other storage devices; an output device 136 for outputting information; and a display device 138 for providing a visual display of information. Publisher and subscriber machines can alternatively include more or fewer components, or different components, in any configuration.

Publisher machines 100 and 118 are connected with subscriber machines 122 and 140 via a network 120 such as the network described above. Network 120 includes intelligent routers for providing distributed routing of data or content in the network core via packets or messages. Although only two publisher and subscriber machines are shown, network 120 can be scaled to include more publisher and subscriber machines. The publisher and subscriber machines can be implemented with any processor- controlled device such as, but not limited to, the following examples: a server; a personal computer; a notebook computer; a personal digital assistant; a telephone; a cellular telephone; a pager; or other devices. Network 120 with intelligent routers can include any wireline or wireless distributed network, connecting wired devices, wireless devices, or both. Network 120 can also potentially use existing or conventional network infrastructure.

FIG. 6 is a diagram illustrating channel managers 150 for intelligent routers. In this example, channel managers 150 are implemented with multiple servers 152, 154, and 156. Each server includes its own local storage 158, 160, and 162. Intelligent routers 164, 166, and 168 contact channel managers for information about particular channels. The channel managers can also provide for data persistence, fail over functions, or other functions. The channel managers thus provide the channel services, which include a database or set of databases anywhere in the network specifying, for example, channel-related information, properties for data persistence, user information for publishers and subscribers, and infrastructure information. The infrastructure information can include, for example, an identification of intelligent routers and corresponding tunnels connecting them, subjects for the channels, and attributes for the channels (a name and type for each attribute). Packets or messages can also carry channel-related information including identification of fixed attributes and variable attributes. A user when on-line can download channel information. For example, a user can register by using a user name and password. Upon authenticating the user's log-on, the user can open (invoke) a channel and retrieve information about the channel from the channel managers. Publishers can use that information in publishing content, and subscribers can use that information for entering and registering subscriptions. Each channel manager 152, 154, and 156, in this example, acts as a primary for each intelligent router. In particular, each intelligent router is provided two Internet Protocol (IP) addresses in this example, one for a primary channel manager and another for a back-up channel manager. The intelligent routers use those IP addresses to contact a channel manager and retrieve channel information. If the primary fails, an intelligent router can contact a back-up channel manager. The channel managers 152, 154, and 156 thus share data, as indicated by the lines connecting them, concerning channel properties and other information. Each channel manager also has a designated back-up so that if the channel manager fails, another one can take over processing for it. Devices in the network can use commands, for example, to retrieve channel information, examples of which are provided in Table 3. Intelligent routers can alternatively only have a primary channel manager or more than two channel managers.

FIG. 7 is a diagram of exemplary software components in a stack 180 in a user machine or device for connecting it with a network having intelligent routers. The user machine can be used as a publisher, subscriber, or both, and it can include the exemplary devices identified above. Stack 180 can include one or more user applications 182, which can provide for receiving subscriptions from a user, receiving channel information from a publisher, or receiving content or data to be published. User application 182 can also include any other type of application for execution by a user machine or device.

The stack 180 can also 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. Agent 184 provides for establishing network connections or other functions, and Table 3 provides examples of commands implemented by agent 184, which can use proxy commands or other types of commands. Event library 186 logs events concerning a user machine or other events or information. Cache library 188 provides for local caching of data. Channel library 190 stores identifications of channels and information for them. Dispatcher library 194 provides connections with a control path 196, a channel manager 198, and one or more intelligent routers 200, and it can include the exemplary functions identified in Table 4. Messaging library 192 provides a connection with a data path 204.

Tables 5-9 provide examples of messaging APIs in the C programming language. Tables 5 and 6 provide examples of APIs to send and retrieve messages. Tables 7 and 8 provide examples of APIs to send and retrieve notifications. Table 9 provides examples of APIs to send and retrieve control messages. These APIs and other APIs, programs, and data structures in this description are provided only as examples for implementing particular functions or features, and implementations can include any type of APIs or other software entities in any programming language.

Table 5

Example of API to Send a Message PC_Status PC_msg_init(ChannelHandle ch, PCJJINT chid, PC_UINT userid,

PC jTypelnfo* MsgType, PC_UINT msgTypeSize,

PC_msg_SessionHandle *sess); PC_Status PC_msg_cleanup(PC_msg_SessionHandle sess); PC_Status PC_msg_closeTransport(PC_msg_SessionHandle sess); PC_Status PC_msg_create(PC_msg_SessionHandle s, PC_msg_DataType dType,

PC_msg_MsgHandle *msg); PC_Status PC_msg_delete(PC_msg_MsgHandle msg); PC_Status PC_msg_clone(PC_msg_MsgHandle org, PC_msg_MsgHandle

*new); PC_Status PC_msg_setSubj ect(PC_msg_MsgHandle msg, PC_CHAR *subj ect); PC_Status PC_msg_setSubjectint(PC_msg_MsgHandle msg,

PC_USHORT *subjectArray, PC_UINT arraySize); PC_Status PC_msg_setAttrByNameInt(PC_msg_MSGHandle msg, const PC_CHAR *name, PC_INT value); // for each type PC_Status PC_msg_setAttrByPosInt(PC_msg_MsgHandle msg,

PCJJINT attributePos, PC_INT Value); // for each type PC_Status PC_msg_addAttrInt(PC_msg_MsgHandle msg, const PC_CHAR *name,

PCJNT value); // for each type PCjStatus PC_msg_send(PC_msg_MsgHandle msg);

Table 6

Example of API to Retrieve a Message

typedef struct attribute {

PC_ CHAR *name;

PC_Status PC msg init(ChannelHandle ch, PC HINT chid, PC UINT userid,

PCjTypelnfo*

PC_Status PC_msg_cleanup(PC_msg_SessionHandle sess);

PC_Status PC_msg_recv(PC_msg_SessionHandle sh, PC_msg_MsgHandle *msg);

PCjStatus PC_msg_ctrlRecv(PC_msg_SessionHandle sh, PC_msg_MsgHandle

*msg);

PC_Status PC_msg_getSequenceNum(PC_msg_MsgHandle msg, PC_UINT

*seqNo);

PC_Status PC_msg_getPublisherInfo(PC_msg_MsgHandle msg,

PC_msg_PublicInfo *pub);

PC_Status PC_msg_getSubject(PC_msg_MsgHandle msg, PC_CHAR **subject);

PC_Status PC_msg_getSubjectInt(PC msg MsgHandle msg,

PCJJSHORT **subjectArray, PC_INT *size); PC. Status PC_msg_getSubjectInt(PC_msg_MsgHandle msg,

PC USHORT **subjectArray, PCJNT *size);

PC. Status PC_msg_getDataType(PC_msg_MsgHandle hMsg,

PC_msg_DataType *dataType);

PC. Status PC_msg_getAttrByPoslnt(PC_msg_MsgHandle msg, PCJJINT pos, PCJNT *val); // for each type

PC. Status PC_msg_getAttrValueByNamehιt(PC_msg_MsgHandle msg, const PC_CHAR *name, PC_INT *val);

PC. Status PC_msg_getAttrTypes(PC_msg_MsgHandle msg, PCJTypeCode* Types,

PCJNT *arraySize);

PC. Status PC_msg_getAttributeByPos(PC_msg_MsgHandle msg,

PCJJINT attributePos, PC_msg_Attribute **attr);

PC. Status PC_msg_getAttributeByName(PC_msg_MsgHandle msg, const PC_CHAR *name, PC_msg_Attribute **attr);

PC. Status PC_msg_getPredefinedAttributes(PC_msg_MsgHandle msg,

PC_msg_AttributeArray **attrs );

PC. Status PC_msg_getDiscretionaryAttributes(PC_msg_MsgHandle msg,

PC_msg_AttributeArray **attrs);

Void PC nsgJreeAttribute(PC_msgAttribute *attr); Void PC msg freeAliributeAττay(PC_msg_AttributeAττay*attr Array);

Table 7

Example of API to Send a Notification

ChannelHandle ch;

PC_msg_MsgHandle msg; PC_msg_SessionHandle sh; PC_msg_TypeInfo Types[2]; Types [0].type = PC_STRING_TYPE; Types [Oj.name = "company" Types [lj.type = PCJNT TYPE; Types [lj.name = "stockvalue"

PC_msgJnit(ch, chid, userid, Types, 2, &sh)

PC_msg_create(sh, PC_MSG_DATA, &msg); PC_msg_setAttrValueByNameInt(msg, "stockvalue", 100); PC_msg_setAttrValueByPosString(msg, 1, "PreCache"); PC_msg_addAttrString(msg, "comment", "mycomments");

PC_msg_send(msg); PC_msg_delete(msg); PC_msg_closeTransport(sh); PC_msg_cleanup(sh); Table 8

Example of API to Retrieve a Notification

ChannelHandle ch;

PC_msg_MsgHandle msg: PC_msg_SessionHandle sh; PC_msg_TypeInfo Types[2]; PC_msg_AttributeArray *attrArray; PC_CHAR *comρany; PC_INT value;

Types [Oj.type = PC_STRING_TYPE; Types [0].name = "company" Types [l].type = PCJNT TYPE; Types [lj.name = "stockvalue"

PC_msgJnit(ch, chid, userid, Types, 2, &sh); While (1) {

PC_msg_recv(sh, &msg);

PC_msg_getAttrValueByPosString(msg, 0, &company); PC_msg_getAttrValueByNameInt(msg, "stockvalue", &value); PC_msg_getDynamic Attributes(msg, &attrArray) ; PC_msg_freeAttributeArray(attr Array) ; PC_msg_delete(msg);

}

PC_msg_closeTransport(sh); PC_msg_cleanup(sh);

chid); } PC_msg_addAttrString(mh, PC_msg_closeTransport(sh);

"Subject", "Quote.cboe"); PC_msg_cleanup(sh); PC_msg_send(mh); PC_msg_delete(mh);

FIG. 8 is a diagram of exemplary software components 210 for an intelligent router such as those identified above and intelligent router 92 shown in FIG. 4. Software components 210 can be stored in, for example, memory 94 for execution by processor 93 in intelligent router 92. Components 210 include, for example, a filtering daemon 212, a dispatcher 214, a routing daemon 216, and a cache manager 218. Filtering daemon 212 provides filtering for content-based routing to process content for subscriptions according to routing rules, as explained below. Dispatcher 214 provides for communication of control messages such as those required for propagating filters via path 220, and the dispatcher can also provide for a single point of entry for users and one secure socket with channel managers, enhancing security of the network. In other words, users do not directly contact channel managers in this example, although they may in alternative implementations. Dispatcher 214 uses control messages to obtain attributes (name-value pairs) from a channel manager. Routing daemon 216 provides for communication with a data path 222, which can occur via a conventional backbone router as illustrated in FIG. 4 or other routing device. Cache manager 218 provides for local caching of data at the network node including the corresponding intelligent router. The operation of cache manager 218 is further explained below, and it provides for distributed caching of data throughout the network core.

Content-based routing can be implemented at the kernel level, as an alternative to the application level. Memory accessible by the kernel is separate from that in the application layer. To have content-based routing running in the application requires, for example, that message data be copied from the kernel memory area to the application area, and switching the context of the application from that of the kernel to that of the routing application. Both can induce substantial overhead. If instead the kernel is modified to support content-based routing, the routing could take place much faster being rid of the overhead described above. With this feature of content-based routing in the kernel, the routing daemon 216 may or may not directly send or receive data via the data path 222, depending on the implementation. The daemon is a process running in the application layer, pre- computing the content-based routing table to be injected into the kernel. Once injected, however, the routing table can be used by the kernel to make routing decisions.

Similarly, the filtering daemon pre-computes the filtering table and injects it into the kernel. In this kernel implementation, neither the routing daemon nor the filtering daemon would directly interact with the data path.

FIG. 9 is a diagram of an example of a packet structure 230 for a message possibly including content for subscriptions. A packet or message for use in content- based routing includes, for example, a header section and a payload section. The header section specifies routing or other information. The payload section specifies data or content, or an indication 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 attributes 242. Packet structure 230 illustrates a basic structure for a length value and the subjects and attributes. A packet used in content-based routing can also include other or different elements, such as those illustrated in the example of FIG. 18 explained below, and packets for content-based routing can be configured in any manner. Also, the attributes can include discretionary attributes appended to the end of a message, for example. These discretionary attributes are ad-hoc information, for example, added by the publisher (or even routers) that cannot necessarily be conveyed using the message format prescribed for the channel.

Publisher and Subscriber Methodologies FIG. 10 is a flow chart of an exemplary publisher method 250 for use by a publisher to set-up a channel and publish content. Method 250 can be implemented, for example, in software modules including agent 106 for execution by processor 114 in publisher machine 100. In method 150, agent 106 in the publisher machine receives a publisher creation of a proxy for a channel (step 252). The proxy provides for communication with the network. Agent 106 determines a message format for the channel through an interface (step 253), and the format information can be obtained from, for example, the channel managers or other entities in the network. Agent 106 sets up the proxy for the channel using the received channel information (step 254), which includes receiving attributes for the channel (step 256) and creating a notification on the channel (step 258). The notification provides content for devices "listening" for content on the channel. The attributes define parameters and characteristics for the notification. Agent 106 transmits an identifier (ID) of the channel and content information to intelligent routers in the network core or elsewhere for use in processing subscriptions (step 260). The publisher populates the notification attributes with appropriate values (step 261), and the publisher can then publish content on notification in accordance with the channel attributes (step 262). Steps 260-262 in this example accomplish publishing the notification, which can alternatively involve different or additional steps depending upon a particular implementation. Therefore, the information associated with a notification in this example is partitioned into an ordered sequence of attributes, each of which has a name, a position within the notification (starting at 1), a type, and a value. Alternatively, attributes can have different characteristics depending upon a particular implementation. Attributes can include, for example, predefined attributes, discretionary attributes, or both.

The intelligent routers can use the channel ID in a packet to obtain the attributes for the corresponding channel, which determines the structure or format for packets transmitted via the channel. In particular, each packet can contain, for example, a tag associated with a channel ID and other header information such as a publisher ID and subjects. The tags can be used to map subjects to numbers in the message format, an example of which is shown in FIG. 18. Small integer values, for example sixteen bit values, can be used for the numbers. Alternatively, any other type of numbers or information can be used to map the subjects. Mapping subjects to numbers can provide particular advantages; for example, it can save space in the message format and provide a uniform or standard way to specify indications of the subjects in the message so that they can be quickly located and identified. Intelligent routers can locally store the mapping or, alternatively, use the numbers to remotely obtain the corresponding subject through a command. Table 10 illustrates a 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 an hierarchical relationship; for example, a subject tree can include a string of subject fields demarcated by particular symbols. Examples of subject trees are provided in Table 2. As an example, a subject tree quotes.nyse includes a subject "quotes" and a sub-field "nyse" with those two terms demarcates by a "." as found in URLs or other network addresses. Aside from using periods and specifying URL-type strings, subject trees can be specified in any way using any characters and symbols for demarcation.

Thus, knowing the packet format or structure for a particular channel, the intelligent routers can quickly locate subjects and attributes, or other information, in the packet for content-based routing. For example, a channel can specify byte positions of subjects and attributes transmitted over the channel, making them easy to locate by counting bytes in the packet. Alternatively, intelligent routers can parse packets to locate subjects and attributes, or other information.

Table 11 provides an example of a publisher program in the C++ programming language. Table 12 provides an example of an API to create a channel. Table 13 provides an example of a channel configuration file maintained by a channel manager (see FIG. 6) and providing channel-related information, as illustrated. The system can alternatively have a global channel manager providing IP addresses of geographically dispersed servers functioning as local channel managers in order to distribute the processing load. Table 11

Example of Publisher Program

#include "PC_evnJSfotification.h" #include "PC_evn_Proxy.h" using namespace precache::event; int main(int argc, char argv[])

{

PC_UINT QuotesRUs = myChanneloflnterest; // channel ID

PCJUINT mylD = myPublisherlD; // publisher ID try {

Proxy p(QuotesRUs, mylD); Notification nl(p, "quotes.nyse"); nl .SetPredefinedAttrC'symbol", "LUS"); nl.SetPredefmedAttr(price", 95.73); p.Publish(nl);

Notification n2(p, "quotes.nyse"); n2.SetPredefinedAttr(l, "SNE"); // attribute symbol is in position 1 n2.SetPredefinedAttr(2, 80.18); // attribute price is in position 2 p.Publish(n2);

} catch (InvalidChannelException icex) { cerr « "bad channel" « endl;

} catch InvalidSubjectException isex) {

} catch (InvalidNotificationException inex) { cerr « "bad notification" « endl;

} catch (Exception ex) { cerr « "unknown error" « endl; }

Table 12

Example of API to Create a Channel

PCjStatus re; re = PC_chn_create(Provider nfo, authinfo, ConfigurationFile, &hChannel);

/* the first one primary channel manager */ re = PC_chn_addChannelManager (hChannel, "10.0.1.1"); /* secondary channel manager */ re = PC_chn_addChannelManager (hChannel, "10.0.2.2");

*/ re = PC_chn_setProρerties (hChannel, ConfigurationFile);

/*

Set the message type (only in fixed part of the message) by using re = PC_chn_setAttributeType(hChannel, name, position, attributeType).

The type information is propagated to all edge routers.

*/ re = PC_chn_setAttributeType(hChannel,"Priority",l,PCJJINT 16JTYPE); re = PC_chn_setAttributeType(hChannel,"Alarm_Name",2, PC STPJNGJTYPE); re = PC_chn_setAttributeType(hChannel,"Alarm_Time",3, PC JNT32JTYPE); re = PC_clm pdateAttribute(hChannel); re = PC_chn_close(hChannel); /* finish channel creation */

Table 13

Example of a Channel Configuration File

# Channel Setup - Read by Channel API, event and messaging

# Each channel entry information is tagged with the

# type of information e.g.

# [ChannelComm 5] for Channel 5 Communication related information

# [ChannelSubjects 5] for subject related information in channel 5

# [ChannelAttributes 5] for attribute information in channel 5 #

# The Channel id is appended to the tag to indicate

# the channel that the information belongs to

# e.g. [ChannelComm 5] indicates routing information

# for channel 5. #

# All the fields need not be set. For example if

# running with the central server, the MulticastIP is

# not needed.

[ChannelComm 5]

MulticastIP=225.0.0.1

RouterIP=test3

RouterPort=12345

ProxyPort=9015

ProxyCfrlPort=9016

[ChannelSubjects 5]

NumberOfSubj ects=2 subjectl= #.SUBSCRIPTION mappingl=0.100 subj ect2=Quotes.Nyse mapping2=102.101

[ChannelAttributes 5]

NumberOfAttributes=4 namel=StockId typel=PC_UTNT_TYPE name2=Company type2=PC_CHARARRAY_TYPE name3=Price type3=PC_FLOAT_TYPE name4=Nolume type4=PC_UIΝT_TYPE

FIG. 11 is a flow chart of a subscriber method 264 for use in receiving and processing subscriptions. Method 266 can be implemented, for example, in software modules including agent 128 for execution by processor 134 in subscriber machine 122. In method 264, a graphical user interface (GUI), for example, presents an indication of available channels to a user (step 266), which can be accomplished by application 126. The information identifying the channels can be received from, for example, the channel managers providing channel-related information. Any type of application 126 can be used for presenting identifications of channels in any particular way or format. The application receives a user's selection of a channel (step 268) and calls an API or other program for the selected channel (step 270). The API presents subscription options to the user for the channel corresponding with the selected option (step 272). The API receives values for the subscription from the user (step 274) and sends the subscription to agent 128 for processing, as explained below (step 276). The parameters for the subscription can include, for example, the predicates as illustrated in Table 1. Each channel can use its own API, for example, in order to process subscriptions according to the particular requirements or parameters for the corresponding channel. These APIs can include, for example, web-based or Java-based APIs for receiving subscriptions and can use any type of user interface and processing to receive information for a subscription and pass it along to the agent application.

FIG. 12 is a diagram conceptually illustrating channel and subscriber screens or GUIs 278 and 284, which can be used in conjunction with method 264 for receiving a subscription. Screen 278 includes a plurality of sections 282 identifying available channels for selection by a user. Upon selection of a particular channel, screen 284 can be displayed for receiving a user's values for the subscription in a section 286. A user can select a section 288 to submit the subscription or select a section 290 to cancel the subscription. Screens 278 and 284 can be formatted as, for example, HyperText Markup Language (HTML) web pages or in any other format. Also, the screens can include any configuration of sections and content, possibly including, for example, text, graphics, pictures, various colors, or multi-media information in order to provide, as desired, a user-friendly and visually appealing interface for subscribers. The screens can also include a toolbar 280 providing, for example, conventional browser functions.

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

SubscriptionHandle sh = p.Subscribe("quotes.nyse", f, this,

(void*)&cl); while (notificationCount < 2) { // let notify() get some

// notifications sleep(5);

} p .Unsubscribe(sh) ;

} catch (InvalidChannelException icex) { cerr « "bad channel"« endl;

} catch (InvalidSubjectException isex) { cerr « "bad subject" « endl;

} catch (InvalidChannelException ifex) { cerr « "bad filter"« endl;

} catch (InvalidSubscriptionHandleException ishex) { cerr « "bas subscription handle" « endl;

} catch (Exception ex) { ceπ « "unknown error" « endl;

}

} void Notify(Notification* n, void* c) // this is the callback method

{ if (*(PCJNT*)c = 0){ // check the closure object

PC_STRING symbol;

PC_FLOAT price; n->GetPredefmedAttr("symbol", symbol); n->GetPredefinedAttr("price", price) ; cout « "The price of" « symbol « " is " « price « endl; notificationCount++;

}; int main(int argc, char argv[])

{

SubscriberApp a; a.run(); Content-Based Routing Via Payload Inspection and Channels

FIG. 13 is a flow chart of a content-based routing via payload inspection method 300. Method 300 can be implemented, for example, in software modules for execution by processor 93 in intelligent router 92, as represented by filtering daemon 212. Alternatively, it can be implemented in an ASIC or a combination of hardware and software. The content-based routing as illustrated in method 300 can be performed in intelligent routers anywhere in the network, such as in the network core or in edge routers.

In a general sense, the content-based routing involves inspecting a payload section of a packet in order to determine how to process the packet. This content-based routing methodology can include, for example, processing a list of subscriptions (using filters, for example) in any order, comparing a message subject-by-subject and attribute- by-attribute with routing rules to determine a routing for the message, and performing the processing in a network core. The rules can include rules governing in-router processing or any rules associated with a filter. These routing decisions can thus be distributed throughout a network core. The use of subjects as represented by channels determines a message format, thus providing an intelligent router with a way of quickly locating attributes within the message, for example by knowing their byte positions in the message or packet for a particular channel. In method 300, intelligent router 92 receives a packet for a message (step 302). It determines from the packet a channel ID for the corresponding message (step 304) and retrieves attributes for the channel using the channel ID (step 306). In this example, the type of channel (determined from the channel ID) determines locations and data types of attributes in the packet. The attributes for the channel can be locally stored or retrieved remotely such as via a channel manager. Intelligent router 92 retrieves a filter, which corresponds with a subscription (step 308). The filter includes one or more attribute tests, usually a group of attribute tests for subscriptions. Intelligent router 92 applies attributes in the packet to the corresponding attribute test(s) in the filter description (step 310). If all the attribute test(s) in the filter description produce a positive result (step

312), meaning the attributes satisfy all the attribute test(s), the intelligent router executes a set of functions prescribed by the rules associated with the filter (step 314). These functions can include, for example, routing the packet to the next link, and/or performing some action or computation with the content of the packet at the local router as prescribed by the rule(s). The action or next link can be identified, for example, in a data structure specifying the corresponding subscription. When the rule is a link, it typically identifies the next network node to receive the packet, which can include an intelligent router, backbone router, a network-connected device, or other entity. Alternatively, the next links can be specified or associated with the subscriptions in other ways.

If all the attribute test(s) in the filter description did not produce a positive result (step 312), meaning the attributes do not satisfy all the attribute test(s), the filter is declared a mismatch (step 315). The intelligent router recursively follows the above procedure until all the attribute tests in the filter description are exhausted or a first negative result is encountered, whichever comes first.

Once all the attribute tests have been processed for this filter, the intelligent router determines if more filters exist (step 316) and, if so, it returns to step 308 to retrieve the attribute test(s) for the next filter to process the attributes for it. The matching procedure (steps 308, 310, 312, 314, 315, and 316) continues until either the complete set of filters is exhausted, or results for all the action or routing rules can be determined, whichever comes first. If the packet does not satisfy any filter, it will be dropped (discarded) and not forwarded. Intelligent router 92 can sequence through the filters in any particular order. For example, as illustrated in Table 15, intelligent router can store the filters for subscriptions in a file or routing table and linearly sequence through them to apply the attributes to filters (attribute tests). Alternatively, the routing table can include links or pointers to the filters. The content-based routing can optionally use more than one method at the same time, depending on the applications and performance-enhancing heuristics such as the switching of algorithms based on traffic conditions, for example. The filters for the processing can optionally be encrypted, decrypted, transformed, and merged at a router in the network for use in performing inspecting of a payload section for the content- based routing. For example, a subscription such as price > $3.54122 may be truncated to price > $3.54 because the publications in the application are known not to contain currency attributes beyond the second decimal points. Also, foreign currency may be translated into U.S. currencies as well when a publication sent from overseas reaches the first router located in the U.S., for example.

As an alternative to a linear approach, intelligent router 92 can select filters for processing in other orders or according to various algorithms that can possibly enhance the speed and efficiency of processing. Table 16 provides examples of subscriptions and corresponding links for them; in these examples, the subjects relate to a particular channel and the subscriptions for the subjects can be represented by routing rules for the filters. The subjects can include, for example, network addresses such as Uniform Resource Locators (URLs) identifying a source of content.

10 Cac l in g at

Net wor k

No des

FIG. 14 is a flow chart of a caching method 320. Method 320 can be implemented, for example, in software modules for execution by processor 93 in intelligent router 92, as represented by cache manager 218. Alternatively, it can be implemented in an ASIC or a combination of hardware and software, either in the same or different physical device as the corresponding intelligent router, h method 320, intelligent router 92 receives a message having data or content, a channel ID, and subjects (step 322). intelligent router 92 time marks the data (step 324) and locally caches it such as in memory 94 or secondary storage 97 (step 326). It indexes the cached data by, for example, channel ID, subjects, and time stamps (step 328). If intelligent router 92 receives a request for data (step 330), it retrieves cached data, using the index, according to the request (step 332). Intelligent router 92 transfers the cached data to backbone router 95 or other routing entity for eventual transmission to the requestor or others. Method 320 can be repeatedly executed in order to continually cache data and retrieve cache data in response to requests. FIG. 15 is a diagram illustrating a cache index (336) for use with method 320.

Cache index (336) receives data (338) and stores it with time stamps (340). As data is gathered, it is marked upon every duration of delta t, where delta t represents the time between marks, for example t₂ - ti. Other types of indexes for time marking in any way can alternatively be used. Table 17 conceptually illustrates indexing of cached data. Table 18 conceptually illustrates a data structure for storing a connection history for caching. Table 19 provides examples of data structures for use in locally caching data in network nodes having intelligent routers.

The time marking can occur at any fixed or variable interval. For example, data can be cached and indexed every five minutes. Upon receiving a command to retrieve cached data (such as #.getCache) specifying a time and subject, channel manager 218 uses the cache index to determine if it can retrieve cached data corresponding with the request for step 332.

Each subject or channel can include, for example, its own IP address in a multicast tree and a set of intelligent routers. Therefore, Table 18 represents a connection history among such routers that can be locally stored a user machine; if an edge router fails, the machine can access the connection history to determine how to reconnect with upstream routers for the channel when the edge router comes back online. It can also execute a get cache command for the duration of the time that it was disconnected in order to obtain any pending content for subscriptions, for example.

Table 19

Examples of Cache Data Structures for Intelligent Router

Channel Node

Struct ChannelNode { PCJJINT unChanld; PC Attributeϊnfo *pAttrinfo; PC BOOL bPersistent; /* Persistent or RT*/ PC UINT unTimeout; PC UINT unTimeGranularity;/* in minutes */ PCJNT nDirFd; HashTable *pFirstLevelSubjs;

}

Subject Node

Struct SubjectNode { PC USHORT unSubjectld; PC UINT unSubjLevel; Void pParent; /* Channel or Subject */ PC INT nDirFd; HashTable *pNextLevelSubj s; DataNode *pData; }

Data Node

Struct DataNode { PCJNT nDirFd; SubjectNode *pParent; LastTimeGrainNode *pLastTGrainData; DLIST *pStoredData;/*list StoredTimeGrainNode */ PC Mutex mStoredDataLock;

}

Stored Time Grain Node

Struct StoredTimeGrainNode { PC UINT unStartTime; /* in minutes */Chanld; PC UINT unEndTime; /* in minutes */ PC INT nFd;

}

Last Time Grain Node

Struct LastTimeGrainNode {

PC CHAR pLastTGrainData; /* could be a list */

PC UINT unLastTGrainStartTime;

PCJBOOL bReadyToStore;

PC Mutex mCachedDataLock; }

These exemplary data structures include the following information. A subject node contains a subject identifier, subject level, pointer to parent channel or subject node, file descriptor for its own directory, pointer to hash table containing its next level subject nodes, and pointer to a data node. A data node contains a pointer to its subject parent node, file descriptor for the data directory, circular buffer containing the data structures for the data stored on each storage device, head and tail of the buffer, and lock for locking the data node during retrieval and storage. The stored time grain node is the node representing the actual data file, and the last time grain node represents the last buffer that has not yet been stored to the storage device but is maintained in memory. The caching and data storage threads in this example use the mutex of the last time grain node for preventing concurrent access to the last time grain node.

Agent Processing

FIG. 16 is a flow chart of an agent method 350 for an outgoing subscription message. Method 350 can be implemented, for example, in software modules as represented by agent 128 for execution by processor 134 in user (subscriber) machine 122. In method 350, agent 128 receives a subscription such as via the method described above in FIGS. 11 and 12 (step 352). Agent 128 creates a string specifying a Boolean expression for the subscription (step 354) and parses the string to detect any eπors in the subscription (step 356). If an error exists, agent 128 can present an error message to the user (step 360) in order for the user to correct the error and re-enter the subscription. If the subscription contains no errors (step 358), agent 128 stores the expression in a data structure, an example of which is provided below (step 362). Agent 128 translates constituent not-equal expressions in the data structure to positive form (step 364) and translates the data structure to a coπesponding disjunctive normal form (DNF) structure (step 366). Agent 128 also simplifies AND expressions of the DNF structure to contain only range filters and membership tests (step 368).

The DNF is a well-known canonical form in which a Boolean expression is represented as an OR of one or more sub-expressions called disjuncts, each sub- expression being an AND of one or more attribute tests. For example, the Boolean expression (price >= 10 AND (symbol = "LU" OR symbol = "T")) has an equivalent DNF representation of ((price >= 10 AND symbol == "LU") OR (price >= 10 AND symbol = "T")).

The transformation in step 364 involves translating expressions having the "not- equal" operator (represented in an exemplary syntax as !=) into an equivalent "positive" form that specifies all allowed values rather than the one disallowed value. This transformation is performed prior to creation of the DNF, and it is needed because the routers in this example require formulae to be in positive form. For example, the expression (price != 80) can be transformed to the equivalent positive expression (price <= 79 OR price >= 81). The transformation in step 368 is performed after the DNF is created and involves an extra simplification of the resulting AND expressions, and it is also performed to simplify the work of the routers in this example. In particular, an AND of multiple attribute tests for the same attribute can be simplified into a canonical "range filter" having either one lower bound, one upper bound, both a lower and upper bound, or a single value in the case of an equality test. The particular kind of range filter is then encoded 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 an example of a range filter with both a lower and an upper bound. Examples of the other kinds after simplification are the following: (price >= 20) (lower bound only); (price <= 80) (upper bound only); and (price = 50) (single value), hi creating these range filters, it is possible that some sub-expression will simplify to true or to false, in which case the sub-expression can be eliminated according to the laws of Boolean algebra, thereby further optimizing the encoding of the expression in a message. For example, the expression (price >= 50 AND price <= 20) simplifies to false, since no value for "price" can satisfy the expression. In the special case in which a whole filter expression simplifies to false, the agent need not create a message at all, thereby relieving the router of unnecessary work. If the subject filter contains wildcards, agent 128 can optionally convert them as explained below (step 370). Otherwise, any wildcards can be converted in the network, rather than on the user machine or other device. In this exemplary embodiment, the syntax for subject filters is the only syntax that uses wildcards, and the syntax for attribute filters is the only syntax that uses Boolean expressions. Alternatively, implementations can use different or varying types of syntax for subject filters and attribute filters.

Agent 128 encodes the resulting DNF expression into a message (step 372) and transfers the message to an intelligent router (step 374). The encoding can involve converting the subscription to a flat message format, meaning that it constitutes a string of data. This transferring can involve propagating routing rules generated from subject filters and attribute filters for the subscription to one or more intelligent routers or other routing entities in the network. For the propagation, the subscription expression can be mapped into a conventional packet structure, for example.

The encoding for step 372 involves marshalling subscriptions for a channel into a messaging format of the messaging API for propagation throughout a channel. A subscription is internally messaged, for example, as a notification with subject

#.SUBSCRIPTION. Because there are both a variable number of subject filter fields and a variable number of attribute tests, one pair of bytes is used to store the number of subject filter fields, and another pair of bytes is used to store the number of attribute tests in this example. The individual fields of the subject filter are marshaled sequentially, for example, in the order in which they were specified in the original subscription and are each marshaled into a two-byte portion of the message. Wildcard fields can be marshaled as described below.

In marshaling the attribute tests, the operands of the tests are marshaled at the end of the message in a manner similar to the marshaling of attribute values of notifications. Prior to marshaling the attribute tests and operands, they are sorted by attribute order within each disjunct of the DNF with tests on predefined attributes in position order, followed by tests on discretionary attributes in name order. Furthermore, the set of relational tests on scalar valued attributes within each disjunct are simplified to a canonical form as range filters having either one limit (for left- or right-open ranges or equality tests) or two limits (for closed ranges between distinct limits). The remaining information about the tests is encoded into, for example, two-byte pairs in the same order as the operands; this sequence of two-byte pairs is placed in the message immediately following the sequence of two-byte encoding of subject filter fields. The two-byte pairs can constitute one form of a sequence of bit-string encodings of attribute tests, which can also be used to represent other types of encodings aside from two-byte pairs. Examples of attribute tests are provided below.

The schema for the encoding of the attribute tests is depicted in Table 20. Table 21 illustrates encoding for the two-byte pairs, and Table 22 illustrates encoding of the Operator ID in the two-byte pairs.

Because the two-byte pair for a test already indicates both the type of the operand of the test and whether or not the test applies to a predefined or discretionary attribute, there is no need to separately marshal the number of tests performed on discretionary attributes or their types. This scheme assumes there are no more than 127 predefined attributes in a notification. Alternatively, this design may use more bits to encode attribute tests. While this marshaling convention orders and groups attribute tests according to the DNF of the attribute filter, an infrastructure element (such as a router) may choose to evaluate the tests in some other order (perhaps according to dynamically derived local data about the probability of success or failure of the different tests) in order to make the overall evaluation of the attribute filter more efficient. The Subscription ID field of the message is a value generated by the agent for uniquely identifying the subscription to the agent's edge router in subsequent requests to modify or unsubscribe the subscription, hi particular, a dynamic modification to the attribute filter of a subscription is propagated using the message format shown in the example of FIG. 18, except that the subject is #.RESUBSCRIPTION and the Subscription ID is that of the previously registered subscription being modified. And an unsubscription is propagated using, for example, the message format of FIG. 18 up through the Subscription ID field, with the subject being #.UNSUBSCRIPTION and the Subscription ID being that of the previously registered subscription being unsubscribed.

The following provides an example to illustrate the conversion and encoding by the agent as described above. Consider the following example attribute filter expression: price >= 10 and (symbol = "LU" or (volume >= 1000 and volume <= 10000)). FIG. 19 presents a Unified Modeling Language (UML) diagram 390 depicting the objects used by the agent in step 362 to store the expression. This diagram illustrates an hierarchical relationship for specifying the subscription, which can include variables, constant values, or both. The objects in the diagram can be instances of filter classes depending upon a particular implementation. Each SimpleFilter object depicts the values of attributes used to store information about a coπesponding attribute test of the filter expression, hi the expression of FIG. 19, an OR filter 396 connects two AND filters 392 and 400. The AND filter 392 contains a simple filter 394 with attributes for the subscription. Likewise, the OR filter 396 contains a simple filter 398, and the AND filter 400 contains simple filters 402 and 404. For the purposes of this example, attributes price, symbol, and volume are assumed to be predefined attributes of the associated channel and are assumed to be defined in positions 0, 1 and 2, respectively. Furthermore, the types of the attributes are assumed to be unsigned integer (typecode 6), character array (typecode 12), and unsigned integer (typecode 6), respectively.

Consider next a subscription containing the above example attribute filter expression as its attribute filter. FIG. 18 presents the marshaling of the subscription into a message. The schematic 386 on the left side of FIG. 18 shows the actual message contents, while the schematic 388 on the right provides a legend for the different parts of the message. The width of each schematic in this example is four bytes. Prior to marshaling, the filter has been converted to its equivalent DNF: (price >= 10 and symbol = "LU") or (price >= 10 and volume >= 1000 and volume <= 10000).

The sixteen-bit attribute test encodings are shown as bit sequences, with gaps showing the separation into the different parts. Note that the two tests on price in this example cannot be combined since they are in separate disjuncts, and thus they are marshaled separately as ranges that have no right bound ("right-open ranges"). On the other hand, the two tests on volume can be combined since they are in the same disjunct, and thus they are marshaled together as a single "closed-range" test.

Finally, note also that certain fields are characterized as being "assumed"; this means that values for these fields were chosen arbitrarily for this example and are in general independent of the subscription that was marshaled. In addition, the subject filter for the subscription was arbitrarily chosen to be ">," which matches any subject defined by the associated channel. The example described above and shown in FIGS. 18 and 19 is provided for illustrative purposes only, and the marshalling can be used with any other type of subscription. Also, method 350 provides only one example of marshaling subscriptions, and they can be marshaled in any other way.

FIG. 17 is a flow chart of an agent method 376 for an incoming message. Method 376 can be implemented, for example, by agent 128 and application 126 in user machine 122. In method 376, agent 128 receives a message from an intelligent router coπesponding with a subscription (step 378). Agent 128 determines a channel coπesponding with the subscription (step 380), for example by the channel ID in the message, and calls an API for the channel (step 382). The API present the data for the subscription in a GUI or other format at the user machine (step 384). The processing of incoming messages can use a process of decoding the data in the reverse of the encoding process described above, and this decoding (reverse encoding) can be performed in a router or in other network entities. Wildcard Processing

FIG. 20 is a flow chart of a wildcard method 410. This method illustrates an example of using a set of routing rules for a filter to convert wildcards in expressions for subscriptions. Method 410 can be implemented, for example, in software modules as represented by agent 128 for execution by processor 134 in user machine 122. Alternatively, wildcards can be processed in the network by processor 93 under software control in intelligent router 92 or in the coπesponding functions contained in ASIC 91. Wildcards include open fields or variable length fields, examples of which are provided in Table 21.

In method 410, agent 128 or other entity receives a subscription having a wildcard (step 412). The subject length for subscriptions can be specified by a publisher when publishing content, and the subject can be pre-processed on the publisher machine, for example, to count the fields of the subject and thus obtain a field count (length) for it. Agent 128 counts the number of fields in the filter operand (step 414) and initializes a new rule (filter) of field length = N (step 416). Agent 128 retrieves a sub-field for the subscription (step 418) and determines if the filter operand sub-field O[i] is a wildcard (step 420). If the filter operand sub-field is not a wildcard, agent 128 adds a conjunctive clause to the rule, field [i] = O[i] (step 422). If the filter operand has more sub-fields (step 424), agent 128 returns to step 418 to process additional sub-fields. The parameter "i" represents a field where i is an integer representing the field number in this example. After processing the sub-fields, agent 128 determines if the last filter operand sub-field is a ">" (step 426) and, if so, it changes the length constraint to field length > N-l (step 428). Wildcard processing can use any type of symbol, and a ">" is only one such example, hi this example, a "a " can mean a.b, a.c, a.d, etc. and all their sub- subjects at all levels (for example, a.b.x, a.c.x, a.b.x.y, etc.). Other symbols can be used for other implementations of wildcards. If necessary, agent 128 propagates the transformed rule to intelligent routers or other entities in the network (step 430). Accordingly, the method iterates through the sub-fields in order to process them for conversion of the wildcards to non- wildcard rules, meaning rules that do not contain wildcards. The conversion of wildcards can occur anywhere in the network, for example on the subscriber machine or in an intelligent router. The conversion can thus occur in one entity with the transformed rule propagated to other entities or it can occur dynamically.

Table 23 provides a summary, along with examples, of these exemplary routing rules for processing wildcards. These routing rules can be generated in the intelligent routers, for example, or generated in other network entities and propagated to the intelligent routers. In addition, the routing rules in Table 23 are provided for illustrative purposes only and other routing rules are possible for converting wildcards.

Reliable Publish-Subscribe System in an Unreliable Network The main function of a publish-subscribe network, such as the publish-subscribe networks described herein (e.g., see FIGS. 1-3) is to deliver matching notifications to subscribers in an efficient and timely fashion. An implementation of the publish- subscribe network requires transmission of notifications from publishers to subscribers in the form of network packets. An unreliable network implies that some of these network packets might be dropped in transit. The major technical difficulty that is overcome by the present embodiment is determining whether the notification (i.e., network packets) was dropped due to transmission eπors or by the filtering mechanism inside the upstream router. FIG. 21 illustrates a method 520 for providing reliability in publish-subscribe networks. In this method 520, a reliable transmission protocol is used. Specifically, the reliability is accomplished by implementing a reliable transmission mechanism (a reliable tunnel) between adjacent router pairs (or between router-user machine pairs). If a router determines an incoming notification needs to be sent to a neighboring router, it uses a reliable transmission protocol, preferably TCP to forward the message. Each router is only responsible for notification delivery to its downstream neighbors (hop distance = 1). Therefore, reliable notification delivery from publisher to subscriber is achieved in a hop-by-hop manner. Method 520 can be executed by a processor 93 under software control in an intelligent router 92 or in the coπesponding functions contained in ASIC 91. Method 520 can also be implemented, for example, in software modules, e.g., as represented by an agent 105 for execution by a processor 114 in a user machine 100.

The use of TCP was found to overcome problems associated with incorporating a reliable transmission protocol with the content-based routing of the publish-subscribe systems describe herein and is prefeπed. Another technique which may be used in a publish subscribe system is forward-eπor coπection. Forward-eπor coπection sends multiple notification packets to the receiver in the hope that one of them will get through. This increases the probability that a packet will be received, at the cost of increased bandwidth use, but does not guarantee delivery. Reliable multicast is a third technique, it ensures that a set of multicast receivers receive the "same" set of packets from the multicast sender. This inherently does not work well with a CBR publish-subscribe system since different receivers will necessarily receive different sets of notifications depending on the different subscriptions.

A node in a publish-subscribe network receives, via the network, a subscription to content (step 522). Content received from a publisher is published via the network, using CBR based upon the subscription, by receiving a notification concerning the content at a node in the network (step 524), determining if the notification is to be forwarded to a neighboring node (step 526), and selectively forwarding the notification to the neighboring node, based upon the determination, using a reliable transmission protocol (step 528). These steps are preferably performed according to any one of the CBR methods described above. The reliable transmission protocol used in step 528 preferably is TCP. TCP is a communications protocol on the transport layer of the OSI model. TCP provides transport functions, which ensures that the total amount of bytes sent is received coπectly at the other end. Accordingly, the forwarding step 528 is done on a single node-to-single node basis, and if there is a transmission failure, the forwarding step 528 includes receiving an indication of a failure in the transmission of the notification (step 5281) and retransmitting the notification in response to the indication (step 5282). The request for such an indication of failure is preferably encapsulated in the packets of the notification. The notification packets are preferably kept in a buffer in case they need to be retransmitted. If the buffer for a particular neighboring node gets full, delivery to that node may be stopped, the packets may be dropped on a FIFO basis, or the packets may be stored in secondary storage. Alternatively, if a certain quality of service (QoS) has been guaranteed to certain publishers or subscribers, the packets may be selectively dropped from the buffer based on QoS (e.g. , those packets not governed by a QoS will be dropped first).

As seen in FIG. 21, the method may be repeated for next neighboring node if further routing is needed at the neighboring node (step 530). This illustrates that the method 520 achieves reliable notification delivery from publisher to subscriber in a hop- by-hop manner.

Filter Propagation

Content-based routing (CBR) is a form of constraint-driven routing, hi a publish- subscribe network enhanced with CBR functionality, such as the publish-subscribe networks described above (e.g., see FIGS. 1-3), a subscriber's interest in publications of specific content (i.e., a subscription) are preferably encapsulated in entities called filters. The filters are preferably used by routers in the network to make routing decisions. Unlike previous filtering schemes that could only be executed at the edge or the user end, the present CBR scheme capable of operating in the network core involves the propagation of these filters. If subscribers are given the capability to place constraints on the content of the packets they receive, and if these content constraints are used in the core of the network to route packets, both the efficiency and the functionality of the network will greatly benefit from CBR. The embodiment described herein provides a family of highly scalable filter propagation methods so that (i) the filters can be propagated into, out of, and/or throughout the core routers along the data paths between publishers and subscribers, and (ii) CBR can be conducted upstream, within the network core and not just at the edge of the network, if desirable. By conducting the CBR further upstream (e.g. , in the network core, or as far as the publisher's machines), the number of data packets that need to be routed downstream often can be drastically reduced. As a result, the traffic load on the network can be reduced.

The filter propagation methods described herein cover aspects of propagating content filters in any name and any form into, out of, and throughout the core of the network. The propagation of filters has many aspects and involves many issues. One important issue addressed by the filter propagation methods described is avoiding the buildup of large numbers of filters as the filters move "up" the propagation stream from a huge number of filter sources (e.g., subscriber) to a few filter destinations (e.g., core router, edge router or publisher). This issue is otherwise known as the "accumulation" problem, and it happens for example in networks composed of cascaded nodes connected in a tree-like topology.

The solutions designed to address this and other issues may include one or more sets of rules, procedures, policies, processes, mechanisms, protocols, message formats, data structures, and/or algorithms. Through these solutions, filter propagation can be made: fast (e.g., through simplification, merging, efficient marshalling, etc.); scalable (e.g., through merging, approximation, etc.); dynamic (e.g., new subscription, un- subscription, repair, etc.); secure (e.g., authentication); private (e.g., encryption); reliable (e.g., TCP connection, reliable tunnels, encoding, recovery protocol, etc.); flexible (e.g., lazy propagation (see below), various multicast topologies or protocols); and, adaptive to the need of users (e.g. , publisher/subscriber behavior-encoding). The filter propagation methods described herein utilize these solutions to achieve these benefits and other benefits.

A. Network Topology - Filter Propagation Strategies

A publish-subscribe system can be implemented with a multicast, broadcast or mobile publish-subscribe strategy. Filter propagation may be embedded in the network topology or executed "on top" of or in addition to the network topology imposed by the strategy chosen for linking publishers and subscribers. Alternatively, the filter propagation strategy may also be the very strategy for linking publishers and subscribers, such as in a publish-subscribe scheme involving advertisements of publications where subscriptions embedded with filters can be delivered directly towards the advertising destinations.

Within the multicast category, the filter propagation may use a protocol consistent with that used for multicast (e.g., protocol independent multicast - sparse mode (PEVISM) and - dense mode (PIMDM), Core-Based Tree (CBT), distance vector multicast routing protocol (DVMRP), multicast open shortest path first (MOSPF), etc.). Depending on the protocol used, the filter propagation can be bi-directional or unidirectional, and many filter propagation strategies are possible. Strategies include one or more the following examples: 1) all filters are propagated to all possible upstream links when they are received (the eager propagation scheme); 2) filter propagation is initiated in response to incoming publishers' packets (the lazy propagation scheme); 3) propagation takes place in response to broadcast advertisements by publishers; 4) propagation takes place after computation of network topology (e.g., MOSPF); 5) filter propagation is periodic (for example, to satisfy the refreshing requirement in a system that supports filter time-outs); 6) filter re-propagation is required during the repair of a fault in the network; 7) filter re-propagation is required during the re-configuration of the network; and/or any combination of the above. The strategies are preferably subject to the filter propagating methods and rules described herein.

B. Link-Level Connection Mechanism for Filter Propagation

The manner in which the source and the destination involved in a filter propagation process are connected may vary. For example, the source and destination involved in a filter propagation process may be connected: 1) hop-by-hop (e.g. , router to router); 2) end-to-end (e.g., user machine to cache in an off-line data retrieval); 3) using tunnels; 4) using transmission control protocol (TCP); 5) using user datagram protocol (UDP) (e.g., supplanted with reliable data recovery mechanisms); 6) using a security protocol; 7) using other protocols; 8) taking place only within the kernel at routers and/or user machines; 9) involving only user-level processes at routers and/or user machines; 10) involving both the kernel and user-level processes at routers and/or user machines in all possible combinations (e.g., kernel-to-application, application-to-kernel-to- application, etc.); and/or, 11) any combination of the above.

C. Destination of Filter Propagation Filters can be injected anywhere in the publish-subscribe network, as given in the following examples: 1) all routers and user machines forming end-to-end connections between publishers and subscribers; 2) every router in the network including the edge routers; 3) core routers only; 4) edge routers only; 5) subscriber machines; 6) publisher machines; 7) administrator machines; 8) cache; 9) backup routers; 10) any routers where packets may be diverted; 11) new routers involved in a network repair or fault recovery; and/or, 12) any combination of the above. The filters are preferably modified through approximation, merging and other processes. For each of the destination categories above, the form of filters being propagated may be different.

D. Source of Filter Propagation

A filter propagation source may be anywhere in the publish-subscribe network.

Examples can be found above in section C. Likewise, the filters are preferably modified, through approximation, merging and other processes, during propagation, and so they often take on different forms from different sources. E. Potential Filter Recipient Behavioral Rules

Filter propagation may also vary depending on the behavior and needs of potential recipients. For example: 1) publishers located at a permanent or semipermanent location want filters to be propagated towards them; 2) mobile publishers may not want filters to be propagated toward their location because they are moving away soon; 3) small-volume publishers who are only publishing a few publications before logging off do not need filters; 4) large- volume publishers may want filters to be propagated before sending the first sets of publications to save network bandwidth; 5) publishers with restricted access authorization may be denied filter propagation to protect the privacy and confidentiality of the subscribers in that application; 6) core routers implementing a filter time-out strategy need periodic updates from downstream routers; and/or, 7) edge routers that are not in constant connection with the subscriber machines may request periodic updates of subscription or filter interest. All these behavioral properties and others can be differentiated, for example, by using publisher advertisements, encoding publisher behavior in its first publication, periodic fransmission of filter updates, and other techniques to convey the need of the filter recipient.

F. Filter Sender Behavioral Rules Likewise, filter propagation may also vary depending on the behavior and needs of filter senders. For example: 1) a subscriber may only want to submit temporary filters with a (system-defined or user-defined) time-out; for example, if he/she is interested in sampling publications; 2) subscribers are mobile, and filters should expire after the subscribers have moved; 3) subscribers not in constant connection with their edge routers may be requested to send periodic filter updates in a CBR system supporting automatic filter time-outs; 4) some policies may dictate that subscribers need to be authenticated before propagating their filters; 5) routers in a CBR system that supports automatic filter time-outs would need to send periodic filter updates; 6) specific queries for only a fixed set of data may involve or may be implemented by filters (e.g., data from cache responding to a query or subscription, persistence backup data, data being recovered during a fault recovery, etc.); and/or, 7) routers that have modified filters for propagation may indicate to upstream routers how the propagated filters are modified based on sender needs. All these behavioral properties and others can be supported for example by encoding the behavior in the filter propagation messages or by using special protocols (e.g., for authentication).

G. Processing of Filters Being Propagated

The processing of filters may involve transformations that modify the content or representation of the filters and or management functions that merely organize the filters. The original filter expressions in a subscription may undergo different sets of processing procedures in different parts of the data delivery path, which includes the following path sections: 1) from the subscriber machine to the edge router; 2) from the edge router to a core router; 3) between two core routers; 4) from a core router to the edge router on the publisher end; and, 5) from the edge router to the publisher machine. Some examples of these transformation processes are described above (e.g. , see Agent Processing and Wildcard Processing). These processes may be executed throughout the publish- subscribe network, e.g., on subscriber machines, publisher machines, edge routers or core routers. Components such as agents (on subscriber and publisher machines) and daemons (on routers) may execute these processes. The processes may include the following examples: 1) attribute content translation (e.g., from subject names to subject ID, from strings to their lexicographical values, from one cuπency to another); 2) expression expansion (e.g., from wildcards to their constituents); 3) expression translation (e.g., > operator to >= operator, != operator to > and < operators); 4) transformation of representations (e.g., from a string representation to a numeric or symbolic representation, such as a polish notation, notations involving brackets, or to a representation pertinent to the specific data structure used for storing or matching filters, such as a tree, a radix trie, etc.); 5) encoding/decoding (e.g., checksum); 6) encryption/decryption; 7) machine-level marshalling and un-marshalling; 8) protocol-level marshalling into and un-marshalling from predefined filter propagation message format; 9) decomposition (e.g. , into

Disjunctive Normal Form (DNF)); 10) simplification to remove redundant predicate expressions (e.g., $1 > 5 && $2 > 3 && $1 > 3); 11) subsumption of two or more filters; 12) approximation of a filter before and/or after merging; 13) merging of two or more distinct filters (e.g., based on approximation); 14) grouping of two or more distinct filters (e.g., for propagation to different uplinks); 15) un-subscription or removal of filters; 16) expiration of filters; 17) delta updating of filter (e.g., bookkeeping an old filter set in any representation and subtracting from it the new one to obtain the changes in the filter configuration, i.e., the delta update); and/or, 18) formation of filter patterns (e.g., filter 2 to be matched if filter 1 is matched). Any process involved in filter propagation, listed or unlisted above, may be utilized by the filter propagation method described herein.

H. Content and Format of a Filter Propagation Message A message may be used to send or propagate a filter. The content and format of the message containing the filter being propagated may be affected by the transformation processes the filter has undergone and, during its propagation, the circumstances triggering the filter propagation. The following are exemplary formats: 1) any message layout at machine or user level; 2) filters may involve attributes in fixed or random positions (e.g., string matching with any part of the publication); 3) filters may involve fixed-size (e.g., integer, boolean, etc.) or variable-size attributes (e.g., arrays, strings, c structures, etc.); 4) filters may involve simple (e.g., integer, boolean, etc.) or complicated data types (e.g., aπays, strings, range variables, etc.); 5) filters may involve simple (e.g., >, =, <=, etc.) or complicated tests or operators (e.g., membership test, regular expressions, string matching, range operators such as intersection queries, enclosure queries, containment queries, etc.); 6) decomposed DNF format; 7) simplified or original representation of filters; 8) compact or expanded format (e.g., a one-sided filter can be represented using a 2-limit expression or a two-side filter can be rewritten as two onesided filters); 9) partial representation of filters (e.g., truncation of string predicates, reduction of data type resolution, and reduction in the number of attributes); 10) transformed representation of filters (e.g., polish notation, brackets, tree, trie, etc. ); 11) inclusion/exclusion of the subject field (e.g., subject filtering could already be implemented by the multicast backbone on which filter propagation takes place); 12) expansion of wildcard subject or attribute predicates; 13) translation of content or expression; 14) encoding information (e.g., eπor-coπecting checksum, etc.); 15) encryption; 16) full set of filters (e.g., during a fault recovery, refreshing updates in a system with filter time-outs); 17) partial set of filters (e.g., subsumed filters, only new filters to be inserted or old filters to be removed); 18) modified set of filters (merged filters, approximated filters); 19) delta changes in the filter representation that do not resemble the filters (e.g., changes in a radix tree during the insertion and removal of filter); 20) identification label of a filter instead of its coordinates (e.g., during an un- subscription); 21) time-out parameters for filters; 22) filter patterning information; and/or, 23) information encoding the behavior and the requests of filter sender as described in section F. This list represents only a sample of possible content and formats of a propagated filter that may be used in the methods described herein.

I. Procedures and Policies for Filter Propagation At the system level, policies and procedure may be instituted to govern or some all aspects of filter propagation. These aspects may include, for example: 1) administering (e.g., global shutdown and restart); 2) maintenance (e.g., fault recovery); 3) filter persistency (e.g., expiration time-outs, one-time filtering of cached data); 4) performance enhancing policies (e.g., load balancing, edge selection, eager versus lazy propagation); 5) monitoring (e.g., fault reporting); 6) accounting (e.g., statistical bookkeeping); 7) billing; 8) regulating (e.g., authority to propagate filters, type of filters allowed in the network, etc.); 9) user authentication; 10) user assistance (e.g., directory service for subject filtering); 10) subscriber privacy (e.g., filters should be hidden from others); 11) synchronization (e.g., acknowledgment to subscribers when filters are received by the edge router, acknowledgment to subscribers when the filter propagation is completed, acknowledgment to repairing routers during recovery, etc.); 12) prioritization, and/or 13) any policy determining and regulating automatic filter injection (e.g., consumer relation management which automatically injects filters that may be of interest to consenting customers, based on the interest shown in the filter set they have injected themselves).

Many aspects and possible features of filter propagation have been thoroughly discussed above in Sections A to I. The feasibility of filter propagation, however, rests on finding a scalable solution to the "accumulation" problem described above. A method and apparatus to implement scalable filter propagation is provided as follows. As discussed above, an important issue in filter propagation is avoiding the buildup of large numbers of filters as the filters move "up" the propagation sfream from a huge number of filter sources (e.g., subscriber) to a few filter destinations (e.g., core router, edge router or publisher). This issue is otherwise known as the "accumulation" problem, and it happens for example in networks composed of cascaded nodes connected in a tree-like topology. FIG. 22 A illusfrates a filter propagation method 450 that addresses the filter accumulation problem. The method 450 illustrates an example of using a set of the solutions described in sections A-I above for propagating filters in a publish-subscribe network. The method 450 can be implemented, for example, in software modules as represented by an agent 128 for execution by a processor 134 in a subscriber machine 122. Alternatively, the method 450 can be executed by a processor 93 under software control in an intelligent router 92 or in the coπesponding functions contained in ASIC 91. Further, the method 450 can be executed by a combination of these.

As shown in FIG. 22A, a plurality of filters is received (step 452). As described above in section C, the filters may be injected anywhere in the publish-subscribe network. The received filters are processed to reduce the number of filters (step 454). The reducing step reduces the number of filters being propagated in order to avoid or reduce the filter accumulation problem. If too many filters are accumulated at one node in this publish-subscribe network, as in cases where there are a lot of immediate downlink nodes to the cuπent node, or where the cuπent node is at a very late stage of the filter propagation path, publishers and routers can be overwhelmed and network efficiency will suffer because of the huge computational load required to process and match all the filters.

The following further illustrates the effect of the filter-reducing step 454. There are many downstream nodes and only one or a few upstream nodes involved in each stage of the propagation path. If each downsfream node at a particular stage reduces the number of filters it will propagate to an upstream node by a factor close to or not much smaller than the number of downstream nodes at that stage, the total number of filters accumulated at the upstream node will be of the same order of magnitude as the number of filters of each of its downstream nodes. By induction, it can be seen that this reducing factor ensures that the number of filters at each destination of the filter propagation will never grow much faster than the number of stages in the propagation path, thus effectively solving the accumulation problem.

FIG. 22B illustrates prefeπed sub-steps of the reducing step. These sub-steps preferably include simplifying filters to remove redundant predicate expressions (step 4542), grouping filters coming only from downlinks relevant to a subject (step 4544), and within this group of filters, approximating filters (before or after merging) (step 4546), clustering filters according to their relative distances (step 4548), subsuming filters (step 4550), and merging of two or more filters (step 4552). These steps may be performed in a different order than shown, and some of these steps may be omitted. Simplification is described above in Agent Processing, with reference to FIG. 16.

The filter grouping step 4544 is important for sending the coπect filter information upstream. Some examples of its importance are given below. For example, a router may have many downlinks (e.g., links to downstream routers). Not all of the downlinks have subscribers sending subscriptions or filters to them. For another example, in a bi-directional multicast scheme, each link to a router can serve as both an uplink and a downlink because publishers and subscribers are allowed to join the network from any arbitrary direction. When a filter request is received from a link, this link should be regarded as the cuπent uplink, and only filters injected from those downlinks belonging to the same subject and apart from the cuπent uplink should be grouped for subsequent approximation, clustering, subsumption and merging operations.

Grouping 4544 may also be needed for other purposes, such as accounting and network traffic confrol. It may even be omitted altogether in some situations, for example, when the global map of filters coming from all the links is required for any reason.

Approximation, step 4546, modifies filters to capture more, rather than fewer, publications. For example, approximation may reduce the number of predicates in the representation of the filter being propagated, reduce the resolution of the filter coordinates, or truncate a long string to the first 12 characters. Approximation has the effect of aligning the formats of the filters so that they may become better candidates for subsumption and merging (steps 4550, 4552). The approximation step also reduces the size of the message propagating the filter.

Subsumption, step 4550, eliminates filters that are a sub-set of another filter. For example, if a first filter is for all condos with an area greater than or equal to 1000 ft² and less than or equal to 1300 ft² and a price range of greater than or equal $200K and less than or equal to $300K, and a second filter is for all condos with an area greater than or equal to 1100 ft² and less than or equal to 1200 ft² and a price range of greater than or equal $225K and less than or equal to $275K, the second filter is a subset of the first filter and, therefore, is eliminated by subsumption. Steps 4542, 4544, 4546, 4548, 4550, and 4552 may be performed in any order, depending on the specific filter reduction scheme and/or algorithm chosen. For example, that steps 4546 and 4550 maybe interchanged. Approximation may take place after subsumption. Further, steps 4550 and 4552 may be integrated and performed as a single step. For example, merging could include subsumption, as shown in the graphs below.

With continued reference to FIG. 22B, merging, step 4552, is similar to subsumption in that it combines two or more filters. Merging, however, may use approximation to combine two or more filters that are partially or completely distinct. Viewing various filters geometrically illustrates this process. For example, see Graphs 1-4 below:

Graph 1 geometrically illustrates two filters, si and s2, that may be reduced through subsumption, since filter s2 is a sub-set of filter si, as described above. In graph 2, however, neither filter s3 or filter s4 is a sub-set of the other. Rather, filters s3 and s4 partially overlap. The merging step 4552 merges s3 and s4 by approximating the minimum filter sA that encompasses both s3 and s4. Since s3 and s4 are both sub-sets of sA, s3 and s4 are subsumed into sA. Graph 3 illustrates another example of merging; in graph 3, filters s5 and s6 are completely distinct. The merging step 4552 approximates a filter sA that includes s5, s6 and the area between these filters. Filters s5 and s6 are then subsumed into sA. Graph 4 illusfrates yet another example of merging in which the filters s7 and s8 are only partially distinct for one attribute. Since s7 and s8 overlap for one attribute and have the same value for the other attribute, the merging step 4552 simply merges the two filers together into sA, subsuming the overlapping portion.

As can be seen, subsumption (step 4550) and merging (4552) depend on locating filters close to one another. To obtain efficiency over that of a linear search through the entire list of filters, clustering algorithm may be used as an optional step (step 4548) to collect filters with boundaries close to or overlapping one another. The clustering algorithm can be performed incrementally in real time as filters are added or removed. Fixed-size or variable-size grids of any granularity over the attribute space of filter attributes can also be used to group filters based on their respective grid coordinates.

The portions of sA that are not covered by either s3 or s4 or s5 and s6 are refeπed to as the leakage area (or relaxation area, redundant area, etc.), in that these portions will capture publications that are not requested by s3 or s4 or by s5 or s6. The merging step 4552, therefore, sacrifices or trades leakage for filter reduction. However, as greater approximations are made, the leakage area may reach a point at which it is too large to be offset by the benefits of filter reduction. Therefore, the publish-subscribe network in which the method 450 is being executed preferably has a defined leakage area threshold that is used in the merging step 4552 to determine whether the leakage area for each approximation is too large. The merging step 4552 preferably performs a statistical analysis on the leakage area to determine what anticipated percentage of additional packets will be received due to the approximation (i.e., packets falling into the leakage area). This statistical analysis may be based on packet distribution profiles built using a history of incoming packets or that of outgoing packets (e.g. , at the router performing the method 450). If the anticipated percentage exceeds the leakage area threshold, the approximation is not used.

The leakage threshold is typically a percentage figure, and more than one threshold can be used as criteria for merging. For one example of leakage threshold, in Graph 3, if leakage threshold #1 is specified as 10% of the number of packets that would be accepted by the actual filters s5 and s6 involved in the merging step 4552, and if it is estimated that the leakage area might contain 20% of the total packets falling in filters s5 and s6, the merging operation may be disallowed. For another example of the leakage threshold, in the same graph, if leakage threshold #2 is 2% of the total number of packets passing the router, and if it is estimated that the gap between filters s5 and s6 might constitute 1% of the total number of packets passing the router, the merging operation may be permitted even though the first leakage threshold (#1) is exceeded, because the overall leakage is still a small percentage of the packets that would consume the bandwidth downstream if they are routed without filtering. A large number and variety of interplays between various leakage thresholds can be designed and specified.

The leakage area threshold may be dependent on the number of filters merged, the area of the filter coverage, or any characteristics of the filter distribution. For example, when the total number of filters is small, a tighter constraint may be used for merging filters, as the accumulation problem is not imminent.

As illustrated by graph 4 above, it should be noted that not all merging operations are approximate. A merged filter sA, that is composed of two or more distinct filters, may have zero leakage area in certain situations and is therefore exact. For example, assuming two-dimensional filters (i.e., s7 and s8 in Graph 4), when the two rectangles representing the filters are aligned with and contiguous to each other, leaving no gap between them, the merging step 4552 resulting in filter sA will be exact. In general, in multiple dimensions, this situation could happen if two or more filters have overlapping or intersecting predicated ranges for one attribute and the same predicated range for any other attribute. Likewise, if the predicated range for a filter begins at the next possible value (e.g., for an integer-only attribute) after the predicated range for another filter ends, these filters may be approximated by a merged filter sA with zero leakage area, assuming the same predicated range for any other attributes of these filters. Referring back to FIG. 22A, the method 450 may alternatively include additional filter processing (in addition to that in step 454), such as the filter processing described in section G above. As shown, the method 450 determines whether to propagate the filters based on recipient behavioral rules (step 456), examples of which are given in section E above. The determining step 456 preferably checks whether filters (and/or what filters) are to be propagated to the potential recipient. For example, the potential recipient may be a mobile publisher that has sent a request not to propagate filters to the node (e.g., edge router) to which it is attached. Alternatively, the potential recipient may be a new publisher that has sent a request to propagate all filters to the node to which it is attached before it will start publishing a huge amount of content. Other potential recipient behavioral rules, such as those listed in section E, may be used. The order of steps 458 and 456 is interchangeable. Additionally, some steps such as step 454 (specifically, the merging substep 4552) and step 456 are optional, for example, for a limited number of subscriptions (i.e., filters) or a network composing only a few stages of propagation because filter accumulation is not yet a serious problem. A determination whether to propagate the filters based on sender behavioral rules

(step 458), examples of which are given in section F above, may also be made. For example, the filter sender may have included a filter time-out. In this case, the determining step 458 checks the filter to see if the filter has expired. Also, the filter sender may need to be authenticated for the filter to be propagated to the next node. In this case, the determining step 458 may reject the filter if its origin cannot be authenticated. Other filter sender behavior rules, such as those listed in section F, may be used.

As described in section D, this filter propagation procedure 450 may be initiated from anywhere in the publish-subscribe network, including the network administrator. The full set or the reduced number of filters is propagated to the next node (step 460). As described above in section C, the next node (the filter recipient) may be anywhere in the publish-subscribe network. The number of filters may be reduced by each of steps 454 to 458. Indeed, the number of filters could be reduced to zero by steps 456 or 458 (e.g., based on a potential recipient rule that says do not propagate any filters). The method 450 may also propagate 460 based on one of the filter propagation strategies for the publish-subscribe network, as described in section A above. Consequently, the propagation step may include determining filter propagation sfrategy and propagating filters based on satisfaction of a requirement(s) of the determined filter propagation strategy. For example, propagation 460 may take place upon receipt of filters or may only take place in response to broadcast advertisements by publishers. Likewise, the method 450 may be executed according to any of the policies and procedures listed in section I above. The method 450 may also format the filter propagation message according to section H above. The manner in which the source and the destination involved in a propagation step 460 are connected may vary, as described in section B above.

After propagation 460, the method 450 may determine if there is another potential recipient (another node) (step 462). If there is another potential recipient, the method 450 determines whether there is any need to repeat the procedure for this potential recipient. There are cases in some publish-subscribe network strategy (e.g., CBT) where filters have no expiration time-outs, and once they have been propagated to one node, they will remain persistent over that link until some changes to the filter set (e.g., filter addition, filter removal, etc.) take place. In those cases, filter propagation becomes unnecessary for that link. One example can be found in the lazy propagation method described below. If filter propagation is needed, the method 450 may determine whether to propagate based on the behavioral rules, steps 456 and 458. The method 450 may repeat until there are no further potential recipients of reduced filters.

FIG. 22C illustrates another filter propagation method 470. This method illustrates another example of using a set of the solutions described in sections A-I above for propagating filters in a publish-subscribe network. The method 470 can be executed by a processor 93 under software control in an intelligent router 92 or in the coπesponding functions contained in ASIC 91. Alternatively, the method 470 can be implemented, for example, in software modules as represented by an agent 128 or 105 for execution by a processor 134 or 114 in a subscriber or publisher machine 122 or 100.

In this example, the network topology is a bi-directional topology with a series of publishers P attached from any arbitrary direction and via any arbifrary path to a network of intelligent routers C, as seen in FIG. 22D. Such a network may be implemented for example by a Core-Based Tree multicast scheme, hi the example, a new publisher, P^N, and a new router C^N, are attached to the network at a router C. The new publisher P^N, in its effort to connect to a particular publish-subscribe network may need to connect to the core through a series of new routers that will form an extension of that network and or may connect through routers that are already part of that network. For illustrative purposes, only 1 new router C^N is shown in Figure 22D. The filter propagation process takes place in 2 stages. In the bi-directional network shown in FIG. 22D, any link can be an uplink or downlink at the same time. For the purpose of the current discussion, the uplink (only one) is defined as the link from which the cuπent filter request is received and a downlink (among many) the link to an immediately downstream recipient of the filter request away from the uplink. Upstream and downstream are directions defined in the same sense as uplink and downlink.

With reference to FIG. 22C, in the first stage, the new publisher P^N broadcasts or multicasts to the downstream router C (or all downstream nodes) a notification requesting filters (step 472). After the filter request is received by the router C (step 474), the router C updates its bookkeeping to ensure that the same set of filters will not be sent twice to the same uplink, preferably by means of reference counting (step 476). The router C then determines whether filter request from this uplink has been serviced before, preferably by means of examining the reference counter for this uplink (step 478). If this is a new uplink that has never been serviced before, as in the case of the first publisher joining the network from this uplink, the router C will relay the request to (step 480) and await a response from the router's downlinks (i.e., downstream routers) (step 482). Those downstream routers in turn transmit the request to their downstream routers and await their response. This process is repeated until the receiving node could make a decision to respond. This completes the first stage.

The second stage begins when any node that receives a filter request has collected the response from all of that node's downstream routers or when that node is the final node in the network and no response is expected from downsfream (step 484). If there are no filters to send, a negative acknowledgment (or a null filter set in any representation) will be sent upstream. If all the new filters have been received from all the node's downstream routers, the entire or partial set of filters (e.g., delta changes) will be sent upstream (step 486) after optional filter reduction (step 454). Only filters collected from the downlinks with respect to the cuπent uplink will be grouped, merged and reduced, according to method 450. This collect-and-then-propagate process is then repeated upstream until the publisher or the initial router sending the filter request receives the filters or the negative acknowledgments from all that publisher's or initial router's downstream routers. The actual propagation of filters or a null set (negative acknowledgment) as described above constitutes the second stage. The two stages differ in their propagation direction as well as the propagated content, and they can overlap in time as the filter request could go further down some branches of the network than others.

Because this filter propagation scheme only initiates the filter propagation process upon reception of a filter request from an uplink, rather than eagerly pumping filters to every uplink, it may be known as a lazy propagation scheme as it pumps filters to only the upstream router requesting filters and only when it requests them. It is noted here that the filter request may not need to be a special-formatted notification. The first notification from any publisher can be regarded as an advertisement of its presence, and the filter recipient behavioral rules encoded and embedded in the data notification can be used to determine if filters are being requested, according to Section E.

Each publisher P's filters may be stored at the publisher user machine 100 or at the router C to which the publisher P is connected. As with the method 450 above, the method 470 may also use additional solutions such as those described in sections A-I above.

CBR Using Compact Filter Storage and Offline Pre-computation

The embodiment of CBR described in this section involves a method for routing data packets in the core of a publish/subscribe network, based on deep packet inspection and filter matching. By transforming filters into more compact forms and by pre- computing the filter coverage in the attribute space, this CBR method forms a map from a finite set of attribute spatial coordinates to routing instructions off-line and then utilizes the map in real time to make routing decisions. This CBR method is very fast, achieving a data-forwarding rate of the same order of magnitude as that of traditional Internet Protocol (IP) routing. Consequently, this CBR method is a suitable candidate for pragmatic commercial deployment of content-based routing in the core of a network.

As described above, subscribers refine the selectivity of packets transmitted from one or many publishers in a publish-subscribe network by specifying predicates over a range of attribute values. Each predicate is an attribute test (attribute tests may include a subject test as well) that relates an attribute in a certain position in the packet to 1 or 2 operands (an operand may be a complex object such as a regular expression) in a relational or membership test. For example, 10 < $l < 20 is a test to examine whether the data value in the first attribute position denoted by $1 is greater than 10 and less than 20 (the definition of a predicate can be simplified by limiting the test to involve only 1 operand, e.g., a 2-sided range test can be broken into a conjunction of two one-sided tests). The subscriber submits a collection of these tests in one or a plurality of subscriptions, each of which may include the subject field of the subscriber's interest.

The embodiments described herein concern content-based routing using filters, which are objects derived from subscriptions and differ from subscriptions only in their representations. One example of filter is the conjunctive filter described below. In a sense, a subscription is the original filter, one that is specified, used for filtering packets and/or sent to the network directly by the subscribers. To facilitate propagation and packet matching at the routers in the network, subscriptions may be converted into objects of other formats called filters. For example, in some implementations, each subject is implemented using a multicast network. Filters that are of the same subject and injected to each node of a multicast network for a particular subject will filter packets only with the same subject field, in effect performing subject field filtering implicitly. Filters can therefore be stored under their subject headings at every node in this network without their subject fields. Filters without subject fields are often known as attribute filters. For the following discussion, the terms subscription, filter and attribute filter may be used interchangeably and its meaning made clear only by their context.

To facilitate the matching of the incoming data packets with these subscriptions, each subscription can be processed and broken down by the proxy into its equivalent Disjunctive Normal Form (DNF), as described above, before being sent to the edge router. A DNF is a disjunction of one or more sub-filters called conjunctive filters. Each conjunctive filter is a conjunction of one or more attribute tests, with each attribute expressed at most once in the expression with the same test operator. For instance, a conjunctive filter may constrain matching of the attribute in position 1 with the expression (attributes other than $1 are included in the following example): $1 > 10 and $1 < 20 and $2 < 4 and $3 = 5 and ...

As far as routers are concerned, attribute filters are all conjunctive filters because of the proxy action. Not only do conjunctive filters have the advantageous property of a uniform format, which facilitates the propagation of these filters in the core of the network, the single occuπence of each attribute in the filter expression also permits the interpretation of these filters as multi-dimensional geometrical objects, which is useful for describing the embodiment of CBR herein. Hence, in the following, only conjunctive filters are used as examples.

Despite the use of DNF, the benefits of the downstream bandwidth gain obtained by using CBR may be easily out-weighed by the huge amount of computation required if a naive method is used to match a large collection of filters one by one and predicate by predicate. This huge amount of computation in the critical data-forwarding path can be a severe drag on publish-subscribe network efficiency. The embodiment of CBR described herein seeks to reduce this huge amount of computation and to move the maj ority of computations out of the critical data-forwarding path.

Indeed, the embodiment described herein provides a very efficient method for CBR by approximating filter expressions into more compact forms and pre-computing the filter coverage information off-line. In this CBR method, the filter coverage over every single point in the attribute space is predetermined off-line when filters are inserted or removed. The coπect action on the packets with attribute values falling on that point will be the union of the actions predicated by all the filters covering that point. These actions may involve the packet, including for example, packet forwarding to a physical or an encapsulated interface, packet diversion to a user-level process, or packet piping to a parallel machine (e.g., cache, backup router, etc.). Some actions may not involve the packet at all, including for example, triggering a general application running on the router to respond to the arrival of a specially designated packet, prolonging the lifetimes of some filters because there are still active publications in the relevant area of the filters, automatically injecting new filters based on the content of the publications, etc. In practice, the actions predicated by each filter can be embodied by a data structure, such as an action bit mask (ABM) with each bit position representing a distinct (forwarding) action, or a list of distinct actions (Distinct Action List - DAL) when the number of actions becomes too unwieldy to be placed in a bit mask (e.g. , an edge router connecting a huge number of subscribers). In the following discussion, when ABM or DAL is mentioned alone, it should be understood that the context covers all forms of action- embodying data structure.

The pre-computation thus generates a CBR map from a number of coordinates in the attribute space to the same number of unions or lists of actions. As this simple map is similar to the Multicast Routing Table used in subject group multicast, it can be known as the CBR Table. As can be seen, by shifting the heavy computational load from the critical data-forwarding path to the non-critical filter pre-computation processes running in the background, data can pass very quickly through the critical data-forwarding path almost free of the processing required for matching the original filter expressions.

This CBR method also preferably includes approximating the filter expressions to more compact forms, for example by means of spatial quantization and predicate reduction. Because there are a huge number of coordinates in each attribute dimension, the attribute space must be quantized, forming a grid. Only the quantized regions instead of individual coordinates are used to construct the CBR table. Because spatial quantization has the effect of grouping individual points in the real attribute space into a single point in the quantized attribute space, every point in the original real attribute space is still indirectly accounted for in the CBR table, sharing with its neighboring points with the same quantized coordinates the list of actions predicated for those quantized coordinates.

Various spatial quantization schemes are allowed in this method. In addition, when a filter expression contains too many predicates, it may be approximated to only the subset(s) represented in the CBR table(s).

The attribute space for an attribute is potentially infinite. Consequently, even with the grid, the attribute space may be too unwieldly. Therefore, the method of CBR described herein preferably reduces the area of the attribute space that is quantized. Specifically, preferably only that area of the attribute space for which matching data packets are expected to be received is quantized. As described below, this area for which matching data will possibly be received is determined based on information received from publishers and/or on a statistical analysis of past (i.e., previously received) packet and/or filter distribution. For example, if a publisher provides information that matching data packets for above a certain value of an attribute will never be published, the attribute space above that certain value preferably is not quantized. Likewise, if statistical analysis shows that filters for below a certain value of an attribute have never been received, the attribute space below that certain value preferably is not quantized.

FIG. 23 A illusfrates a method 480 of CBR by approximating filter expressions into more compact forms and pre-computing the filter coverage information off-line, according to the embodiment described herein. This method of CBR minimizes real time predicate-by-predicate filter matching. Method 480 can be executed by processor 93 under software control in intelligent router 92 or in the coπesponding functions contained in ASIC 91. Typically, because the pre-computation step, which involves filter management functions, is computationally intensive, it is preferably done in software. However, in some filter representations such as the radix representation, it is also possible to maintain the filters in hardware. Method 480 can be implemented, for example, in software modules, e.g., as represented by agent 106 for execution by processor 114 in user machine 100. As shown in FIG. 23A, the method 480 first determines whether it is time to perform spatial (re-)quantization (step 482), which can be triggered by a periodic or aperiodic time-out, or by a pre-defined event such as the observation that the packet statistics has become overly uneven across the cuπent quantized attribute space. Spatial quantization is performed off-line if needed and when the router is relatively idle (step 484). Spatial quantizing involves the computation of a new grid that will preferably have the property of rendering either the packet distribution or the filter distribution (or some coπelation of the two) uniform across the resulting quantized attribute space. Other methods and criteria for spatial quantization can be used.

The grid area may be constructed to only cover a reduced area of the attribute space in which matching packets are expected to be received. For example, if the first attribute $1 represents the number of stocks in a certain industrial sector in the US, the spatial quantization needs only take place in the range from 0 to a number comparable to the total number of stocks in all the US stock exchanges combined. After the statistical distribution of this attribute can be formed from the packet statistics collected, adaptive quantization, as discussed below, can be used to dynamically adjust this range, initially to a much smaller number that is the maximum of the number of stocks for all sectors, and in the future to higher numbers when the maximum grows.

The router then determines if any filters have been inserted at or removed from (step 486) the network location (e.g., a core or edge intelligent router 92, or a publisher machine 100) at which the method 480 is being executed. A reference-count method can keep track of whether a newly injected filter has the identical information (e.g., attributes, matching attribute values, and filter actions) as another filter previously injected (step 488, step 494). Only distinct filters need to be processed. For the purposes of this description, the location is assumed to be an intelligent router 92. For example, a new filter may have been propagated upstream to the intelligent router 92 or an old filter may have timed-out due to an expiration time-out set for the old filter. When a request to insert or remove a filter is received (step 486), the filter is first compared to the other filters already received and stored by the router using its real coordinates, for the purpose of (1) updating the reference count for the coπect filter in the real attribute space (step 488), and (2) determining if the filter to be inserted/removed is a distinct filter or a filter already received before (step 490). If the filter is not a distinct filter, the execution flow will be passed back to the packet matching routine.

Otherwise, the attribute values of the packet are mapped to the quantized space to obtain the quantized coordinates of the attribute values (step 492). A similar filter identification procedure is performed, this time using the quantized coordinates, for (1) updating the reference count for the coπect filter in the quantized attribute space (step 494), and (2) determining if this filter is a distinct filter in the filter's quantized coordinates (step 496). For step 488 and step 494, two maps of filter coordinates to filter references may preferably be used.

If the filter is distinct in both the real attribute space and the quantized space, the filter can then be approximated and reduced (step 498). For example, only a sub-set of the attributes of a filter with too many predicates may be selected for quantization and mapping. Likewise, attributes with predicates of a more complicated nature (e.g. , predicates requiring string matching, regular expression, in-string, in-aπay, range operators, etc.) or requiring a higher resolution may be handled separately.

One of the key contributions of embodiments of the present invention is the idea that if filters are made compact, packet matching and forwarding can then be performed efficiently in a scalable fashion. The compacting of filters may involve both the mapping of filters to a quantized attribute space (step 492) and the approximation and reduction of the filter expressions (e.g., step 498). As shown, the compacting step includes spatially quantizing the attribute space (step 484). This step forms a grid in the attribute space, as described above and shown below:

The CBR table can now be updated (step 500). Each filter is associated with a rule indicating one or more (routing) actions for publications matching that filter. The (routing) actions predicated by the filter are inserted into the grid cells in this CBR table in the following manner. Using the grid formed in the attribute space of the filter coverage information, step 500 first identifies all the grid cells (i.e., quantized regions) that the quantized coordinates of the filter cover or overlap. Then step 500 inserts into these grid cells the predicated (routing) actions. For example, assuming five possible destination nodes, two filters requiring routing to user machines connected to nodes 2 and 3, respectively may cover the grid cell or quantized region X (see above). As a result, step 500 inserts or affirms the rules respectively requiring routing to nodes 2 and 3 to grid cell or quantized region X. This process is iterated for each of the grid cells identified to be covered or overlapped by the quantized coordintes of the filter. Preferably, step 500 represents the mapping by generating or updating an ABM for each grid cell or quantized region. In this example, the ABM for grid cell or quantized region X, assuming the nodes are numbered 0-4, is:

0 Note, bookkeeping is preferably performed for filter removal. For example, suppose a grid cell is covered by two filters, and one of the filters is removed. The coπesponding bit in the ABM should not be reset to 0. The confusion can be avoided by bookkeeping for each grid cell the reference count of the filters covering the cell area. The FBM is then generated from the updated reference counters. These reference counters may be refeπed to as the action reference counters. Therefore, the mapping step 500 may include a bookkeeping step as described herein.

A CBR table is constructed/updated (step 500) from the ABMs generated for each grid cell or quantized region. This preferably involves, directly or indirectly, both spatial requantization and CBR table updating, and all the supplementary steps 482-500. Steps 482-500 are preferably executed off-line (i.e., when the intelligent router 92 is not receiving published packets) or in the background of the real-time routing process as filters are injected, suspended, paused, or removed. Accordingly, if no published packets are received, or if steps 482-500 are being executed in the background, method 480 again determines first if it is time to re-quantize the attribute space (step 482) and subsequently if any filters have been inserted or removed (step 486). The CBR table is then used in the real-time routing process in the data-forwarding path, as shown in FIG 23B.

The size of the CBR table can be massive for a large number of attributes or a large number of grid divisions for each attribute. In principle, only those grid cells in the CBR table that contain action rules (i.e., those which are covered by filters), need to be stored. The CBR table can be condensed using any technique. Whereas FIG. 23 A illustrates the CBR management aspects of method 480, FIG. 23B illustrates the CBR data forwarding aspects of method 480. If method 480 determines that published packets are received (step 502), the intelligent router 92 receives the published packets (step 504), as seen in FIG. 23B. The received packets can be injected into the network using a point-to-point connection (e.g., wireless connection to an edge router). The received packets are mapped to the grid(s) (step 506). Step 506 determines the quantized coordinates of the packet so that the coπect grid cell of the CBR table can be looked up and the action rules contained in that grid cell can be extracted and used to handle the packet (508). These actions may include determining which nodes or other locations in the network to route the packet, or dropping the packet.

Leakage Reduction

The CBR method 480 presented so far may incur eπor in the form of packet leakage as a result of filter approximation (see step 492). Because the boundaries of the grid cells, instead of the original filter boundaries, are used for matching packets, the actual regions (e.g., area in 2 dimensions and volume in 3 dimensions) used for matching are enlarged, and unwanted packets whose attribute values fall between the actual filter boundary and the grid cell boundary, herein known as the relaxation region, will eπoneously be accepted. As described above, the reduced filter resolution is deemed an acceptable sacrifice when speed performance and scalability are acquired or improved in the process and when the leakage eπor is small in comparison with the total number of incoming packets.

However, the leakage eπor in some cases may not be small. For example, when the system contains filters with at least one of its CBR-enabled attribute predicates being an equality or inequality test (e.g., $1 = 4 & $2 = 100 & $3 < 30, or $1 = 4 & $2 > 3). In the dimensions of those attributes that are equality-tested or inequality-tested, the filter resembles a point. When the grid boundaries are imposed to subsume these points (in step 490 above), the expanse (e.g., area, volume, hyper-volume) of the relaxation region can be much larger than that of the actual filter itself.

This problem is described in the diagram below, depicting a 2-attribute space and showing two point filters FI and F2, both defined by an equality test in either dimension. The numerals indicate the grid cell coordinates and the alphabets the real coordinates. Those packets whose attributes fall into anywhere in grid cell (4, 1) will be accepted as matching both FI and F2.

6 5

4

$2

a b 3 4

$1

Such an undesirable property of the CBR method 480 can be mitigated by various techniques that may be performed in the leakage reduction step 516, one of which is described below as an example.

One such technique for leakage reduction 516 involves exact matching in one dimension (ID). Matching packets to filters exactly for all the attributes at the same time is a multi-dimensional problem that does not have a scalable solution. Exact matching in ID is however known to have many efficient and scalable solutions, including but not limited to: (1) a binary search on an aπay of filter boundaries; (2) a binary tree search through all the filter boundaries; (3) a radix search down a tree embedded with the filter boundary information; and, (4) a search with other more complicated data structures such as a the interval binary search free, etc. hi the leakage reduction step 516, ID exact matching using any ID search technique is preferably conducted for all the attributes. An exemplary leakage reduction step 516 according to ID exact matching is described below: a. Perform CBR matching step 508 without leakage reduction, as described above (if there is no match, drop the packet); b. For packets that match (see step 508 above), select one attribute dimension and match that attribute value of the packet with the projection of all the filter boundaries on that attribute axis, using any ID exact matching technique and its coπesponding data structure. A list of all the forwarding nodes for which a matched filter is found is obtained; c. If there is no ID match, the packet can be dropped because it is guaranteed that no filter will match the packet on all its attribute tests; d. If there is a match, pick another attribute dimension and repeat step b until (i) a mismatch is found in any dimension; (ii) the lists of forwarding nodes produced by all the previously performed ID searches do not contain common interfaces (i.e., the ID matches are generated from filters from different interfaces); or, (iii) the exact matching test is done for all the attribute dimensions, which may include those disabled for CBR; e. If any one of the dropping condition described in step d does not happen, and all the attributes are tested without a mismatch, a decision not to drop the packet can be made. f. In cases where more than one interface is involved, the interfaces for which the packet is not dropped must be compared with the list of interfaces obtained from step a. The packet will only be routed to the interfaces in the intersection between the two lists will be routed. Other orders of substeps a-f are allowed. For example, sub-step a may be performed after the ID leakage reduction step (sub-steps b-e) is completed. Some sub-steps may be integrated.

It is noted that the above ID leakage reduction step 516 is not exact when all the dimensions are taken into account. Using the last example, a packet having attribute values $1 - a & $2 = d will pass the exact-matching test in either dimension, but the test in each dimension actually matches a different filter. In a true multi-dimensional analysis, the packet would have been dropped. This leakage reduction is therefore only good for dropping packets and not for accepting packets. For the latter cause, it is only approximate and leakage eπor is still possible. Notwithstanding its inaccuracy, the leakage reduction step 516 greatly reduces the leakage eπor caused by using the entire area in grid cell (4, 1) for filtering.

The data-forwarding path traffic through the intelligent router 92, at which method 480 is performed, is checked to determine if it is above a set threshold (step 510) (i.e., the intelligent router 92 is "busy," e.g., being occupied with the critical task of forwarding packets). If the intelligent router 92 is busy, the packets that map to covered grid cells are routed (step 508) based on the routing actions determined by step 508 (step 512), and the coπesponding packet statistics is updated (step 514). Consequently, if the intelligent router 92 is busy, "leakage" resulting from routing packets that map to a partially covered grid cell, but that fall outside the actual filter coverage in that grid cell, is accepted as a sacrifice to improve routing speed.

If step 510 determines that the intelligent router 92 is not busy (i.e., the traffic is not above the threshold), leakage reduction is preferably performed (step 503). The leakage reduction step 516 reduces the leakage described in the preceding paragraph.

The leakage reduction may be performed, for example, according to the below-described methods.

Up to this point, no exact or predicate-by-predicate filter matching has been performed in real time. However, a minimal level of exact filter matching may be allowed in method 480, preferably only if the fraffic is not above threshold. This CBR method intrinsically groups filters according to their locations with respect to the grid. The grid cells are a tool to group filters according to their geometrical locations. Within any group of filters (alternatively known as filter bucket), detailed filtering at more accuracy can take place for some situations. Such extra matching requirements can be stored in the filter bucket. Some examples include:

1. Attribute tests requiring a higher resolution than provided by the CBR map can be processed after the filter bucket is retrieved from the first grid-matching step of CBR (step 508).

2. Attributes tests of more complicated nature (e.g., string matching, regular expression, in-string, in-aπay, range operators, etc.) are handled by the filter bucketing method.

3. For filters containing a large number of attribute tests, the attributes can be separated into two groups, one group entered into the CBR map and another group in the filter bucket.

The filter predicates for the attributes described in 1-3, may be reduced by step 498 above. Additionally, if the intelligent router 92 is not busy (see step 520), a predicate- by-predicate or other exact filter matching is used to match such packets to the filter bucket determined by the partially covered grid cells, as ascertained from the CBR table. Since the filter bucket for that grid cell or quantized region is aheady reduced (from the total number of filters) by the pre-computation (in steps 482-500), this process is still more efficient that simply doing straight predicate-by-predicate CBR.

Before routing the packets based on the CBR table (step 512) (as determined by step 508), the method determines if there are any reduced filter predicates or packets mapped to partially covered grid cells (step 522) for the filter bucket determined by the mapped-to grid cell. If there are such reduced filter predicates (e.g., from examples 1-3 above) or such mapped packets, predicate-by-predicate or other exact filter matching is performed (step 524). The matched packets are then routed based on the routing actions determined from the CBR table and the exact matching, for example, by intersecting the interface lists obtained by the two methods (step 512) and the packet statistics is updated (514).

In alternative embodiments of the method 480, the fraffic threshold checking step 510 may precede only some of the computationally intensive steps, such as steps 518 and 524, as determined by a balancing of waste versus computational intensity. Further, the method 480 may have separate paths for packets that map to completely covered grid cells and for packets that map to partially covered grid cells. The traffic threshold step 510 may then be only performed in the partially covered grid cell path.

The leakage reduction step 516 in method 480 may be replaced with a more advanced leakage reduction procedure, described herein. The advanced leakage reduction procedure further reduces leakage eπor. For example, exact multi-dimensional matching can be performed within the grid cell by cross-producting after the grid table search. Cross-producting involves the following procedure: a. Perform ID exact-matching as described above, using any ID exact-matching technique. The main difference in this alternative step is that a list of filter labels instead of a list of forwarding nodes is produced; b. If the list is empty (i.e., no matches), the packet is dropped; c. If there is at least one match, the search proceeds to another attribute. Step ac are repeated until any one of the short-circuiting conditions below is met: (i) a mismatch is found in any dimension; (ii) there is no common filter label in all the filter label lists produced by the previous ID tests; or, (iii) all the dimensions have been tested; and d. If any one of the dropping condition described in step c does not happen, and all the attributes are tested without a mismatch, a decision to accept the packet can be made.

For example, in the above diagram, a packet having attribute values (a, d) will produce F2 for the $1 test and FI for the $2 test. Since there is no intersection between the two filter label lists, the packet will be dropped. On the other hand, a packet having attribute values (a, c) will produce F2 in both the $1 and the $2 tests, causing the packet to be accepted. Since this procedure is almost exact even in the final multi-dimensional analysis, it is a test to accept packets and not merely one to drop them. The only approximation that has been made is the truncation of attribute tests in the filters. This problem is not unsolvable. It can for example be circumvented by the following procedure:

1. Create multiple grid tables involving subsets of attributes coπesponding to a subset permutation of the full set (e.g., choose ($1, $2, $3) as one set, ($2,

$4, $5) as the other). A filter with a long list of predicates will be covered by at least one such grid table; or

2. Perform the cross-producting test for all the attributes. The probability of short-circuiting is very high because filters with a large number of predicates are selective in nature, and any one of the packet dropping conditions (e.g., filter label list intersection) outlined in step c above could occur before all the attributes are tested.

Since it is impractical and rare to have a filter containing a large number of predicates, some truncation of the filter expression, though necessary, may occur infrequently.

This hybridized procedure combining spatial quantization and cross-producting and the multi-table lookup approach as described above constitute another key contribution of this patent, in that both methods combined solve the traditional problem of non-scalability often faced by any cross-producting solution, as seen below.

In the case of point filters, the cross-producting solution is exact, hi the case of range filters, however, there are traditionally two problems with cross-producting as a list of filter labels need to be stored between any pair of neighboring filter boundaries. First, the storage is of order N², where N is the number of filters, when the system is injected with range filters that highly overlap each other. Secondly, the list-intersection step is of order N, which can be a very slow process when N is large. The hybridized approach combining the grid search and the cross-producting method reduces both problems to a reasonable size because only those filter boundaries that fall into the same grid cells need to be stored and matched for packets falling into the boundaries of that grid cell. In a way, the grid cells have taken over the role of storing filter label lists from the intervals between neighboring filter boundaries, and since there are fewer grid cells, filter label lists need to be stored.

If the grid is constructed based on the filter boundary distribution, an even number of filters will result in each grid cell interval in any attribute dimension. The storage problem N² becomes less formidable when Nbecomes small. For example, a grid of 32 intervals would have reduced the storage problem by (N/32)² * 32 = N/32. The problem of list-intersection speed is similarly alleviated.

The cross-producting method as described above works as long as the number of grid cells remain practically a small number. The method of dividing attributes into various permutation sets and assigning one CBR tables for each set limits the number of grid cells in each table to a reasonable number. For example, if E is the number of divisions in each attribute axis, the total number of grid cells for k number of attributes would be E . By using the multiple-table (size = 4) method, the size is now reduced to M L⁴, where Mis smaller than the total number of permutations k!/(k-4)!4l. It is noted that some permutations highly overlap one another and only one can be chosen as a representative, (e.g., {$1, $2, $3}, {$1, $2, $4}, {$1, $2, $5}).

A CBR method according to the present embodiment (e.g., method 480) (minus the exact predicate-by-predicate filter matching steps 516 and 524) has at least the following properties: 1) the packet forwarding speed is very fast and comparable to IP routing, requiring only Ofk log(L)] steps, where E is the number of divisions in any attribute axis and k the number of attributes being quantized and mapped. With 4 attributes and 32 divisions per attribute, about 22 steps are required; 2) the packet forwarding speed is a constant in real time. It is not dependent on the number of filters (N). This property makes it possible to estimate the maximum bandwidth capacity sustainable by this CBR method; 3) it is fast for dynamic updating as well. For example, insertion of a filter may take 0(L^k) steps, depending on the implementation; 4) the storage requirement is small and limited, being approximately k (L-l) S_A + N_rL^k / 8, where S_A is the size of the attribute data type in bytes and N_r the number of forwarding interface at the router. The first term is the total size of all k number of the indexing components of the data structure and the latter the actual forwarding component (i.e., the CBR table) being indexed. For a router with 8 interfaces configured with a 4-integer- attribute 32-division CBR, the amount of storage is only 1 MB; 5) the indexing data structure, being separated from the much larger forwarding component, is very amenable to caching. For example, using the example above, the size of the indexing structure is only (4)(31)(4) = 496 bytes; and, 6) the grid is also a tool for grouping and organizing filters. It is useful in particular for merging filters before they are propagated, making this method very scalable in systems comprising a lot of subscribers. In summary, the CBR method 480 is fast, predictable, dynamic, scalable, not memory demanding, flexible, and hence practical for deployment in the core of a publish-subscribe network.

Adaptive Grid

As described above, the grid is formed by spatially quantizing the attribute space. Generally speaking, the attribute space is uniformly quantized. However, if the attribute space is adaptively spatially quantized, e.g., based on past packet distribution, the resolution of the grid, and therefore, the efficiency of the CBR method 480 can be improved. Adaptive quantizing determines region(s) of the attribute space for which the most matching packets are likely to be received. For example, adaptive quantizing may determine the region(s) of the attribute space in which the past packet distribution is most concentrated. The determined region or regions are then quantized to a greater degree than the other quantized regions of the attribute space. In other words, in the determined regions, the number of grid cells will be greater and the size of the grid cells will be smaller than in the other quatized regions of the attribute space. The 2 diagrams below of an adaptive grid illustrate this:

3 4

$1

In the first diagram, a finer grid is superimposed on the regions of heavy packet traffic. In the second diagram, illustrating an alternative method, the grid spacing is changed on either attribute axis so that more grid cells will be finer and more concentrated in the area encompassed for example by quantized coordinates (3, 2), (4, 2), (3, 3) and (4, 3).

The advantages of such an adaptive grid are numerous. As can be seen in this diagram, the region Z has been adaptively quantized, hi the region Z, where there would be four (4) grid cells without adaptive quantizing, there are now sixty-four (64) grid cells. As illustrated in this diagram, whereas the filter coverage information sS previously would have partially covered three grid cells, with the adaptive grid there is only one (1) partially covered grid cell Y. Consequently, the amount of potential leakage is significantly reduced. Further, if one or more of the sixty-four grid cells in the region Z were to be partially covered, the amount of potential leakage in each of these grid cells would be significantly less than in the partially covered grid cell Y. This is because the relaxation region in each of such partially covered grid cells in the region Z would be significantly smaller than the relaxation region in the partially covered grid cell Y. Therefore, the efficiency of the CBR method 480 can be improved by using an adaptive grid. The second method has the advantage of not increasing the storage demand as the first method does because the same number of grid cells is generated. However, it also provides less accuracy as the former method. Implementing Query-Response With a Publish-Subscribe Architecture

Described herein is a family of methods for using publish-subscribe networking to support query-response style interaction. The methods involve different mappings from the primitive absfractions of the publish-subscribe style, namely publications (also called notifications) and subscriptions, to those of the query-response style, namely advertisements (also called offers), queries and responses. Additional variations distinguish between the use of singleton advertisements and queries (which characterize a single content item) and set advertisements and queries (which characterize a plurality of content items) .

As described above, in a publish-subscribe network, publishers create and distribute content items called publications or notifications. In many systems, this information is structured as a tuple of typed attributes, and in some systems a distinguished attribute called a subject is used as a primary classifier for the notification. Subscribers create and distribute subscriptions, which characterize the notifications in which they are interested. A notification is typically a singleton content item, while a subscription typically uses a complex expression to characterize a set of notifications of interest. The same entity can act as both publisher and subscriber. Interaction takes place by having publishers push content items to subscribers. This push delivery respects a certain temporal order among subscriptions and notifications; in particular, a notification is matched only against subscriptions that are active at the time of the notification but not against future subscriptions.

A different form of interaction, the query-response style, underlies many common distributed applications, including Web search engines and peer-to-peer content sharing systems, hi a query-response software application, an entity called an advertiser or producer makes available content to other entities, and it makes the existence of this content known via advertisements or offers characterizing singleton content items or sets of content items it is able to provide. Another entity called a requester or consumer broadcasts queries or requests that characterize singleton content items or sets of content items of interest. The application is then responsible for locating matching advertisements and delivering them as responses to the consumer. Interaction thus takes place by having consumers pull both advertisements and the content items themselves from producers. This pull delivery respects a certain temporal order among advertisements and queries; in particular, a query obtains responses only about the advertisements that are active at the time of the query but not about future advertisements. The embodiments described herein are a family of methods for using the push- style interactions of publish-subscribe to support the pull-style interactions of query- response. The following describes five exemplary methods to achieve this.

1. FIG. 24A is a flowchart illustrating a first query-response method 600 using a publish-subscribe system. Method 600 may be executed using a variety of publish-subscribe systems. For example, method 600 may be executed by processor 93 under software control in intelligent router 92 (or in the coπesponding functions contained in ASIC 91) and implemented in software modules, e.g., as represented by agent 128 and 105, for execution by processor 134 and 114 in user machine 122 and 100.

In method 600, a publish-subscribe network is used to match advertisements to queries, whereby an advertiser uses a subscription to register a singleton or set advertisement (step 602), and a requester uses a publication/notification to distribute a singleton query (step 604). In other words, a singleton or set advertisement is mapped to a subscription and a singleton query is mapped to a notification. Any matching notification is pushed to the advertiser by the publish-subscribe system performing CBR using the subscription (the advertisement) as a filter for the notification (the query) (step 606). The CBR may be performed according to any of the above-described methods using the above-described infrastructure. The advertiser receives the notification and returns responses to the requester (step 608) via some non-publish-subscribe means (e.g., a unicast connection to the requester) or via an agreed-upon convention using the publish-subscribe network (e.g. , requiring the requester to register a separate subscription (coπesponding to the requester's notification) in order to receive the responses, which are delivered as notifications).

FIG. 24B is a sequence diagram further illustrating the method 600. FIG. 24B depicts the interaction between the advertiser (e.g., using publisher machine 100), the CBR infrastructure (e.g., network of intelligent routers 92), and the requester (e.g., using subscriber machine 122). The sequence diagram illustrates that multiple processors (e.g., processor 93, processor 114, and processor 132) preferably execute method 600. 2. FIG. 24C is a flowchart illustrating a second query-response method 610 using a publish-subscribe system. Method 610 may be executed using a variety of publish-subscribe systems. For example, method 610 may be executed by processor 93 under software control in intelligent router 92 (or in the coπesponding functions contained in ASIC 91) and implemented in software modules, e.g., as represented by agent 128 and 105, for execution by processor 134 and 114 in user machine 122 and 100.

In method 610, producers distribute content items in duplicate using related pairs of subjects. A producer publishes notifications using one subject of a pair, called the initial subject, for the initial advertisement of a singleton content item (step 616). The producer publishes a notification using the other subject of the pair, called the past subject, to periodically republish advertisements that had been first published with an initial subject (step 618). A consumer submits one subscription on the initial subject to receive new advertisements (step 612), and it submits another subscription on the past subject to receive previously published advertisements (step 614). Alternatively, the consumer may only subscribe to the previously published advertisements. The matching previously published advertisements (and, if subscribed, the new advertisements) are pushed to the consumer using CBR (step 620). At some point the consumer decides to un-register the subscription for the past subject (step 622).

FIG. 24D is a sequence diagram further illustrating the method 610. FIG. 24D depicts the interaction between the advertiser (e.g., using publisher machine 100), the CBR infrastructure (e.g., network of intelligent routers 92), and the consumer/requester (e.g., using subscriber machine 122). The sequence diagram illustrates that multiple processors (e.g., processor 93, processor 114, and processor 132) preferably execute method 610. 3. FIG. 24E is a flowchart illustrating a third query-response method 630 using a publish-subscribe system. Method 630 may be executed using a variety of publish-subscribe systems. For example, method 630 may be executed by processor 93 under software control in intelligent router 92 (or in the coπesponding functions contained in ASIC 91) and implemented in software modules, e.g., as represented by agent 128 and 105 for execution by processor 134 and 114 in user machine 122 and 100.

Publish-subscribe networks are augmented with a caching feature, such as the one described above, whereby notifications published in the past are cached (step 632) and made available to future subscribers. Producers publish notifications to advertise singleton content items (step 634). Consumers submit a single subscription both to query previously advertised content items of interest (which are delivered by replaying the relevant notifications from the cache) and to obtain future advertisements of content items of interest (step 636). As in traditional publish-subscribe networks, the subscription characterizes a set of content items of interest. The matching previously published notifications are replayed from the cache (step 638) and pushed to the consumer using CBR (step 640).

FIG. 24F is a sequence diagram further illustrating the method 630. FIG. 24F depicts the interaction between the advertiser (e.g. , using publisher machine 100), the CBR infrastructure (e.g., network of intelligent routers 92), and the consumer/requester (e.g., using subscriber machine 122). The sequence diagram illustrates that multiple processors (e.g., processor 93, processor 114, and processor 132) preferably execute method 630. 4. FIGs. 24G and 24H are flowcharts illustrating a fourth query-response method 650 using a publish-subscribe system. Method 650 may be executed using a variety of publish-subscribe systems. For example, method 650 may be executed by processor 93 under software control in intelligent router 92, or in the coπesponding functions contained in ASIC 91, and implemented in software modules, e.g., as represented by agent 128 and 105, for execution by processor 134 and 114 in user machine 122 and 100.

FIG. 24G illusfrates a data advertisement phase of method 650. A data advertisement is received (step 652). hi order to allow consumers to use subscriptions to specify set queries and producers to use notifications to advertise singleton content items, and in order to achieve the reversal of temporal order necessitated by such a use of subscriptions and notifications, an ontology transformation is performed whereby the data advertisement is transformed to an equivalent subscription (step 654). The subscription (transformed data advertisement) is registered with the CBR network (e.g., the subscription is stored in intelligent routers 92) (step 656). FIG. 24H illustrates a query-response phase of method 650. A query is received

(step 658). As with the data advertisement above, the query is transformed to an equivalent notification (step 660) using ontology transformations. The transformation from the old space (e.g., data advertisement) to the new space (e.g., equivalent subscription) in steps 654 and 660 first involves defining attributes in the new space that represent combinations of attributes and expression operators from the old space. The transformation then involves creating notifications and subscriptions in the new space that are equivalent to the queries and advertisements of the old space, respectively. The transformation must satisfy the requirement that the notification matches the subscription if and only if the untransformed data advertisement matches the untransformed query.

The notification (transformed query) is pushed to the advertiser by the publish- subscribe system performing CBR using the subscription (transformed data advertisement) as a filter for the notification (step 662). The CBR may be performed according to any of the above-described methods using the above-described infrastructure. The advertiser receives the transformed notification and returns responsive data to the requester (step 664) via some non-publish-subscribe means or via an agreed-upon convention using the publish-subscribe network. FIG. 241 is a sequence diagram further illustrating the method 650. FIG. 241 depicts the interaction between the advertiser (e.g., using publisher machine 100), the CBR infrastructure (e.g., network of intelligent routers 92), and the requester (e.g., using subscriber machine 122). The sequence diagram illustrates that multiple processors (e.g., processor 93, processor 114, and processor 132) may execute method 650. The following is a detailed description of the ontology transformation. The following assumptions are made regarding the underlying structures: an advertisement is an element Ae A, such that A = VιxV₂x ... xV_m, where Vi is a data set (1 < i < m) and A_j is used to refer to the j^th element of A (1 < j < m); a query is a logical expression E e Q, where Q = {E, E:A→B | E = (F and G) or E = (F or G) or E = A αj Vj, with F,GeQ, α;: Nx Vi -» B, Vj<= Vi} ; and, it is said that a query E e £ matches an advertisement Ae A if and only if E(A) = true. Likewise, the following assumptions are also made: a notification is an element Ne N, such that N= VιxV₂x ... xV„, where j is a data set (1 < i < n) and N_j is used to refer to the j^th element ofN (l ≤j < n); a subscription is a logical expression S e S, where S = {S, S: N→B | S = (F and G) or S = (F or G) or S = Ni a; v;, with F,GeS, NeN, αj: VjX Vj -» B, VjβVj}; and, it is said that a notification Ne N matches a subscription Se S, if and only if S(A~) = true. A mapping between A and S, and between Q and N is defined as a pair of functions (MP_AS, MP_QN), MP_AS:A→S, MPQ_N-Q→N, such that for any A e A and Q e Q:

S =MP_AS(A)

N = R_ρ Q) S(N) = Q(A) i.e. (MP_AS(A))(MP_QN(Q)) = Q(A)

As a simplifying assumption a query expression would be considered to include only simple predicates (such as "A ocj v ") and "and" operators (any query expression can be expressed in DNF foπnat and handle each disjunct as a separate query). The next sections present an exemplary mapping solution, first applied on a particular case and then on the general case.

Simple Query Mapping

Given a basic scenario in which a query includes a simple predicate Q = A α v, an advertisement tuple contains only one element (i.e., A = V) and α is the only operator defined for V, the mapping problem becomes: N = MP_QJ^A a v) and S = MP_AS(A = a). The mapping for a "A = a" advertisement and a "A α v" query is: S = "A_α α^"1 a" and N = "A_x = v", where, α^~\ Vx V→ B, such that " x α^"1 y = y α x" for any x, y e V.

For the case when there are multiple operators α_ls α₂,... O_n, the mapping is: S = MP_AS(A = a) = "(A_αl αf¹ a) and (A_«2 α₂ ^_1 a) and ... and (A_αn On^"1 a)" and N = MP_QN(A α a) = "Axi = null_a A_α2 = nullc , ... , A _αk⁼ , ... , Aα_n = nullan", where, x αf nulled = true, for any x e and i = l,n.

An alternative mapping can be: S = MP_As(A = a) = "(A_xi αf¹ a) or (Aχ₂ α₂ ^_1 a) or ... or (Aχ_n O_n ^"1 a)" and N = R_βΛ A α a) = "A_αι = null_al, A„₂ = n ll^ ,..., A _αk= a ,..., A_αn = null_an", where, x αf¹ null_e ^ false, for any x e and i = l,n. Disjunctive Query Mapping

For a single operator and a disjunctive query, the mapping looks as follows: A = "A = a", Q = "(A α ai) and (A α a₂) ...(A α a_<N', S = "A_α α ¹ a", and N ="A_α = SUPER_α(a₁,a₂,...,a„)", where SUPER_α(aι,a₂,...,a_n): VxVx...→ V, "(x α ai) and (x α a₂) ...(x aq)" = "x α SUPER_α(a₁,a₂,...,a_n)" and SUPERα(())) = null_a. Note that there is no guarantee that the function SUPER_α(aι,a₂,...,a_n) exists for any operator α (in fact one can easily define an operator for which such a property cannot be defined). However, for most of the common operators such functions are available (i.e., for "<" it is MAX(..), for "in" u(...), for "=" is

For multiple operators and disjunctive queries a mapping looks as follows (we assume that each operator is used no more than once - previous case shows how any example can be reduced to this situation): A = "A = a", Q = (A α_x a_αX) and (A α_y a^) ...(A α₂ a_αZ)", S = "(A_αl αf¹ a) and (Aχ₂ α₂ ^_1 a) and ... and (A_αn c ¹ a)", and N = (..., Actk = null_ed ifoi is used by Q or a_αj otherwise,...).

General Case Mapping

Given advertisement A and a query Q, A = "A_t = a_ls A = a₂, ... A_n = a_n" and Q = "... and (A αj_k aj) and ...". The mapping look as follows: S = "...and (Ai_k αj_k ^_1 a_\) and ...", with: i=l,n where n = number of fields from the advertisement and

where m; = number of operators supported for the type of filed, and N = "...,A_αk= SUPER_αi_cda_αi_d a k2, • • •})_>•• •", where aα i are values appearing inside queries predicates of the form "Aj_k ctik ^_1 aαici", if there are now such elements for αj . The following are some examples of the mapping transformations described herein.

Example 1

We consider a simple stock quote information system. The information structure is described by a 2-touple (Symbol, Price), where Symbol is of type String and Price is of type Float. Queries, are formulated as conjunctions and/or disjunctions of primitive predicates, where the predicates are of format:

value>" or "Pπce==<float value>". The data set is:

Aι= ("IBM", 70.12), A₂= ("LU", 5.30), A₃= ("KKD", 30.23), and

A_ («_ATT»₅ 5 0).

The queries are:

Qι = (Symbol = "IBM"), Q₂ = (Symbol = "LU") AND (Price = 5.30), and

Q₃ = (Symbol = "KKD") OR (Price = 5.30).

Therefore, the query matching (i.e., the response) is:

The Publish-Subscribe mapping for the above Query-Response:

Notification schema (Symbol=,Price=)

Subscription mapping for data advertisements:

S₃

Notification mapping for queries:

).

Therefore, the subscription matching is:

The reciprocal notification matching is:

), MP_AS(A₄)} .

Example 2 We again consider a simple stock quote information system. The information structure is described by a 2-touple (Symbol, Price), where Symbol is of type String and Price is of type Float. Queries, are formulated as conjunctions and/or disjunctions of primitive predicates, where the predicates are of format:

value>" or "Pπ^'ce==<float value>" or "Price > <float value>" or "Price < <float value>."

The data set is:

Aι= ("IBM", 70.12),

A₂= ("LU", 5.30),

A₃= ("KKD", 30.23), and

A = ("ATT", 5.30). The queries are:

Q_! = (Price > 5.00), Q₂ = (Symbol = "LU") AND (Price < 40.00), and Q₃ = (Symbol = "KKD") OR (Price = 5.30).

Therefore, the query matching (i.e., the response) is:

The Publish-Subscribe mapping for the above Query-Response:

The notification schema is (Symbols, Price=, Price_>, PriceX).

The subscription mapping for data advertisements is: S₁ = MP_AS(A_Ϊ)=

(Sjmbo/==="roM")AND(Pπce===70.12)AND(Prtce_><=70.12)AND(Pr/ce_<>=70.12),

The notification mapping for queries is: Ni = P_βW(Q₁) = (*, *, 5.00, ∞),

N₂ = P_βΛ<Q₂) = ("LU", *, -oo, 40.00), and

N₃₁,N₃₂ = P_βΛ<Q₃) = ("KKD", *, -∞, «>),(*, 5.30, -oo, oo).

Therefore, the subscription matching is:

The reciprocal notification matching is:

Ni: {Sι,S₂,S₃,S₄} MP_QN(Qύ = {MP_AS(A₁), MP_AS(A₂), P_AS(A₃)MPAS(A₄)}, N₂: {S₂} MPg^ ) = { P^(A₂)}, and

N₃₁,N₃₂: {S₂,S₃,S₄} MP_QΉ(QX) = {MP_A^A₂), MP_AS(A_Z)JMP_A^.A_A)} .

5. hi a fifth method, the publish-subscribe network is augmented with additional interface points and/or message formats that allow producers to distinguish between notifications, advertisements and responses, and that allow consumers to distinguish between subscriptions and queries. The network honors the separation between the various primitives while using a uniform set of data structures, algorithms and protocols to simultaneously implement both styles of interaction. Persistent and Reliable Massage Delivery

The embodiment described herein provides apparatus and methods for persistent storage of messages and recovery, restart and/or continuation of message flows in the face of network, link and/or node failures in a publish-subscribe network. Message persistence is the ability to store messages and retrieve them at a later time. A large number of specific applications, e.g. email, generally require lengthy message persistence for messages flowing through the network, hi ideal conditions, with no failures in the network an always-connected subscriber should not need any persistence beyond that required for these specific applications. However, in reality, messages can get "lost" while traversing through the network due to various reasons - e.g., (1) failures or buffer overflows occurring either inside the network or at the user end or (2) users doing an explicit disconnect from the network and connecting back again after a time period.

The persistence model of an event notification platform of the present embodiment is divided into two levels: short-term persistence and long-term persistence. Short-term persistence is designed for recovering from packet loss due to network congestion or short-term link failure. Long-term persistence is designed for recovering from other failures including, e.g., loss of user connections, failure of user machines, failure of applications, and/or longer-term network failure.

A channel (e.g., as described above) can either be persistent or real-time. A real- time chaimel transmits data that is generally only useful in real-time and does not have any application-specific persistence requirements. A persistent channel stores data traversing through network for a persistence time frame T. In other words, persistence for a persistent channel is guaranteed for a time frame T. This persistence of data is achieved through the following, for example: caching data at each edge node for the persistent duration of a channel; retrieving data from the cache transparent to the users under failure conditions; allowing the user to explicitly retrieve data from the cache; making the flow of data through the network persistent by guarding against router failures and setting up reliable tunnels between routers; and, protecting the channel components against failure through replication.

A. Persistence through Caching

Timed Persistence (with time frame T) is the ability to retrieve the last time frame T of data from the publish-subscribe network. For example, if a subscriber leaves the network, any data on a persistent channel that is received during the subscriber's absence is held in the network for a time frame T (from the data's receipt). If the user returns within the time frame T, the user does not lose any data.

FIG. 25 A is a block diagram illustrating certain components of a publish- subscribe network that provide persistence through caching. As shown, the network includes core routing nodes and an edge routing node. Each routing node preferably includes an intelligent router 92 (shown with the edge routing node) and a conventional backbone router (not shown), as described above in FIG. 4. Each intelligent router 92 that needs to perform caching for persistent channels preferably has a cache manager 218 co-located with it, as illustrated by FIG. 25 A. The cache manager 218 is described above with references to FIG. 8. The intelligent router 92 is preferably responsible for short-term persistence for retrieving lost data or recovering from router failures. The cache manager 218 is responsible for caching data to provide long-term persistence for a 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). Also shown in FIG. 25A is an agent 128, which is preferably resident in subscriber machine 122 (not shown in FIG. 25A), as described above in FIG. 5. The agent 128 is responsible for communicating with the cache manager 218 to retrieve data from the cache 540, receiving the retrieved data and for organizing the retrieved data. Although not shown in FIG. 25 A, each of the first level of core routing nodes upstream from the edge routing node preferably includes a cache manager 218. Upsfream is the direction moving away from the agent 128 (i.e., away from the subscriber machine 122). The first level of upsfream core routing nodes refers to the routing nodes immediately upstream from the edge routing node. Although publish- subscribe networks often include a plurality of first level upstream core routing nodes, FIG. 25 A only depicts one first level upstream core routing node, core routing node 548. As described above, a cache manager 218 provides for local caching of data at a network node at which it is located. Therefore, the operation of cache managers 218 located at various core routing nodes, including, e.g., core routing node 548, provides for distributed caching of data throughout the network core. This distributed caching provides a backup for the caching at edge routing node. Cache manager 218 preferably includes routines or sub-routines responsible for managing the cache 546. These routines preferably include a caching data routine 545, purging cache data routine 547 and retrieving cache data routine 549, as illustrated in FIG. 25B. Each of these routines may operate separately or, as shown, may communicate and/or pass control between one another. FIG. 25C is a flow chart illustrating an example method of persistent caching 550 for data contained in a single message. As shown, the method 550 shows an exemplary execution of steps performed by each routine shown in FIG. 25B. In operation, these routines preferably operate independent of one another. Method 550 may be performed at an intelligent router 92, at an edge routing node or core routing nodes, that provides caching.

The method 550 can be implemented, for example, in software modules (e.g., cache manager 218) for execution by a processor 93 in intelligent router 92. Alternatively, it can be implemented in an ASIC or a combination of hardware and software, either in the same or different physical device as a coπesponding intelligent router 92. The intelligent router 92 forwards messages that need to be cached to the cache manager 218. The cache manager 218 receives the messages containing data (step 552), time marks the data in the messages (step 554), and caches the data in the cache 546 (step 556) (analogous to steps 322-326 in FIG. 14 (see above)). The cache manager 218 indexes the cached data (step 558) in a number of ways, e.g., channel identifier, subjects, publisher identifier, timestamp etc, as described above. The indexing step 558 may take place prior to, simultaneously with, or after the caching step 556. The cached data may be indexed and stored in a hierarchical directory structure (e.g., see FIG. 15). See also Tables 17-19.

The data is cached in memory (the cache 546) and periodically moved to disk (step 560). A persistent time frame "T" for a particular channel is divided into N time grains each of size G. The caching in memory (step 556) is only for the duration of G. After the cache manager determines that time interval G has passed (step 559), the data is moved to the disk (step 560). The cache manager 218 stores the data on the disk for the duration of persistent timeout interval T.

The data coπesponding to a time interval G is deleted from the disk (step 564) once the time becomes greater than the Persistent timeout (T) for the channel + the upper limit of the interval (step 562). To better understand this, suppose a channel has a T of 2 hours. As an example, the cache manager 218 uses a time granularity G of 15 minutes. For deleting the data from the disk, the policy preferably used is that when the last data cached during a time interval G (15 minutes) has been stored for T (2 hours), the entire data cached during that 15-minute interval will be discarded. Therefore, the data cached in the beginning of that 15-minute interval will have been stored for longer than 2 hours before it is deleted, hi 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, any point in time there will be N+l blocks of data (N on disk and 1 in memory) in the cache 540 for each subject. If the cache manager 218 receives a request for data (step 566), the cache manager 218 retrieves that requested cached data (for which time T has not passed), using the index (step 568) and transfers the retrieved data to the backbone router for routing to the requesting subscriber machine 122 (step 570). As described below, with reference to FIG. 25D, if the data is not at the cache 540 at the edge routing node, the cache manager 218 may invoke caches at the first level of upsfream core routing nodes (e.g., at core routing node 548) to retrieve the data. If the cache manager 218 does not receive a request, method 550 loops back to step 552.

To guard against failures of the cache manager 218 at a given intelligent router 92, in addition to storing data in the cache 546, the data is also stored in caches at the first level of upsfream core routing nodes (e.g., core routing node 548). Hence, steps

552-564 are preferably performed at the first level of upstream core routing nodes prior to the messages being routed to and method 550 being performed at the edge routing node.

The locations of the cache 546 (e.g., at the edge routing node) and the caches at the first level of upstream core routing nodes (e.g., at the first upsfream core router 548) are stored locally in the agent 128. Therefore, if the subscriber machine 122 moves (e.g., the subscriber is a mobile subscriber that re-connects to the network at a different edge routing node), the agent 128 will provide the new edge routing node with the location of the caches for the edge routing node and first level of upstream core routing nodes to which the subscriber machine 122 was connected prior to moving. This enables persistence to be maintained even if the subscriber machine 122 moves. As seen in FIG. 25D, a flowchart of a method of persistent message retrieval 580, a user application 182 at subscriber machine 122 preferably invokes the agent 128 to request data from the cache (step 582). Using the stored cache locations, the agent 128 invokes the cache 546 at the appropriate edge routing node (e.g., using a getcache command) to get the data (step 584). The agent 128 may indicate what time frame of data to retrieve. Alternatively, the cache manager 218 may check the connection history of a subscriber machine 122 (see Table 18 above) to determine what cached data to retrieve. If the connection history indicates that the subscriber machine 122 was off-line for X period of time, the cache manager 218 may retrieve all available cached data for X. Additionally, the cache manager 218 may simply retrieve all data cached within persistent time frame T. If the edge routing node cache 546 has the data (step 585), the agent 128 retrieves the data from the cache 546 (step 586).

If the cache 546 does not have the data, the cache manager 218 uses a list of the caches at the first level of upsfream routing nodes (e.g., core routing node 548) provided by the agent 128 to invoke these upstream caches to locate the data (step 588). Once the cache manager 218 locates the data in an upstream cache or caches, the cache manager 218 retrieves the data from the upstream cache(s) (step 590). The cache manager 218 may perform duplicate suppression (i.e., eliminate duplicate data) (step 592) before forwarding the data to the agent 128 (step 594).

B . Persistence through Failure Protection An infrastructure consistent with the present embodiment has the following components or equivalent components: channel managers; event agent; and, routing nodes and caches. To guard against loss of messages during failure conditions, each of these components needs to be protected.

1. Channel Manager Fault Protection Channel managers are described above with reference to FIG. 6. The channel managers are protected from failures through replication. The channel managers operate in a primary-backup group, where there is one primary module and the other backup modules. The primary module is responsible for all updates to the data and also responds to queries. The backup can only serve queries but cannot perform updates. It forwards all updates to the primary. Components of the publish-subscribe network that need to retrieve channel information from the channel managers are refeπed to as channel manager clients and are assigned a channel manager. These clients include intelligent routers 92, and their cache managers 218, and subscriber machines 122, and their agents 128. If the channel manager assigned to the client fails, the client accesses another channel manager and connects to it.

2. Routers and Cache Fault Protection

There are several levels of recovery for the routing infrastructure components. (Level 0, Level 1, through Level 3). Level 0 controls the failure effect locally (i.e., within the failed router) and the recovery is also limited to the failed routing node. Level 0 recovery depends on hardware redundancy to recover from hardware failures. The hardware resources in a router are replicated. The main advantage of level 0 recovery is the short recovery time and transparency. Level 1 controls the failure effect within a LAN. Level 1 recovery may be implemented with IP fail-over using cluster technology. However, tunnels of a failed router to its neighbors have to be reconstructed after recovery. Therefore, level 1 recovery is less transparent and takes longer than level 0 recovery.

The scope of Level 2 recovery is to recover router failure by remote backup router over a WAN, without affecting network topology, which may cause complex reconfiguration and data loss. Level 2 may be implementing by grouping routers to form a recovery set (e.g., a primary and backup router). One router may be a primary in one group and a backup for another group. The primary exchanges routing and network configurations with the backup, and when the backup detects a failure of the primary, it takes over the functions of the primary. The backup ensures that the primary router failed, and not the link to the primary router, by ensuring that it can connect to the majority of neighbor primary routers of the failed primary router. If it cannot, level 3 recovery is triggered. Level 3 on the other hand may involve a system-wide coordinated recovery. Level 3 is used when all else fails. The router that detects such a failure sends a restart notice to all downstream routers. The routers receiving the notice, suspend all other recovery, stop all network services, and discard all multicasting information in the restart message. After all network services have been terminated, the router restarts all services, including tree-building process for multicasting. Any failure in the network is treated by a lower level recovery procedure. If a lower level recovery cannot be applied, the recovery is escalated to the next higher level. If none of the lower level recoveries work, the level 3 recovery is used. 3. Reliable Tunnels

To guard against loss of messages during network failures, a reliable tunnel is used to cany traffic between routing nodes. Tunnels are described above in the description of FIG. 3. Any message losses during transmission are detected by the receiving end, which then asks the sender to retransmit the lost messages. While the present invention has been described in connection with an exemplary embodiment, it will be understood that many modifications will be readily apparent to those skilled in the art, and this application is intended to cover any adaptations or variations thereof. For example, various types of publisher machines, user or subscriber machines, channels and configurations of them, and hardware and software implementations of the content-based routing and other functions may be used without departing from the scope of the invention. This invention should be limited only by the claims and equivalents thereof.

Claims

1. A method for executing publish-subscribe operations over unreliable networks, comprising: receiving using a network a subscription to content; and, publishing content using the network based upon the subscription to content, comprising: receiving a notification concerning the content at a node in the network; determining if the notification is to be forwarded to a neighboring node; and selectively forwarding the notification to the neighboring node, based upon the determination, using a reliable transmission protocol.

2. The method of claim 1 , wherein the selectively forwarding step includes receiving an indication of a failure in the forwarding of the notification and re- forwarding the notification in response to the indication.

3. The method of claim 1, wherein the forwarding step includes forwarding a packet encapsulating the notification.

4. The method of claim 1, wherein the forwarding step includes using Internet Protocol for the forwarding of the notification.

5. The method of claim 1, wherein the forwarding step includes forwarding the notification on a single node-to-node basis.

6. The method of claim 1, wherein the determining step includes determining whether the content satisfies one or more criteria of the subscription to content.

7. The method of claim 1 , wherein the forwarding step includes using a router to forward the notification to the neighboring node.

8. The method of claim 1, further comprising repeating the publishing step on a node-to-node basis in the network until the notification is forwarded to a subscriber or subscribers coπesponding to the subscription.

9. The method of claim 1, wherein the selectively forwarding step uses transmission control protocol.

10. A router for executing publish-subscribe operations over unreliable networks, comprising modules for executing the method of claim 1.

11. A wide-area network for executing publish-subscribe operations, comprising: one or more subscriber machines; and a plurality of routers, wherein each of the plurality of routers includes: a subscription receiving module, wherein the subscription receiving module receives a subscription to content, coπesponding to one or more of the subscriber machines, via the wide-area network; and a publishing module, wherein the publishing module includes: a notification receiving module, wherein the notification receiving module receives a notification concerning the content at a node in the network; a content-based routing module, wherein the content-based routing module determines if the notification is to be forwarded to a neighboring node; and, a reliable forwarding module, wherein the reliable forwarding module selectively forwards the notification to the neighboring node, based upon the determination, using a reliable transmission protocol; wherein the plurality routers selectively and reliably forward the notification until the notification is forwarded to the one or more subscriber machines coπesponding to the subscription.

12. A method for executing publish-subscribe operations over unreliable networks, comprising: receiving via a network a subscription to content at a first node in the network; receiving a notification concerning the content at the first node in the network; determining based on content-based routing (CBR) using the subscription to content if the notification is to be forwarded to a second, neighboring node; and, selectively forwarding the notification to the second node, based upon the determination, using a reliable transmission protocol.

13. The method of claim 12, further comprising the steps of: if there is a forwarding failure between the first node and the second node, receiving an indication of the forwarding failure; and, re-forwarding the notification to the second node in response to the indication.

14. The method of claim 12, further comprising the step of buffering the notification in a buffer prior to the selectively forwarding step.

15. The method of claim 14, further comprising the step of moving the buffered notification to secondary storage after a period of time.

16. The method of claim 14, further comprising the step of deleting the buffered notification on a first in-first out basis.

17. The method of claim 14, further comprising the step of deleting the buffered notification on a quality of service basis.

18. The method of claim 12, further comprising the step of caching the notification in a cache at the first node.

19. The method of claim 12, wherein the reliably forwarding step uses transmission control protocol.

20. A router for executing publish-subscribe operations over unreliable networks, comprising modules for executing the method of claim 12.

21. A wide-area network (WAN) for executing publish-subscribe operations, comprising: one or more subscriber machines; and a plurality of routers, wherein each of the plurality of routers includes: a subscription receiving module, wherein the subscription receiving module receives a subscription to content at a first node in the WAN, coπesponding to one or more of the subscriber machines, using the WAN; a notification receiving module, wherein the notification receiving module receives a notification concerning content at the first node; a content-based routing module, wherein the content-based routing module determines if the notification is to be forwarded to a second node in the WAN; and, a reliable forwarding module, wherein the reliable forwarding module selectively forwards the notification to the second node, based upon the determination, using a reliable transmission protocol; wherein the plurality of routers selectively and reliably forward the notification until the notification is forwarded to the one or more subscriber machines coπesponding to the subscription to content .

22. The network of claim 21 , wherein the reliable forwarding module uses transmission confrol protocol.

23. A method for executing publish-subscribe operations over unreliable networks, comprising: establishing a reliable tunnel between two neighboring nodes using a reliable transmission protocol; receiving via a network a subscription to content at a first of the neighboring nodes in the network; receiving a notification concerning the content at the first of the neighboring nodes in the network; determining based on content-based routing (CBR) using the subscription to content if the notification is to be forwarded to a second of the neighboring nodes in the network; and, selectively forwarding the notification to the second of the neighboring nodes in the network, based upon the determination, using a the reliable tunnel.

24. A router for executing publish-subscribe operations over unreliable networks, comprising modules for executing the method of claim 23.

25. A network for executing publish-subscribe operations comprising a plurality of routers according to claim 24.

26. A method for propagating filters in a publish-subscribe network, comprising: receiving a plurality of filters relating to subscriptions to content in the network; reducing a number of the filters based upon particular criteria; and propagating in the network the reduced number of filters for use in satisfying the subscriptions to content.

27. The method of claim 26 wherein the reducing step includes one or more of: performing an approximation operation on one or more of the plurality of filters; and performing a merging operation on one or more of the plurality of filters.

28. The method of claim 27, wherein the performing a merging operation step includes determining whether a merged filter will exceed a packet leakage threshold.

29. The method of claim 26 wherein the receiving step includes receiving the plurality of filters via a content-based routing network.

30. The method of claim 26 wherein the propagating step includes propagating the filters using one or more of a plurality of particular procedures chosen from a list consisting of: an eager propagation scheme; lazy propagation scheme; response to broadcast advertisement scheme; after network topology computation scheme; periodic propagation scheme; filter re-propagation during fault repair scheme; and, filter re-propagation during network re-configuration scheme.

31. The method of claim 26 wherein source and destination nodes for the propagation are connected using one or more of a plurality of particular mechanisms chosen from a list consisting of: hop-by-hop, end-to-end, using tunnels, and using transmission confrol protocol.

32. The method of claim 26, further including injecting the filters at one or more of a plurality of particular locations in the network.

33. The method of claim 26 wherein the propagating step includes propagating the filters based upon one or more of a plurality of particular behaviors of an intended recipient, the behaviors chosen from a list consisting of: mobile, permanent, and temporary.

34. The method of claim 26 wherein the propagating step includes propagating the filters based upon one or more of a plurality of particular behaviors of a sender of one or more of the filters, the behaviors chosen from a list consisting of: mobile, permanent, and temporary.

35. The method of claim 26, further including performing one or more of a plurality of particular processing steps on one or more of the filters, the processing steps chosen from a list consisting of: attribute content translation, expression expansion, expression translation, transformation of representations, encoding/decoding, and encryption/decryption.

36. The method of claim 26, further including formatting a message containing one or more of the filters according to one or more of a plurality of particular formats.

37. The method of claim 26 wherein the propagating step includes propagating the _ filters according to one or more of a plurality of particular policies or procedures chosen from a list consisting of: administering, maintenance, filter persistency, performance enhancing policies, monitoring, and accounting.

38. The method of claim 26, wherein the propagating step includes: determining a network topology underlying a filter propagation strategy, wherein the underlying network topology includes one or more of a plurality of requirements for filter propagation that must be satisfied in order to propagate filters; and propagating the reduced number of filters based on satisfaction of the requirement of the determined filter propagation strategy.

39. The method of claim 38, wherein the determined filter propagation strategy is one of a list consisting of: eager propagation scheme; lazy propagation scheme; response to broadcast advertisement scheme; after network topology computation scheme; periodic propagation scheme; filter re-propagation during fault repair scheme; and, filter re-propagation during network re-configuration scheme.

40. The method of claim 26, wherein the receiving step receives the plurality of filters at a core router in the network.

41. The method of claim 26, wherein the receiving step receives the plurality of filters at an edge router in the network.

42. The method of claim 26, wherein the receiving step receives the plurality of filters at publisher machine in the network.

43. A router for propagating filters in a publish-subscribe network, comprising modules for executing the method of claim 26.

44. A publish-subscribe network comprising a plurality of routers that include modules for executing the method of claim 26.

45. A publish-subscribe network comprising user machines that include modules for executing the method of claim 26.

46. An apparatus for propagating filters in a publish-subscribe network, comprising: a filter receiving module, wherein the filter receiving module receives a plurality of filters relating to subscriptions to content in the network; a filter reduction module, wherein the filter reduction module reduces a number of the filters based upon particular criteria; and a filter propagation module, wherein the filter propagation module propagates, in the publish-subscribe network, the reduced number of filters for use in satisfying the subscriptions.

47. The apparatus of claim 46, wherein the filter reduction module further comprises: a filter approximation module, wherein the filter approximation module performs an approximation operation on one or more the plurality of filters; and a filter merging module, wherein the filter merging module merges two or more of the plurality of filters.

48. The apparatus of claim 46, further comprising: a filter processing module, wherein the filter processing module transforms one or more of the filters; and a filter grouping module, wherein the filter grouping module groups filters based on the filters proximity to one other.

49. A method for propagating filters in a publish-subscribe network, comprising the steps of: (a) receiving a plurality of filters at a node in the network;

(b) processing one or more of the received filters to reduce the number of filters;

(c) determining whether to propagate filters based on recipient behavior rules; and (d) propagating the processed filters to a next node in the network.

50. The method of claim 49, further comprising: determining whether to propagate filters based on sender behavior rules;

51. The method of claim 49, further comprising the step of determining if there is another node after the next node in the network.

52. The method of claim 49, if it is determined that there is another node, repeating steps (b)-(d).

53. The method of claim 49, further comprising the step of determining if there are additional filters to be received at the next node in the network.

54. The method of claim 53, if it is determined that there are additional filters to be received at the next node in the network, repeating steps (a)-(d) at the new node.

55. The method of claim 49, wherein the processing step includes one or more of the steps of: simplifying the filters to remove redundant predicate expressions; approximating the filters; clustering the filters; subsuming the filters; and, merging two or more filters.

56. The method of claim 55, wherein the processing step further includes: grouping filters; and, wherein the approximating step approximates filters in the group, the clustering step locates and collects filters in the group with respect to the filters' proximity, the subsuming step subsumes filters in the group, and the merging step merges filters in the group.

57. The method of claim 56, wherein the grouping step groups filters only from downlinks relevant to a subject.

58. The method of claim 55, wherein the merging step includes determining whether a merged filter will exceed the packet leakage threshold

59. The method of claim 49, wherein the processing step includes: approximating the filters; and, subsuming and merging the approximated filters.

60. The method of claim 49, wherein the node in the network includes stored filters and wherein the processing step process the received filters and the stored filters to reduce the number of filters.

61. The method of claim 60, wherein the stored filters are previously received and processed filters.

62. The method of claim 49, wherein the receiving step (a) receives the plurality of filters at a node in the core of the network.

63. A router for propagating filters in a publish-subscribe network, comprising modules for executing the method of claim 49.

64. A publish-subscribe network comprising a plurality of routers that include modules for executing the method of claim 49.

65. A publish-subscribe network comprising user machines that include modules for executing the method of claim 49.

66. An apparatus for propagating filters in a publish-subscribe network, comprising: a filter receiving module, wherein the filter receiving module receives a plurality of filters at a node in the network; a filter processing module, wherein the filter processing module reduces the number of filters in the plurality of received filters; and, a filter propagation module, wherein the filter propagation module determines whether to propagate filters based on recipient behavior rules and, if determined to propagate, propagates the reduced number of filters to a next node in the network.

67. The apparatus of claim 66, wherein the filter processing module includes: a simplification module, wherein the simplification module simplifies the filters to remove redundant predicate expressions.

68. The apparatus of claim 66, wherein the filter processing module includes: a grouping module, wherein the grouping module groups filters according to a selection of downlinks.

69. The apparatus of claim 66, wherein the filter processing module includes: an approximation module, wherein the approximation module approximates the filters.

70. The apparatus of claim 66, wherein the filter processing module includes: a subsumption module, wherein the subsumption module subsumes filters.

71. The apparatus of claim 66, wherein the filter processing module includes: a clustering module, wherein the clustering module clusters filters according to their proximity to each other.

72. The apparatus of claim 66, wherein the filter processing module includes: a merging module, wherein the merging module merges filters.

73. A method of filter propagation in a publish-subscribe network, comprising the steps of: a router sending notification requesting filters; one or more downstream routers receiving the notification; propagating the filter requests further downstream; waiting for a response from the downstream routers to which the filter request is propagated; collecting filters from the downstream routers to which the filter request is propagated; processing the propagated filters to reduce the number of filters; and, sending the reduced number of filters upstream to the router requesting filters.

74. The method of claim 73, further comprising: each downstream router updating a bookkeeping database to reflect that a filter request is received from the router; and determining if the router from which the filter request is received has been serviced.

75. A publish-subscribe network comprising a plurality of routers and publisher machines that include modules for executing the method of claim 73.

76. A method for content-based routing of packets in a publish-subscribe network, comprising: receiving a packet in the network; accessing a map specifying filter coverage in an attribute space; inspecting content of the packet for use in a routing decision for the packet; using the map to assist in a routing decision for the packet; making a routing decision based upon the inspected content of the packet and the map; and routing the packet based on the routing decision.

77. The method of claim 76, wherein the making a routing decision step further includes matching the content to a coπesponding subscription.

78. The method of claim 77, wherein the matching step includes using a plurality of conjunctive filters in order to identify a match.

79. The method of claim 77, wherein the matching step includes performing attribute tests.

80. The method of claim 76, wherein the making a routing decision step includes using the map online.

81. The method of claim 76, further comprising precomputing filter coverage off- line or with background processing.

82. The method of claim 76, further comprising precomputing filter coverage wherein the precomputing step includes approximating and reducing filter expressions.

83. The method of claim 76, further comprising computing filter coverage wherein the computing filter coverage includes spatially quantizing attribute space into a grid comprising grid cells.

84. The method of claim 83, wherein the computing filter coverage includes: combining filter coverage information and the grid; and generating the map based on a union of actions predicated by filter coverage information in each grid cell.

85. A router for content-based routing of packets in a publish-subscribe network, comprising modules for executing the method recited in claim 76.

86. A network comprising a plurality of routers according to claim 85.

87. A computer-readable medium comprising instructions for performing the method recited in claim 76.

88. A method for use in content-based routing of packets, comprising:

(a) spatially quantizing attribute space, wherein the spatially quantizing step creates a grid including grid cells;

(b) identifying the grid cells covered by a plurality of filters, wherein each filter has at least one predicated attribute; and

(c) updating a content-based routing (CBR) table with action rales predicated by the plurality of filters that cover the grid cells identified in step (b).

89. The method of claim 88, further comprising the step of: determining if one or more distinct filters are inserted or removed from a node; and executing steps (b) and (c) at the node based on a determination that one or more distinct filters are inserted or removed from the node.

90. The method of claim 88, further comprising the steps of: receiving published packets; and plotting the received packets to the grid.

91. The method of claim 90, wherein for packets plotted to grid cells that are completely covered by the computed filter coverage information, the method further comprises: checking the CBR table to determine routing actions for packets plotted to the completely covered grid cells.

92. The method of claim 91 , further comprising: determining if the network traffic is above a set threshold; and, routing the published packets based on the determined routing actions, if the network traffic is determined to be above the set threshold.

93. The method of claim 92, further comprising: performing leakage reduction, if the network traffic is determined to be at or below the set threshold.

94. The method of claim 93, wherein the performing leakage reduction step includes one-dimension exact matching.

95. The method of claim 93, wherein the performing leakage reduction step includes cross-producting.

96. The method of claim 93, wherein the performing leakage reduction step includes the formation of multiple grids and CBR tables according to the full set of subset of the permutations of a limited number and a variety of attributes.

97. The method of claim 92, further comprising: determining if there are any reduced filter predicates or packets plotted to partially covered grid cells, if the network traffic is determined to be at or below the set threshold; performing predicate-by-predicate filter matching to determine routing actions for any reduced filter predicates and any packets plotted to partially covered grid cells, if there are determined to be reduced filter predicates or packets plotted to partially covered grid cells; and, routing the packets based on determined routing actions.

98. The method of claim 88, further comprising reducing filter expressions.

99. The method of claim 88, wherein step (a) includes adaptive quantizing the attribute space.

100. The method of claim 99, wherein the adaptive quantizing step adaptively quantizes the attribute space based on packet distribution information.

101. The method of claim 88, wherein the spatially quantizing step spatially quantizes the attribute space based on packet distribution information.

102. The method of claim 88, wherein the spatially quantizing step updates the grid based on packet distribution information.

103. The method of claim 88, wherein step (c) generates or updates an action bit mask for a grid cell that is covered by the computer filter coverage information.

104. The method of claim 88, wherein step (c) generates or updates a linked list of action for a grid cell that is covered by the computer filter coverage information.

105. The method of claim 88, further comprising updating parameters for covered cells in the CBR table, wherein the parameters include statistical information about the filter distribution.

106. The method of claim 88, further comprising collecting statistical information about packet distribution, wherein the packet distribution information is used in step

(a)-

107. The method of claim 88, wherein steps (a) through (c) are performed offline.

108. The method of claim 88, further comprising performing content based routing (CBR), wherein only the CBR table and the rules in the CBR table are used to perform the CBR.

109. An apparatus for content-based routing of packets in a publish-subscribe network, comprising modules for executing the method recited in claim 88.

110. The apparatus of claim 109, wherein the apparatus is a router.

111. A network comprising a plurality of routers that comprise modules for executing the method recited in claim 88.

112. A computer-readable medium comprising instructions for performing the method recited in claim 88.

113. A method for implementing query-response interactions on a publish- subscribe network, comprising: receiving an advertisement relating to a data set; receiving a query representing a logical expression; mapping the advertisement to a coπesponding subscription; mapping the query to a coπesponding notification; using the coπesponding subscription for implementation of the advertisement; and using the coπesponding notification for implementation of the query in the network.

114. The method of claim 113 wherein the mapping the advertisement step includes performing a general case mapping for the advertisement.

115. The method of claim 113 wherein the mapping the query step includes performing a disjunctive query mapping for the query.

116. A method for implementing query-response interactions on a publish- subscribe network, comprising: creating a subscription to register an advertisement; publishing a notification to distribute a query; performing content-based routing (CBR) using the subscription to push the notification to an advertiser; and, returning responsive data to the requester.

117. The method of claim 116, wherein the returning step is accomplished using a unicast connection between the advertiser and the requester.

118. The method of claim 116, wherein the returning step includes the requester creating a new subscription for the responsive data and performing CBR using the new subscription to push the responsive data to the requester.

119. The method of claim 116, wherein the creating step creates a subscription to register an advertisement for a set of data.

120. A publish-subscribe network for implementing query-response interactions, comprising routers, publisher machines and subscriber machines that include modules for executing the method of claim 116.

121. A method for implementing query-response interactions on a publish- subscribe network, comprising: receiving a subscription that registers an advertisement; receiving a notification that distributes a query; performing content-based routing using the subscription to determine whether to forward the notification to a neighboring node; and, selectively forwarding the notification based upon the determination.

122. An apparatus for implementing query-response interactions on a publish- subscribe network, comprising modules for executing the method of claim 121.

123. The apparatus of claim 122, wherein the apparatus comprises a router.

124. A method for implementing query-response interactions on a publish- subscribe network, comprising: publishing a notification with an initial subject; publishing a notification with a past subject, wherein the notification with a past subject is for previously published advertisements; submitting a subscription for the past subject, wherein the subscription for the past subject is a query for the previously published advertisements; and performing content-based routing using the subscription for the past subject to push the previously published advertisements to a consumer.

125. The method of claim 124, further comprising the step of submitting an un- subscription for the past subject.

126. The method of claim 124, further comprising the step of submitting a subscription for the initial subject;

127. A publish-subscribe network for implementing query-response interactions, comprising routers, publisher machines and subscriber machines that include modules for executing the method of claim 124.

128. A method for implementing query-response interactions on a publish- subscribe network, comprising: receiving notifications with initial subjects and notifications with past subjects, wherein the notifications with past subjects are for previously published advertisements; receiving subscriptions for initial subjects and subscriptions for past subjects, wherein the subscriptions for past subjects are queries for previously published advertisements; performing content-based routing using the subscriptions for past subjects to determine whether to forward the previously published advertisements to a neighboring node; and, selectively forwarding the previously published advertisements based upon the determination.

129. An apparatus for implementing query-response interactions on a publish- subscribe network, comprising modules for executing the method of claim 128.

130. The apparatus of claim 129, wherein the apparatus comprises a router.

131. A method for implementing query-response interactions on a publish- subscribe network, comprising: caching a published notification; publishing notifications to advertise content in the cached published notification; submitting a subscription to query published notifications; replaying the cached published notification from the cache; and, performing content-based routing (CBR) based on the subscription to push the replayed published notification to a consumer.

132. A publish-subscribe network for implementing query-response interactions, comprising routers, publisher machines and subscriber machines that include modules for executing the method of claim 131.

133. A method for implementing query-response interactions on a publish- subscribe network, comprising: caching published notifications; receiving subscriptions that query published notifications; replaying the cached published notifications from the cache; and, performing content-based routing (CBR) using the subscriptions that query published notifications to determine whether to forward cached published notifications to a neighboring node; and, selectively forwarding the cached published notifications based upon the determination.

134. An apparatus for implementing query-response interactions on a publish- subscribe network, comprising modules for executing the method of claim 133.

135. The apparatus of claim 134, wherein the apparatus comprises a router.

136. A method for implementing query-response interactions on a publish- subscribe network, comprising: receiving a data advertisement; fransforming the data advertisement to a subscription; receiving a query; transforming the query to a notification; performing content-based routing (CBR) based on the subscription to push the notification to an advertiser; and returning responsive data to a requester based on the notification.

137. The method of claim 136, wherein the transforming steps include performing ontology transformations.

138. The method of claim 136, wherein the returning step is accomplished using a unicast connection between the advertiser and the requester.

139. The method of claim 136, wherein the returning step includes the requester creating a new subscription for the responsive data and performing CBR using the new subscription to push the responsive data to the requester.

140. The method of claim 136, wherein the receiving a query step receives a query for a data set.

141. The method of claim 136, wherein the receiving a data advertisement step receives a data advertisement for data set.

142. The method of claim 136, wherein the transforming the data advertisement step includes performing a general case mapping for the data advertisement.

143. The method of claim 136, wherein the transforming the query step includes performing a disjunctive queries mapping for the query.

144. The method of claim 136, wherein the transforming the data advertisement step includes defining attributes in the subscription that represent combinations of attributes and expression operators in the data advertisement.

145. The method of claim 136, wherein the transforming the query step includes defining attributes in the notification that represent combinations of attributes and expression operators in the \query.

146. A publish-subscribe network for implementing query-response interactions, comprising routers, publisher machines and subscriber machines that include modules for executing the method of claim 136.

147. A method for implementing query-response interactions on a publish- subscribe network, comprising: receiving a query; fransforming the query to a notification; and, receiving responsive data based on content-based routing performed on the notification and a data advertisement transformed into a subscription.

148. An apparatus for implementing query-response interactions on a publish- subscribe network, comprising modules for executing the method of claim 147.

149. The apparatus of claim 148, wherein the apparatus comprises a subscriber machine.

150. A method for implementing query-response interactions on a publish- subscribe network, comprising: receiving a data advertisement; transforming the data advertisement to a subscription; receiving a query fransfoπned into a notification based on content-based routing performed on the subscription and the notification; and forwarding responsive data to a requester based on the notification.

151. An apparatus for implementing query-response interactions on a publish- subscribe network, comprising modules for executing the method of claim 150.

152. The apparatus of claim 151, wherein the apparatus comprises a publisher machine.

153. A method for implementing query-response interactions on a publish- subscribe network, comprising: receiving a notification, wherein the notification was transformed from a query; performing content-based routing (CBR) to determine whether to forward the notification to a neighboring node; and selectively forwarding the notification based upon the determination.

145. The method of claim 153, further comprising receiving a subscription, wherein the subscription was transformed from a data advertisement and wherein the performing CBR step performs CBR based on the subscription.

155. An apparatus for implementing query-response interactions on a publish- subscribe network, comprising modules for executing the method of claim 153.

156. The apparatus of claim 155, wherein the apparatus comprises a router.

157. A method for providing persistent caching of messages delivered via a publish-subscribe network, comprising the steps of:

(a) receiving, at a first node, a message having data via the network; (b) time-marking the data;

(c) caching the data in a cache memory at the first node; and

(d) routing the message to a second node using content-based routing.

158. The method of claim 157, further comprising the step of:

(e) repeating steps (a) through (d) at the second node, wherein the data is cached in a cache memory at the second node.

159. The method of claim 157, further comprising the steps of: determining if a time granularity G has passed since the caching step (c); and moving the cached data from the cache memory to a disk based on a determination that G has passed.

160. The method of claim 157, further comprising the steps of: determining if a persistent time-frame T has passed since the caching step (c) for a last block of the cached data; and deleting the cached data based on a determination that T has passed for the last block of the cached data.

161. The method of claim 160, wherein T is set based on a channel with which the data is associated.

162. The method of claim 157, wherein the first node comprises an intelligent router and the receiving step (a) receives the message at the intelligent router.

163. The method of claim 162, wherein the intelligent router includes a cache manager and the cache manager performs steps (b) and (c).

164. The method of claim 157, wherein the second node comprises a subscriber machine.

165. A router for providing persistent caching of messages delivered via a publish- subscribe network, comprising modules for executing the method of claim 157.

ill

166. A publish-subscribe network for providing persistent caching of messages, comprising nodes that include modules for executing the method of claim 158.

167. A computer-readable medium comprising instructions for executing the method of claim 157.

168. A method for providing persistent caching of messages delivered via a publish-subscribe network, comprising the steps of: receiving a message having data via the publish-subscribe network; time-marking the data; caching the data in a cache memory; determining if a time granularity G has passed since the caching step; moving the cached data to a disk based on a determination that G has passed; determining if a persistent time-frame T has passed since the caching step for a last block of the cached data; and deleting the cached data from the disk based on a determination that T has passed for the last block of the cached data.

169. The method of claim 168, further comprising the step of determining whether a request for the cached data has been received.

170. The method of claim 169, wherein the request for the cached data is received from a user machine.

171. The method of claim 169, further comprising retrieving the cached data based on a determination that a request for the cached data has been received.

172. The method of claim 171, wherein the retrieving step comprises invoking an upstream cache and retrieving the cached data from the upstream cache.

173. The method of claim 172, further comprising performing duplicate suppression on the cached data retrieved from the upstream cache.

174. The method of claim 172, wherein the retrieving step obtains a listing of upsfream caches from a user machine agent.

175. The method of claim 171, further comprising the step of transferring the cached data to a backbone router for routing to a user machine.

176. The method of claim 168, further comprising the step of indexing the cached data.

177. The method of claim 176, wherein the indexing step indexes the cached data by channel ID, subjects and/or time stamps.

178. The method of claim 168, further comprising the steps of performing the receiving, time-marking and caching steps at an upstream routing node.

179. The method of claim 168, further comprising the step of repeating the receiving step.

80. A router for providing persistent caching of messages delivered via a publish- subscribe network, comprising modules for executing the method of claim 168.

181. A publish-subscribe network for providing persistent caching of messages, comprising a first node and a second node, wherein the first node is upstream from the second node and the first node and the second node each include modules for executing the method of claim 168.

182. A computer-readable medium comprising instructions for executing the method of claim 168.

183. A method for providing persistent caching of messages delivered via a publish-subscribe network, comprising the steps of:

(a) receiving a plurality of messages having data via the network at a plurality of upstream nodes;

(b) time-marking the data;

(c) caching the data in cache memories at one or more of the plurality of upstream nodes;

(d) routing the messages to an edge node using content-based routing; and, (e) repeating steps (a) through (c) at the edge node, wherein the data is cached in a cache memory at the second node.

184. The method of claim 183, further comprising the step of routing at least one of the messages from the edge node to a subscriber machine using content-based routing.

185. The method of claim 184, further comprising the step of the edge node receiving a request for cached data from the subscriber machine.

186. The method of claim 185, further comprising the steps of: determining a time-amount of cached data to retrieve in response to the request; and, retrieving the determined time-amount of cached data based on the time-mark of the cached data.

187. The method of claim 186, wherein the time-amount is determined from the request, wherein the request includes a requested time-amount of cached data to be retrieved.

188. The method of claim 186, wherein the time-amount is determined by calculating a disconnected time for the subscriber machine, wherein the disconnected time is the amount of time that the subscriber machine was disconnected from the publish-subscribe network.

189. The method of claim 185, further comprising the step of determining that at least some requested cached data is stored at one or more of the plurality of upsfream nodes.

190. The method of claim 189, further comprising the step of the edge node receiving a list of upstream nodes from the subscriber machine.

191. The method of claim 189, further comprising the steps of: communicating the request for cached data to one or more of the plurality of upstream nodes; retrieving requested cached data from the one or more of the plurality of upsfream nodes; and, routing the retrieved data to the subscriber machine.

192. The method of claim 191, further comprising the step of performing duplicate suppression on the retrieved data.

193. A publish-subscribe network for providing persistent caching of messages, comprising a plurality of upstream nodes and an edge node, wherein the nodes include modules for executing the method of claim 183.