CN1701304B - Systems, methods and apparatus for packet routing via payload inspection in a publish-subscribe network - Google Patents

Abstract

Packet routing via payload inspection at routers in a core of a distributed network for use in distributing digital content such as video, music, and software. Packets include subjects and attributes in addition to routing information. The subjects correspond with particular types of content for subscriptions, and the attributes encapsulate the data or content, which can include video, music, or software such as software updates. The routers store filters corresponding with subscriptions to content. Upon receiving a packet, a router inspects the payload section of the packet containing the attributes in order to retrieve the attributes and apply them to the filters for the subscriptions to the digital content. If an attribute satisfies a filter, the packet is routed to the next link. If the attributes do not satisfy the filters, the router discards the packet. These routing decisions are distributed among routers in the network core.

Description

Systems, methods and apparatus for packet routing via payload inspection in a publish-subscribe network

References to related applications

This application is incorporated by reference and claims priority to US Provisional Application No. 60/394631, entitled "Packet Routing for Quality of Service Management via Payload Inspection," filed July 8, 2002. This patent application is also the following U.S. Patent Application No. 10/199,356, entitled "Packet Routing Through Payload Inspection," both filed July 19, 2002, entitled "Content-Based Routing at Routers Employing Channels" and Filtering Method and Apparatus, U.S. Patent Application No. 10/199,368, entitled "Method of Sending and Receiving Boolean Functions Over a Network," U.S. Patent Application No. 10/199,439, entitled "Used for Storing Boolean Functions in U.S. Patent Application No. 10/199369 for a method of implementing evaluation, modification, reuse, and delivery over a network, and U.S. Patent Application entitled "Efficient Implementation of Wildcard Matching on Variable-Sized Fields in Connection-Based Routing" Continuation-in-Part (CIP) of Application No. 10/199388, which is hereby incorporated by reference in its entirety.

This application also incorporates by reference the following U.S. patent applications filed March 28, 2003 and as their CIP: Application entitled "Method and Apparatus for Reliable Publishing and Ordering in an Unreliable Network" Application No. 10/400671, entitled "Method and Apparatus for Content-Based Packet Routing Using Compact Filter Storage and Offline Precomputation," and Application No. 10/400465, entitled "For Implementing Query Response in Publish-Subscribe Networks" Application No. 10/400453 entitled "Method and Apparatus for Interaction", Application No. 10/400462 entitled "Method and Apparatus for Enabling Continuous and Reliable Message Delivery", and Application No. 10/400462 entitled "Propagation of Content Filters for Publish-Subscribe Networks and devices" Application No. 10/400444.

technical field

The present invention relates to a method and apparatus for routing packets in a network core to provide an alert service based on the detection of the payload in the packets.

Background technique

Today's network bandwidth is increasing exponentially. However, the infrastructure of the network (including routers, servers, daemons, protocols, etc.) is still using relatively old technology. Therefore, the development speed of Internet application software and network routers cannot keep up with the speed of bandwidth increase. At the same time, more and more devices and applications are becoming network-enabled. The load imposed by these devices and application software on network nodes has increased significantly. The increase in network load and the number of applications makes implementing and maintaining network applications more complex. Consequently, the increase in network bandwidth and the ubiquitous use of network devices and application software has made it increasingly difficult to route and transmit data across legacy network infrastructure, especially when distributing content to subscribers.

One model for having a network push information from servers to clients is the publish-subscribe format. In this model, servers become simple publishers of information, regardless of which clients might be interested in the information or where the clients are on the network. Clients become subscribers to information, receiving delivered information as it becomes available, regardless of where in the network it was published. The network is responsible for efficiently routing published information to subscribers, matching information to valid subscriptions, and doing so in a manner that is transparent to both publishers and subscribers.

Since the server complexity is greatly reduced in the publish-subscribe model, there is no distinction between important servers and unimportant clients, or they can be combined as either publishers or subscribers, or both. equivalent. Many types of application software have a natural affinity for publish-subscribe style interactions between peers. A common theme on which many of these applications are based is that the information published and subscribed is in the form of events. For example, an investor buys or sells a stock, causing the stock price to change. A traffic accident occurred on the highway, causing traffic jams on the highway. Security breaches in software systems are discovered, leading to the development of patches for software users. One player shoots in an online game, causing the death of the virtual character manipulated by another player. All of these representative phenomena are events of interest to most subscribers and can be propagated through the network to notify those subscribers that these events have occurred. Thus, an event is nothing more than a self-contained succinct piece of information about something that happened somewhere and at a time on the network that might be of interest.

In order to instruct the network where to send published content in a publish-subscribe model, network routing decisions are typically performed by the server or publisher. A publisher stores subscriptions for the content it publishes. As new content is received or generated, the publishing facility compares that content to each subscription to identify any matches. If the content (event) satisfies the subscription, the publisher pushes the content to the corresponding subscribers through the network. This conventional publish-subscribe model places a huge burden on the publisher, especially as more and more devices become network-enabled and as the number of subscriptions increases.

As countless applications converge on the Internet, the possibilities for leveraging event notifications will become endless. However, these possibilities require a more efficient way of making routing decisions and determining when events satisfy subscriptions, thereby reducing the burden on the publisher. Therefore, a pervasive persistent event notification service can provide great value-added benefits for Internet applications as well as other applications and implementations.

Contents of the invention

A method and apparatus provide for routing packets in a network to provide alerting services. The method and device overcome the disadvantages of the prior art. One advantage of the method and apparatus includes a significant reduction in network load when processing and routing video clips. Another advantage includes reduced bandwidth requirements for routing video clips. Yet another advantage includes reduced traffic on the LAN of the digital video recorder.

In an embodiment that achieves these and other advantages, a packet is received having a header portion and a payload portion containing information related to a video clip from a particular camera. The payload portion is detected in the network core for determining whether and how to route a packet to a subscriber for information from a particular camera, and based on detection this packet is selectively routed. These and other advantages can also be realized by, for example, an apparatus having modules to perform these steps.

These and other advantages may also be realized using methods such as routing messages in a network to provide alerting services. The method includes: receiving a message having a header portion, at least one body, and at least one attribute, the attribute relating to a video clip from a particular camera; retrieving the body and attributes from the message; retrieving an order from the body; and in order to determine whether and how to route the message to Subscriber information from a specific camera, attributes are applied to the subscription in the core of the network. These and other advantages may also be realized by, for example, an apparatus comprising means for performing these steps.

Again, these and other advantages can be achieved using methods such as routing packets in a network to provide alerting services. The method includes: receiving a packet having a header portion and a payload, wherein the payload portion includes information related to an event of a particular alerting service; examining the payload portion of the packet in a network core to determine whether and how to route the packet to the subscriber alerting service information; and selectively routing the packet based on the detection. These and other advantages may also be realized by, for example, an apparatus comprising means for performing these steps.

Description of drawings

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

Figure 1 is a diagram illustrating intelligent routing in the network core.

FIG. 2 is a diagram illustrating an intelligent router for publishers and subscribers.

FIG. 3 is a diagram illustrating network infrastructure of intelligent routers and backbone routers.

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

Figure 5 is a diagram of a publisher and a user machine.

Figure 6 is a diagram of a channel manager of an intelligent router.

Figure 7 is a diagram of the software components in a user machine for interfacing the machine with an intelligent router.

FIG. 8 is a software component diagram of an intelligent router.

Fig. 9 is a packet structure diagram of a message.

Figure 10 is a flowchart of a publisher method.

Figure 11 is a flowchart of a subscriber method.

Figure 12 is a diagram of the Channels and Subscribers screen.

Fig. 13 is a flowchart of a content-based routing method.

Figure 14 is a flowchart of a caching method.

Fig. 15 is a diagram illustrating a cache index.

Figure 16 is a flowchart of a proxy method for outputting messages.

Figure 17 is a flowchart of a proxy method for incoming messages.

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

Fig. 19 is a diagram of a database structure for storing orders.

Figure 20 is a flowchart of the wildcard method.

Figure 21 is a diagram of a digital video surveillance system.

Figure 22 is a diagram illustrating an agent for a digital video surveillance system in a two-step approach.

Figure 23 is an architectural diagram of digital content delivery.

FIG. 24 is an architectural diagram illustrating Phase 1 of digital content delivery.

FIG. 25 is an architectural diagram illustrating Phase 2 of digital content delivery.

Fig. 26 is a diagram illustrating a plurality of external links of quality of service management.

Fig. 27 is a diagram illustrating a single external link of quality of service management.

Figure 28 is a diagram illustrating filtering and dynamic caching outside the ISP.

Figure 29 is a diagram of caches in the network.

Figure 30 is a diagram of a backup persistent cache in an upstream router.

Figure 31 is a diagram illustrating the interaction between caches and proxy servers and routers.

Figure 32 illustrates a diagram for creating a cache on an order.

Fig. 33 is a diagram of an index tree.

Fig. 34 is a diagram illustrating retrieval from a plurality of caches.

Figure 35 is a diagram illustrating the interaction of the cache manager with other modules in the system.

Fig. 36 is a file directory structure diagram of the cache.

Detailed ways

overview

An Internet-scale or other distributed network-level event notification system provides a powerful and flexible publish-subscribe network implementation. In this system, applications utilize an event notification application programming interface (API) to publish notifications and/or subscribe to and receive notifications about events occurring within the network.

Notifications in the system have a body, which is a string or other structure that distinguishes the type of information that the notification encapsulates. Notifications are also completed with a set of properties that contain notification-specific information. For example, an application may post a notification about trading on the New York Stock Exchange with the subject quote.nyse and the attributes symbol and price. The application can issue individual notifications with special attribute values, for example, the symbol is SNE (Sony's stock ticker symbol), and the price is 85.25. In most cases, if not all properties in a notification are predefined, then the properties in all notifications are of the same body class. However, to provide additional event-specific information, publishers MAY add arbitrary attributes on a per-notification or other basis. Therefore, not all or even any properties need to be predefined.

In this system, subscribers are not limited to subscribing only to subjects or to entire channels. Channels are further explained and defined below. They may include a hierarchy specifying, for example, a subject field and one or more levels of related subfields (subsubjects). Thus, subscribers can provide more appropriate representations of interest by specifying content-based filters on attributes of notifications. For example, a subscriber might subscribe to all notifications with a symbol of SNE and a subject quote.nyse with a price above 90.00 (indicating perhaps a sell opportunity for a stock owned by the subscriber). All notifications matching a subscription may be delivered to the subscriber through a callback or other type of functionality provided by the subscriber when registering for the subscription or at other times. A subscription can be broken down into many filters.

Callbacks can perform many computations, ranging from something as simple as writing a message to a terminal or sending an e-mail, to something more complex like initiating a sale of a stock, to something more complex like initiating a new publish-subscribe action (e.g., used in A new subscription bought at the price of 75.00 replaces an existing subscription, or a new notification is issued that the subscriber's securities have been changed).

For example, in application publishing and ordering activities are assisted by agents. A proxy may utilize or be implemented with a proxy server. Brokers, when used, provide network connectivity for outgoing notifications and ordering and delivery of incoming matching notifications to subscribers. Once a notification enters the network, the routers of the system's network propagate the notification to all subscribers whose subscriptions match the notification. One way to achieve this propagation is to broadcast the notification to all points in the network, and let the application agent decide whether the notification is relevant to the subscriber. However, this is an approach that does not need to scale, and the network is often quickly overloaded with excessive message traffic, especially when there are a large number of active and lengthy publishers. Even if there is enough bandwidth, the subscriber will be heavily burdened by the need to process many notifications.

The exemplary network of the present system is more efficient at routing notifications. First, multicast routing can be used to ensure that notifications are propagated at most once, for example, across any connection in the network. Second, a number of advanced optimizations can be applied to filters to minimize the propagation of notifications.

Figure 1 is a diagram conceptually illustrating such an intelligent router in the core of a network. For a publish-subscribe network, the publisher 14 transmits the contents of the message to the network core 10 through the edge router 16 . A publish-subscribe network includes any type of network that routes data or content from publishers to subscribers. Content is transported over one or more channels 18 representing logical connections between routers or other devices. It is up to the intelligent router 12 in the network core 10 to determine whether to route or forward the message. Specifically, intelligent router 12 may determine whether the message contains content subscribed to by subscriber 24 .

Each subscription encapsulates subject filters and attribute filters. The router can expand subject filters to the set of matching subjects, merging attribute filters on a per-subject basis. The intelligent router evaluates the body filter against the body of the notification and the attribute filter against the attribute values in the notification. The syntax for body filters can use wildcards, and the syntax for attribute filters can use Boolean expressions, both of which are explained in detail below. The term "filter" is used to describe a set of events that a subscriber is interested in receiving from a publisher. Routing rules are generated by filters and used by intelligent routers to make routing decisions.

Thus, if a message 26 does not satisfy the entire set of filters, for example, the intelligent router 12 drops (drops) the message 26, meaning that the message is no longer forwarded. For example, if any one of the filters in the entire set is satisfied by the message 20 based on the evaluation of the body and attribute filters, intelligent router 12 passes the edge Router 22 and possibly other devices to route (forward) message 20 to subscriber 24 , or utilize message 20 to perform other functions internal to router 12 . This search will continue until the entire filter set is exhausted or decisions on all rules have been obtained, whichever happens first.

These intelligent routes based on content routing in the core of the network provide the delivery of real-time data such as alerts and updates. Examples of real-time data delivery for alerts include, but are not limited to, stock quotes, business, 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, software updates, antivirus updates, movie and music delivery, workflow, storage management, and cache coherency. Many other applications can be used to deliver ordering information.

Table 1 illustrates the storage of subscriptions with subjects and predicates on filtering. They can be stored anywhere on the network in any type of data structure desired or needed. As described below, predicates are an integral part of ordering. Ordering can be expressed in any number of ways, examples of which are provided below.

Table 2 provides an example of publishing and ordering on the quote server. This example is provided for illustration purposes only, an order may include any number and type of parameters for any type of data or content.

The assertion provides a Boolean expression to order, while the body provides an indication of the ordering channel. Ordering can be expressed in many different ways. The use of boolean expressions is one such example and provides the ability to easily convert ordering into body filters and attribute filters for content-based routing. Or an order may be expressed without reference to a subject; however, employing a subject or a channel (explained further below) provides an environment for interpreting and applying filters to attributes.

Routing decisions can be made in the core of the network and distributed throughout the network, reducing the processing burden on publisher and subscriber machines and significantly improving network efficiency. For illustration purposes only, Figure 1 shows a publisher, a subscriber, and an intelligent router; implementations may include many publishers, subscribers, and intelligent routers. The term intelligent router refers to a router or other entity capable of making routing decisions by inspecting the payload of packets or messages at the network core or elsewhere.

network infrastructure

Figure 2 is a network diagram of intelligent routers illustrating publishers and subscribers. For example, routing entities 30 that provide channel services are actually layered on the network infrastructure for routing messages between intelligent routers, as described below. Publisher 32 conceptually includes applications 34 for receiving indications of published content, such as pointers to retrieve content, for example, and proxies 36 for encoding content transmitted over the network of channel service 30 , and proxies 36 . A set of logically interconnected intelligent routers 38, 40, 42, 44, 46, and 48 employ the routing rules generated by the subscribed body filters and attribute filters to route content from publishers. A plurality of links 39 , 41 , 43 and 45 provide logical connections between intelligent routers 38 , 40 , 42 , 44 , 46 and 48 . Other links 37 and 47 provide logical connections between publisher 32 and intelligent router 38 and between subscriber 54 and intelligent router 46, respectively. A subscriber 54 includes an agent 50 to detect and receive ordered content, and an application 52 to display the content.

A channel may comprise, for example, a related logical set of multicast connections implemented in a distributed manner. A channel in the exemplary embodiment is a logically related collection of network resources used to exchange content for an affiliate of publishers and subscribers. Classify content according to the namespace of the channel subject, and manage, control and provision these resources through the channel service provided by the channel manager. Multiple channels can share the same resource. Channels may provide highly scalable directory services such as, but not limited to, publisher and subscriber information, authentication and authorization information, message types, administrative information, and billing and charging information, for example. Channels may also provide mechanisms such as persistent, fast data delivery during caching, security, and user and network management. Channels can also be used for any other purpose.

Filtering by intelligent routers can occur in the network core to distribute routing decisions. In addition, intelligent routers can also be used as edge routers connecting user devices (such as publishers or subscribers) with the network core. Moreover, the same devices connected to the network Can act either as a publisher to push content to subscribers through routing decisions in the network, or as a subscriber to receive pushed content. Intelligent routers and channels can be in any configuration as required or desired for a particular implementation ) and the configuration shown in Figure 2 is provided for illustration purposes only.

Figure 3 is a diagram of an exemplary network infrastructure of intelligent routers and traditional backbone routers, which also illustrates the logical connection of channels. The intelligent router in this example adopts an existing backbone router in a network (such as the Internet or other distribution network), and the intelligent router is actually layered on the backbone router here. 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 to one or more backbone routers in the ISP networks 58 , 59 and 60 . The intelligent routers 61-70 are also interconnected by a plurality of links 73-85 (representative examples of links), and end-user devices may also be connected by these links. Intelligent routers 61-70 may be controlled by one or more supervisors (such as entity 71) and one or more virtual private network (VPN) controllers (such as entity 72). The ISP networks 58, 59 and 60 also connect to publisher and subscriber machines (not shown in Figure 3). Backbone routers in and between ISPs 58, 59 and 60 may be interconnected in any conventional manner within the existing network infrastructure.

Intelligent routers 61-70 and links 73-85 as described above can be implemented using existing network infrastructure, which provide content-based routing in the core of the network. Links 73-85 represent logical connections between intelligent routers 61-70 and may be implemented using, for example, existing network infrastructure or other equipment. For example, links can be implemented using logical connections called tunnels. A tunnel includes the hardware, and possibly software, network infrastructure used to implement the link, and a tunnel can be a component of multiple channels. Channels facilitate content-based routing in intelligent routers by providing a logical configuration for specific types of content and thereby providing context for attributes transmitted over the channel. While intelligent routers can perform routing decisions without channels, channels increase the efficiency of content-based routing by intelligent routers in the network core.

This exemplary embodiment includes the use of channels and links. A link is a connection between two routers, even smart ones. A channel is a network entity (usually large) consisting of a collection of routers, which are statically or dynamically configured through interconnected links to complete one-to-many or many-to-many logical connections. Specifically, a channel is a top-level logical entity that describes the basic characteristics of a channel. There may be many principals under one channel. Individual subjects will form subnetworks (eg, multicast trees) involving collections of interconnected routers. These principal-based subnets can be assigned, directed, and configured in different ways. A channel as a collection of all subnets within which a subject is constituted may resemble, for example, a mesh network.

FIG. 4 is a diagram of exemplary hardware components of intelligent router 92, which may correspond to any of the other referenced intelligent routers. Network node 90 may include an intelligent router 92 connected to a traditional backbone router 95 . The intelligent router 92 includes a processor 93 connected to a memory 94 and a secondary storage device 97 (possibly implemented, for example, as separate machines), either of which can store data and also cache data , and may store applications executed by the processor 93. Secondary storage device 97 provides non-volatile data storage. Under software control as explained below, processor 93 provides instructions to backbone router 95 so that it can route (forward) or not route (drop) messages or packets based on the routing rules generated by the subject filter and attribute filter for the subscription . Although shown as being implemented in a stand-alone processor-controlled device, intelligent router 92 may optionally be implemented within backbone router 95 using an application-specific integrated circuit (ASIC) so that the intelligence may be provided in hardware, possibly with embedded software. Routing function. Alternatively, the intelligent routing function can also be realized by a combination of software and hardware of one or more routing devices.

Figure 5 is a diagram of exemplary publisher and subscriber machines. A publisher machine 100 or 118 may include the following components: memory 102 to store one or more publisher applications 104 and broker applications 105; secondary storage to provide non-volatile data storage device 112; input device 108 for inputting information or commands; processor 114 for executing applications stored in memory 102 or received from other storage devices; output device 110 for outputting information; and for providing visual A display device for displaying information 116.

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

Publisher machines 100 and 118 are connected to subscriber machines 122 and 140 via network 120, such as the network described above. Network 120 includes intelligent routers for providing distributed routing of data or content by packets or messages in the network core. Although only two publisher and subscriber machines are shown, network 120 can be scaled to include more publisher and subscriber machines. Publisher and subscriber machines may be implemented with any processor-controlled device, such as including but not limited to the following examples: servers; personal computers; notebook computers; personal digital assistants; telephones; cellular phones; pagers; or other devices. Network 120 with intelligent routers may include any wired or wireless distribution network that connects hardwired devices, wireless devices, or both. It is also possible for network 120 to utilize existing or legacy network infrastructure.

FIG. 6 is a diagram illustrating the channel manager 150 of the intelligent router. In this example, channel manager 150 is implemented with a plurality of servers 152 , 154 and 156 . Each server includes its own local storage 158 , 160 and 162 . Intelligent routers 164, 166 and 168 contact the channel manager for information about a particular channel. The channel manager may also provide data persistence, fault skip functionality, or other functions. The channel manager thus provides channel services comprising a database or a set of databases anywhere in the network specifying, for example, channel-related information, data persistence characteristics, user information for publishers and subscribers, and infrastructure information. Infrastructure information may include, for example, the identities of the intelligent routers and the corresponding tunnels connecting them, the principals of the channels, and the attributes of the channels (name and type of each attribute). Packets or messages can also carry channel-related information, including identification of fixed and variable attributes.

Users can download channel information while online. For example, a user may log in by using a username and password. When a user's login is authenticated, the user can open (activate) a channel and retrieve information about the channel from the channel manager. Publishers can use this information when publishing content, and subscribers can use this information to enter and register for subscriptions.

Channel managers 152, 154, and 156 preferably form a team to perform a persistent and reliable channel directory service. One of the channel managers will act as the primary channel manager and the other as backup channel managers. If the primary channel manager fails, the primary channel manager's adjacent channel managers will take over as the new primary channel manager to maintain reliable service. Each intelligent router retains the addresses of these channel managers. If one channel manager is not reachable by the intelligent router, it will look for another to retrieve the information. For example, devices in the network may employ commands to retrieve channel information, some examples of which are provided in Table 3. Alternatively, an intelligent router may have only a primary channel manager or more than two channel managers.

FIG. 7 is a diagram of exemplary software components within a stack 180 in a user machine or device for connecting the user machine or device to a network with an intelligent router. A client machine can act as a publisher, subscriber, or both, and it can include the exemplary devices identified above. Stack 180 may include one or more user applications 182 that may provide for receiving subscriptions from users, receiving channel information from publishers, or receiving content or data to be published. User applications 182 may also include any other type of application executed by a user machine or device.

The stack 180 may 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. The agent 184 provides for establishing a network connection or other functions, and Table 3 provides the information implemented by the agent 184. example of a command, which may use a proxy server command or other types of commands. Event repository 186 records events or other events or information about the user machine. Cache repository 188 provides local cache data. Channel repository 190 stores the identification of the channel and its Information. Dispatcher library 194 provides connectivity to control path 196, channel manager 198, and one or more intelligent routers 200, and it may include exemplary functionality identified in Table 4. Messaging library 192 provides connectivity to data path 204 Connection.

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

table 5 API example for sending messages PC_Status    PC_msg_init(ChannelHandle ch，PC_UINT chld，PC_UINT userid，PC_TypeInfo*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_setSubject(PC_msg_MsgHandle msg，PC_char*subject)；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 typePC_Status PC_msg_setAttrByPosInt(PC_msg_MsgHandle msg, PC_UINT attributePos, PC_INT Value); //for each typePC_Status PC_msg_addAttrInt(PC_msg_MsgHandle_char_value); typePC_Status PC_msg_send(PC_msg_MsgHandle msg); Table 6 API example for retrieving messages

table 5 typedef struct_attribute{PC_char              *name；PC_TypeCode          type；void                 *value；PC_UINT              arraySize；}PC_msg_Attribute；typedef struct_attributeArray{PC_UINT                      size；PC_msg_Attribute     **attrs；}PC_msg_AttributeArray；PC_Status PC_msg_init(ChannelHandle ch，PC_UINT chld，PC_UINT userid，PC_TypeInfo*MsgType， PC_INT msgTypeSize，PC_msg_SessionHandle*sess)；PC_Status PC_msg_cleanup(PC_msg_SessionHandle sess)；PC_Status PC_msg_recv(PC_msg_SessionHandle sh，PC_msg_MsgHandle*msg)；PC_Status PC_msg_ctrlRecv(PC_msg_SessionHandle sh，PC_msg_MsgHandle*msg)；PC_Status PC_msg_getSequenceNum(PC_msg_MsgHandle msg，PC_UINT*seqNo)；

table 5 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，PC_USHORT**subjectArray，PC_INT*size)；PC_Status  PC_msg_getDataType(PC_msg_MsgHandle hMsg，PC_msg_DataTyPe*dataType)； PC_Status  PC_msg_getAttrByPosInt(PC_msg_MsgHandle msg，PC_UINT pos，PC_INT*val)；//for each typePC_Status  PC_msg_getAttrValueByNameInt(PC_msg_MsgHandle msg，const PC_char*name，PC_INT*val)；PC_Status  PC_msg_getAttrTypes(PC_msg_MsgHandle msg，PC_TypeCode*Types，PC_INT*arraySize)；PC_Status PC_msg_getAttributeByPos(PC_msg_MsgHandle msg，PC_UINT 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_msg _freeAttribute(PC_msgAttribute*attr); Void PC_msg_freeAttributeArray(PC_msg_AttributeArray*attrArray); Table 7 API example for sending notifications

table 5 ChannelHandle ch; PC_msg_MsgHandle msg; PC_msg_SessionHandle sh; PC_msg_TypeInfo Types[2]; Types[0].type=PC_STRING_TYPE; Types[0].name="company" Types[1].type=PC_INT_TYPE; "stockvalue" PC_msg_init(ch, chld, userld, 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 API for retrieving notifications

table 5 ChannelHandle ch; PC_msg_MsgHandle msg: PC_msg_SessionHandle sh; PC_msg_TypeInfo Types[2]; PC_msg_AttributeArray*attrArray; PC_char*company; type = PC_INT_TYPE; Types[1].name = "stockvalue" PC_msg_init(ch, chld, userld, Types, 2, &sh); While(1) { PC_msg_recv(sh, &msg); PC_msg_getAttrValueByPosString(msg, 0, &company); PC_msg_getAttrValueByNameInt(msg, "stockvalue", &value); PC_msg_getDynamicAttributes(msg, &attrArray);PC_msg_freeAttributeArray(attrArray);PC_msg_delete(msg); } PC_msg_closeTransport(sh); PC_msg_cleanup(sh);

FIG. 8 is a diagram of exemplary software components 210 of intelligent routers such as those identified above, as well as intelligent router 92 shown in FIG. 4 . Software components 210 may be stored, for example, in memory 94 for execution by processor 93 in intelligent router 92 . Components 210 include, for example, filter daemon 212 , distributor 214 , routing daemon 216 , and cache manager 218 . The filtering daemon 212 provides content routing based filtering to process ordered content according to routing rules as explained below. Distributor 214 provides communication of control messages such as those needed to propagate the filter via path 220, and the distributor may also provide a single point of entry for the user as well as a channel manager for a security plugin, thereby increasing the security of the network . In other words, users do not contact the channel manager directly in this example, although they could do so in alternative implementations. Distributor 214 uses control messages to obtain attributes (name-value pairs) from the channel manager.

Routing daemon 216 provides communication with data path 222, which may be via a conventional backbone router as illustrated in FIG. 4 or other routing device. Cache manager 218 provides local cache data on network nodes including corresponding intelligent routers. The operation of the cache manager 218, which provides a distributed cache of data throughout the network core, is explained further below.

As an alternative to the application level, content-based routing can be implemented at the kernel level. The memory accessible by the kernel is independent of the memory in the application layer. For content-based routing to work in an application, it is necessary, for example, to copy message data from the kernel memory area to the application area, and to switch the application context from the kernel context to the routing application context. Both incur significant overhead. If instead the kernel is modified to support content-based routing, faster routing can be done, thereby getting rid of the overhead described above.

Because of this feature of content-based routing in the kernel, the routing daemon 216 may or may not, depending on the implementation, send or receive data directly via the datapath 222. A daemon is a process running at the application layer that precomputes the Content-based routing table in . However, once a content-based routing table is inserted, the routing table can be used by the kernel to make routing decisions. Likewise, the filtering daemon precomputes the filtering table and inserts it into the kernel. In this kernel implementation, Neither the routing daemon nor the filtering daemon can directly interact with the datapath.

FIG. 9 is a diagram of an example of a packet structure 230 of messages that may include ordering content. A packet or message for content-based routing includes, for example, a header portion and a payload portion. The header section specifies routing or other information. The payload portion specifies data or content, or an indication of 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 body fields 240 , and one or more attributes 242 . Packet structure 230 illustrates the basic structure with respect to length values as well as bodies and attributes. Content-based routing packets may also include other or different elements, such as those illustrated in the example of FIG. 18 explained below, and content-routing based packets may be configured in any manner. Also, these attributes may include, for example, discretionary attributes appended to the end of the message. These free attributes are ad hoc information added eg by publishers (or even routers), which may not necessarily be conveyed in the message format specified for the channel.

Publisher and Subscriber Methodology

10 is a flowchart of an exemplary publisher method 250 used by a publisher to establish a channel and publish content. Method 250 may be implemented in software modules including, for example, agent 106 executed by processor 114 in publisher machine 100 . In method 150, proxy 106 in the publisher machine receives the publisher's creation of a proxy server for the channel (step 252). A proxy server provides communication with the network. The agent 106 determines the message format of the channel through the interface (step 253), and this format information may be obtained from, for example, the channel manager or other entities in the network. Proxy 106 uses the received channel information to establish a proxy server for the channel (step 254), which includes receiving the attributes of the channel (step 256) and creating notifications on the channel (step 258). The notification provides content to devices that "listen" for content on the channel. Properties define the parameters and characteristics of the notification.

The agent 106 sends the content information and the identifier (ID) of the channel to an intelligent router in the network core or wherever else used to process the subscription (step 260). The publisher populates the notification attributes with appropriate values (step 261), and the publisher can then publish content about the notification according to the channel attributes (step 262). In this example, steps 260-262 accomplish publishing the notification, or this may require different or additional steps depending on the particular implementation. Thus, the information associated with the notification in this example is divided into an ordered sequence of attributes, each having a name, a position within the notification (starting at 1), a type, and a value. Alternatively, properties may have different characteristics depending on the particular implementation. Attributes may include, for example, predefined attributes, free attributes, or both.

An intelligent router can use the channel ID in the packet to obtain attributes of the corresponding channel, which determine the structure or format of the packet transmitted over the channel. Specifically, each packet may contain, for example, a marker associated with a channel ID and other header information such as a publisher ID and a body. These tokens can be used to map bodies to numbers in message formats, an example of which is shown in Figure 18. Small integer values (such as sixteen-bit values) can be used as these numbers. Alternatively, these subjects can be mapped with any other type of number or information. Mapping subjects to numbers has particular benefits; for example, it saves space in message formats and provides a uniform or standard way to specify indications of subjects in messages so that they can be quickly located and identified. The smart router can store the mapping locally, or it can also use the numbers to remotely obtain the corresponding principal through commands.

Table 10 illustrates the structure used to map numbers to subjects, in this example taking integer values. The subject tree parameter in the table indicates that a subject may include one or more subject fields in a hierarchical relationship; for example, a subject tree may consist of a string Subject fields delimited by specific symbols. An example of a subject tree is provided in Table 2. As an example, the subject tree quotes.nyse includes the subject "quotes" and the subfield "nyse", which are used, for example, in URLs or other network addresses The found "." is used to delimit. In addition to using the period and the specified URL type string, any character and symbol used for delimiting can also be used to specify the subject tree.

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

Table 11 provides examples of publisher programs 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 profile maintained by a channel manager (see FIG. 6) and providing channel-related information, as shown in the table. Alternatively, to distribute the processing load, the system may have a global channel manager to provide IP addresses of geographically dispersed servers, where these servers are used as local channel managers.

Table 11 Publisher program example #include "PC_evn_Notification.h" #include "PC_evn_Proxy.h" using namespace precache::event; int main(int argc, char argv[]) { PC_UINT QuotesRUs = myChannelofInterest; //channel IDPC_UINT myID = myPublisherID; //publisher ID

try{Proxy p(QuotesRUs, myID); Notification n1(p, "quotes.nyse"); n1.SetPredefinedAttr("symbol", "LUS"); n1.SetPredefinedAttr(price", 95.73); p.Publish(n1 ); Notification n2(p, "quotes.nyse"); n2.SetPredefinedAttr(1, "SNE"); //attribute symbol is in position 1 n2.SetPredefinedAttr(2, 80.18); //attribute price is in position 2p. Publish(n2); }catch(InvalidChannelException icex){cerr<<"bad channel"<<end1;}catch InvalidSubjectException isex){}catch(InvalidNotificationException inex){cerr<<"bad notification"<<end1;}catch( Exception ex){cerr<<"unknown error"<<end1; }} Table 12 API examples for creating channels

PC_Status rc; rc = PC_chn_create(Provider_info, authinfo, ConfigurationFile, &hChannel); /*the first one primary channel manager*/rc = PC_chn_addChannelManager(hChannel, "10.0.1.1"); /*secondary channel manager*/rc(Channel_addManager hChannel, "10.0.2.2"); */rc = PC_chn_setProperties(hChannel, ConfigurationFile); /*Set the message type(only in fixed part of the message) by using rc = PC_chn_setAttributeType(hChannel, name, position, attributeType). The type information is propagated to all edge routers.*/rc=PC_chn_setAttributeType(hChannel,"Priority", 1, PC_UINT 16_TYPE); rc=PC_chn_setAttributeType(hChannel,"Alarm_Name", 2, PC_STRING_TYPE); rc=PC_chn_setAttributeType(hChannel, "hChannel" Alarm_Time", 3, PC_INT32_TYPE);

rc＝PC_chn_updateAttribute(hChannel); rc＝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 nnel 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.1RouterIP＝test3RouterPort＝12345ProxyPort＝9015ProxyCtrlPort＝9016[ChannelSubjects 5]NumberOfSubjects＝map CR＝2 = 0.100 subject2 = Quotes.Nysemapping2 = 102.101 [ChannelAttributes 5] NumberOfAttributes = 4name1 = StockIdtype1 = PC_UINT_TYPEname2 = Companytype2 = PC_charARRAY_TYPEname3 = Pricetype3 = PC_FLOAT_TYPEname4 = Volumetype4 = PC_UINT_TYPE

FIG. 11 is a flowchart of a subscriber method 264 for receiving and processing subscriptions. Method 266 may be implemented in software modules including, for example, agent 128 executed by processor 134 in subscriber machine 122 . In method 264 , a graphical user interface (GUI), for example, displays an indication of available channels to the user (step 266 ), which may be done with application 126 . Information identifying a channel may be received, for example, from a channel manager that provides channel-related information. The identification of the channel may be displayed by any type of application 126 in any particular manner or format. The application receives the user's channel selection (step 268) and calls an API or other program for the selected channel (step 270). The API provides the user with subscription options for the channel corresponding to the selected option (step 272). The API receives the order value from the user (step 274) and sends the order to the broker 128 for processing as described below (step 276).

Ordering parameters may include assertions such as those shown in Table 1. For example, each channel may utilize its own API in order to process ordering according to specific needs or parameters of the corresponding channel. These APIs may include, for example, web-based or Java-based APIs for receiving orders, and may employ any type of user interface and processing to receive ordered information and pass it on to the broker application.

12 is a diagram conceptually illustrating channel and subscriber screens or GUIs 278 and 284, which may be used in conjunction with method 264 of receiving an order. Screen 278 includes a plurality of fields 282 identifying available channels for user selection. When a particular channel is selected, a screen 284 may be displayed for receiving the user's subscription values in field 286 . A user may select field 288 to submit an order or field 290 to cancel an order. Screens 278 and 284 may be formatted, for example, as hypertext markup language (HTML) web pages or in any other format. Furthermore, the screen may include any configuration of regions and content, possibly including, for example, text, drawings, pictures, various colors or multimedia information, in order to provide a user-friendly and visually appealing interface to the subscriber as desired. These screens may also include toolbars 280 that provide, for example, traditional browser functionality.

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

Table 14 Subscriber program example

Table 14 #include<unistd.h>#include<iostream>#include "PC_evn_Filter.h" #include "PC_evn_Subscription.h" #include "PC_evn_Proxy.h" using namespace precache::event; class SubscriberApp: public Subscriber{private": PC_UINT notificationCount=0; public: SubscriberApp(){}//default constructor void run(){PC_UINT QuotesRUs＝myChannelofInterest; //channel IDPC_UINT myID＝myPublisherID; ::GetFilterFactory(); Filter* f=factory->CreateFilter(p, "symbol=\"LU\""); PC_INT c1=0; SubscriptionHandle sh=p.Subscribe("quotes.nyse", f, this, (void*)&c1); while(notificationCount＜2){ //let notify() get some//notificationssleep(5);}p.Unsubscribe(sh);}catch(InvalidChannelException icex){cerr＜＜“bad channel "<<end1;}catch(InvalidSubjectException isex){cerr<<"bad subject"<<end1;}

Table 14 catch(InvalidChannelException ifex){cerr<<"bad filter"<<end1;}catch(InvalidSubscriptionHandleException isex){cerr<<"bas subscription handle"<<end1;}catch(Exception ex){cerr<<"unknown error" ＜＜end1;}}void Notify(Notification*n，void*c)//this is the callback method{if(*(PC_INT*)c＝＝0){//check the closure objectPC_STRING symbol; PC_FLOAT price; n ->GetPredefinedAttr("symbol", symbol); n->GetPredefinedAttr("price", price); cout<<"The price of"<<symbol<<"is"<<price<<end1; notificationCount++; }} }; int main(int argc, char argv[]) { SubscriberApp a; a.run(); }

Content-based routing and channeling via payload inspection

13 is a flowchart of a method 300 of content-based routing through payload inspection. Method 300 may be implemented, for example, as a software module executed by processor 93 in intelligent router 92 , as represented by filter daemon 212 . Alternatively, it can be implemented with an ASIC or a combination of hardware and software. The content-based routing illustrated in method 300 may be performed in an intelligent router or in an edge router anywhere in the network, such as the core of the network.

In a general sense, content-based routing involves examining the payload portion of a packet in order to determine how to process the packet. This content-based routing approach may include, for example, processing ordered lists in any order (e.g., with filters), body-by-body, and attribute-by-attribute The message is compared with routing rules in order to determine the routing of the message and perform the processing in the core of the network. These rules may include rules governing processing within routers or any rules associated with filters. These routing decisions may thus be distributed over Throughout the core of the network, message formats are determined using entities represented by channels, e.g. by knowing their byte position within a message or packet for a particular channel, thereby providing a way for intelligent routers to quickly locate attributes within a message.

In method 300, intelligent router 92 receives a message packet (step 302). It determines the channel ID of the corresponding message from the group (step 304), and uses the channel ID to retrieve the attributes of the channel (step 306). In this example, the channel type (determined from the channel ID) determines the location and data type of the attribute in the packet. Channel properties may be stored locally or retrieved remotely, such as through a channel manager. Intelligent router 92 retrieves the filter corresponding to the subscription (step 308). The filter consists of one or more property tests, usually a set of property tests for ordering. Intelligent router 92 applies the attributes in the packet to the corresponding attribute tests in the filter description (step 310).

If all attribute tests in the filter description yield positive results (step 312), meaning that the attribute satisfies all attribute tests, the intelligent router performs a set of functions specified by the rules associated with the filter (step 314). These functions may include, for example, routing the packet to the next link, and/or using the content of the packet to perform some action or computation at the local router as specified by these rules. 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 may include an intelligent router, backbone router, network-connected device, or other entity. Alternatively, a next link can be designated or otherwise associated with the subscription.

If all of the property tests in the filter description yield no positive results (step 312), it means that the property does not satisfy all of the property tests and the filter is declared a mismatch (step 315). The smart router continues the above process recursively until all property tests in the filter description are exhausted or the first negative result is encountered, whichever comes first.

Once all attribute tests for this filter have been processed, the intelligent router determines whether there are more filters (step 316), and if so, it returns to step 308 to retrieve the attribute test for the next filter to be processed for it The property. The matching process (steps 308, 310, 312, 314, 315, and 316) continues until the complete filter set is exhausted or all action or routing rule outcomes can be determined, whichever comes first. If a packet does not satisfy any filter, it is dropped (dropped) and not forwarded.

Intelligent router 92 may sequence through the filters in any particular order. For example, as shown in Table 15, an intelligent router may store ordered filters in a file or routing table and sequence through them linearly to apply attributes to the filters (attribute test). Alternatively, the routing table may include links or pointers to filters.

Optionally, content-based routing can employ more than one method at the same time, depending on eg application and performance-enhancing heuristics, such as algorithm switching based on traffic conditions. Filters for processing are optionally encrypted, decrypted, converted, and merged at routers in the network to perform payload portion inspection for content-based routing. For example, an order such as price > $3.54122 may be truncated to a price > $3.54 since it is known that publications in the application do not contain currency attributes beyond the second decimal point. Furthermore, it is better to convert the foreign currency into the U.S. currency when the issue sent from overseas reaches, for example, the first router located in the United States.

As an alternative to the linear approach, intelligent router 92 may select filters for processing in other orders or according to various algorithms that potentially increase processing speed and efficiency. Table 16 provides examples of ordering and corresponding links for ordering ; in these examples, the subject is associated with a particular channel, and the ordering for the subject may be represented by the routing rules of the filter. The subject may include, for example, a network address (such as a Uniform Resource Locator (URL) identifying the source of the content).

Caches on network nodes

14 is a flow diagram of a caching method 320. The method 320 may be implemented, for example, as a software module executed by the processor 93 in the intelligent router 92, as represented by the cache manager 218. Alternatively, it may be implemented in an ASIC or hardware and software Combining is implemented in the same or different physical device as the corresponding intelligent router. In method 320, intelligent router 92 receives a message containing data or content, a channel ID, and a body (step 322). Intelligent router 92 time-stamps the data (step 324), and caches it locally, e.g., in memory 94 or secondary storage 97 (step 326). It indexes the cached data by, for example, channel ID, subject, and timestamp (step 328).

If intelligent router 92 receives a request for data (step 330), it uses the index to retrieve cached data according to the request (step 332). Intelligent router 92 passes the cached data to backbone router 95 or other routing entity for eventual transmission to the requester or others. Method 320 may be executed repeatedly to continuously cache data and retrieve cached data in response to requests.

FIG. 15 is a diagram illustrating a cache index ( 336 ) used with method 320 . The cache index (336) receives the data (338) and stores it with a timestamp (340). When collecting data, the data is marked at intervals of delta (delta) t, where deltat represents the time between markings, for example, t ₂ -t ₁ . Other index types that are time-stamped in any manner may also be used.

Table 17 conceptually illustrates the indexing of cached data. Table 18 conceptually illustrates the data structure used to store connection history with respect to the cache. Table 19 provides an example of a data structure for locally caching data in a network node containing an intelligent router.

Timestamping can be done at any fixed or variable interval. For example, data can be cached and indexed every five minutes. Upon receiving a command (such as #.getCache) to retrieve cached data for a specified time and subject, channel manager 218 utilizes the cache index to determine whether it can retrieve cached data corresponding to the request of step 332 .

Each principal or channel may include its own IP address, eg in a multicast tree and a set of intelligent routers. Therefore, Table 18 shows the connection history between such routers, which can be stored locally in the client machine; if the edge router fails, the client machine can access the connection history to determine how to connect to the channel when the edge router comes back online. The upstream router reconnects. For example, it may also execute cached commands while it is disconnected in order to obtain any pending subscriptions.

Table 19 Example of a Smart Router's Cache Data Structure channel node Struct ChannelNode{PC_UINT           unChanld；PC_AttributeInfo  *pAttrinfo；PC_BOOL           bPersistent；/*Persistent or RT*/PC_UINT           unTimeout；PC_UINT           unTimeGranularity；/* in minutes*/PC_INT            nDirFd；HashTable         *pFirstLevelSubjs；} main node Struct SubjectNode{PC_USHORT unSubjectld; PC_UINT unSubjLevel; Void pParent; /*Channel or Subject*/PC_INT nDirFd; HashTable p *pNextLevel *pNode js; data node

Table 19 Struct DataNode {PC_INT nDirFd; SubjectNode *pParent; LastTimeGrainNode *pLastTGrainData; DLIST *pStoredData; /*list StoredTimeGrainNode*/PC_Mutex mStoredDataLock;} Stored time granularity nodes Struct StoredTimeGrainNode{ PC_UINT unStartTime; /*in minutes*/Chanld; PC_UINT unEndTime; /*in minutes*/PC_INT nFd;} Final Time Granularity Node Struct LastTimeGrainNode{PC_char pLastTGrainData; /*could be a list*/PC_UINT unLastTGrainStartTime; PC_BOOL bReadyToStore; PC_Mutex mCachedDataLock;}

These exemplary data structures include the following information. A principal node contains a principal identifier, a principal level, a pointer to a parent channel or principal node, a file descriptor for its own directory, a pointer to a hash table containing its subordinate principal nodes, and a pointer to a data node pointer. A data node contains a pointer to its principal parent, a file descriptor for the data directory, a ring buffer containing data structures for the data stored on each storage device, the buffer's head and tail, and the and the lock that locks the data node during storage. The stored time granularity node is a node that represents the actual data file, and the last time granularity node represents the last buffer that has not been stored in the storage device but is maintained in the memory. The cache and data store threads in this example utilize the last time granularity node's mutex to prevent concurrent access to the last time granularity node.

proxy processing

16 is a flowchart of a proxy method 350 for outputting order messages. The method 350 may be implemented, for example, with a software module as represented by the proxy 128, where the software module is executed by the processor 134 in the user (subscriber) machine 122. In method 350, agent 128 receives an order (step 352) as described above using the method in FIGS. If there is an error, the agent 128 may provide an error message to the user (step 360) so that the user corrects the error and re-enters the order. If the order does not contain an error (step 358), the agent 128 stores the expression In the data structure (step 362), an example of which is provided below. The agent 128 transforms the inequality expressions composed in the data structure into positive form (step 364), and transforms the data structure into the corresponding disjunctive normal form (DNF: disjunctive normal form) structure (step 366). Agent 128 also simplifies the "AND" expression of the DNF structure to include only range filters and membership tests (step 368).

DNF is a well-known canonical form in which a Boolean expression is expressed as an "or" of one or more so-called disjoint subexpressions, each as an "and" of one or more property tests. For example, the Boolean expression (price>=10 "and" (symbol == "LU" "or" symbol == "T")) has an equivalent DNF representation ((price>=10 "and" symbol == "LU" ) "or" (price>=10 "and" symbol == "T")).

The conversion in step 364 involves converting an expression with an "not equal" operator (denoted != in the exemplary syntax) into an equivalent "positive" form that specifies all allowable values rather than a not equal allowable value. This transformation is performed before the DNF is created, and is necessary because the router in this example requires a formula in a regular shape. For example the expression (price!=80) can be converted to an equivalent regular expression (price<=79 or price>=81).

The transformation in step 368 is performed after the DNF is created and involves an additional simplification of the resulting AND expression, which in this example is also performed to simplify the work of the router. Specifically, the "and" of multiple attribute tests for the same property can be reduced in the case of equality tests to either " scope filter". Specific types of range filters are coded according to Table 22.

For example, the expression (price>=10 "and" price<=80" and "price>=20" and" price<=100) can be reduced to expression (price>=20 and price<=80), which is Example of a range filter with lower and upper bounds. The following are simplified examples of other categories: (price>=20) (lower bound only); (price<=80) (upper bound only); and (price==50) (single value). When creating these range filters, it is also possible to reduce some subexpressions to "true" or "false", in which case subexpressions can be eliminated according to the rules of Boolean algebra, thereby further optimizing the The encoding of the expression. For example, the expression (price >= 50" and "price <= 20") is simplified to "false" because there is no value for "price" that satisfies the expression. In the specific case of reducing the entire filter expression to "false", the broker does not have to create the message at all, thereby relieving the router of unnecessary work.

If the subject filters contain wildcards, the agent 128 optionally converts them as described below (step 370). Alternatively, any wildcards can be translated on the network rather than on the user's computer or other device. In the present exemplary embodiment, the syntax for subject filters is the only syntax using wildcards, and the syntax for attribute filters is the only syntax using Boolean expressions. Alternatively, implementations may employ different or variable types of syntax for subject filters and attribute filters.

Agent 128 encodes the resulting DNF expression into a message (step 372), and transmits the message to the intelligent router (step 374). Encoding may involve converting the order into a flat message format, which means it constitutes a data string. This transfer may involve propagating the routing rules produced by the subscribed body filters and attribute filters to one or more intelligent routers or other routing entities in the network. For this propagation, ordering expressions can be mapped, for example, into traditional grouping structures.

The encoding of step 372 involves marshalling subscriptions for a channel into the messaging API's messaging format for propagation across the channel. Subscriptions are messaged internally, e.g., as notifications with body #.SUBSCRIPTION. Because both A variable number of subject filter fields in turn has a variable number of attribute tests, so in this example 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. The fields of the filter are marshaled sequentially (eg, in the order specified in the source order), and each is marshaled into a two-byte portion of the message. Wildcard fields may be marshaled as follows.

When marshalling property tests, the test operands are marshaled at the end of the message in a manner similar to the marshalling of property values for notifications. Before attribute tests and operand marshalling, they are sorted in attribute order within each disjunct of DNF, while pre-defined attributes are tested in positional order, followed by free attributes in name order. Furthermore, the set of correlation tests on scalar-valued properties within each disjunct is reduced to have one bound value (for left or right open range or equality tests) or two bound values (for The canonical form of the range filter for the closed range of ). The remaining information about the test is encoded, for example, as a two-byte pair in the same order as the operands; this two-byte pair sequence is set in the message immediately following the two-byte encoded sequence for the body filter field. A two-byte pair may constitute a form of bit-string encoding of a sequence of property tests, but it may also be used to represent other types of encoding. Examples of property tests are provided below.

The coding profiles for the attribute tests are described in Table 20. Table 21 illustrates the encoding of the two-byte pair, and Table 22 illustrates the encoding of the operator ID in the two-byte pair.

Since the two-byte pair of the test already indicates the type of the operand being tested and whether the test applies to a predefined or free attribute, there is no need for a separate marshalling of the number of tests performed on free attributes or their types. This scheme assumes no more than 127 predefined attributes in the notification. Alternatively, this design can take more bits to encode the attribute test.

While this grouping routine orders and groups attribute tests according to the DNF of the attribute filter, to make the overall evaluation of the entire attribute filter more efficient, infrastructure units (such as routers) may choose to be in some other order (perhaps according to dynamically obtained local data on the likelihood of success or failure of different tests) to evaluate tests. The Subscription ID field of the message is a value generated by the proxy to uniquely identify the subscription of the proxy's edge router in subsequent requests to modify or cancel the subscription. Specifically, dynamic modifications to a subscription's attribute filter are propagated using the message format shown in the example of Figure 18, except that the body is #.RESUBSCRIPTION, and the subscription ID is the ID of the previously registered subscription to be modified. Unsubscription is propagated, for example, across the Subscription ID field in the message format of Figure 18, where the body is #.UNSUBSCRIPTION and the Subscription ID is the ID of the previously registered subscription to be cancelled.

Examples are provided below to illustrate the conversion and encoding performed by the above agents. Consider the following exemplary attribute filter expressions: price >= 10 and (symbol == "LU" or (quantity >= 1000 and quantity <= 10000)). FIG. 19 shows a Unified Modeling Language (UML) diagram 390 describing the objects used by the agent in step 362 to store expressions. This diagram illustrates the hierarchical relationships used to specify ordering, which can include variables, constant values, or both. Objects in the graph can be instances of filter classes depending on the particular implementation. Each SimpleFilter object describes property values used to store information about the filter expression's corresponding property test. In 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 an ordered attribute. Similarly, OR filter 396 includes simple filter 398 and AND filter 400 includes simple filters 402 and 404 .

For this example, assume that the attributes Price, Sign, and Volume are predefined attributes of the associated channel, and assume they are defined in positions 0, 1, and 2, respectively. Also, the attribute types are assumed to be unsigned integer (type code 6), character array (type code 12), and unsigned integer (type code 6), respectively.

Consider the next order containing the above exemplary attribute filter expression as its attribute filter. Figure 18 shows the marshalling of subscriptions into messages. The diagram 386 on the left of Figure 18 shows the actual message content, while the diagram 388 on the right provides an illustration of the different parts of the message. In this example, each sketch is four bytes wide. Before marshalling, the filter has been converted to its equivalent DNF: (price >= 10 and symbol == "LU") or (price >= 10 and volume >= 1000 and volume <= 10000).

The attribute test code of sixteen bits is shown as a sequence of bits, with gaps shown separated into distinct sections. Note that the two tests for price in this example are not mergeable, since they are separate disjuncts, they are grouped separately into ranges with no right bound ("right open range"). On the other hand, since the two tests of the quantity are in the same disjunct, they can be combined, thereby grouping them together as a single "closed-scope" test.

Finally, note also that the characteristics of certain fields are "hypothetical"; this means that the values of these fields for this example were chosen arbitrarily, and are generally independent of the order being marshaled. Additionally, the ordered subject filter is arbitrarily chosen to be ">", which matches any subject defined by the associated channel. The examples described above and shown in Figures 18 and 19 are provided for illustration purposes only, and groupings can be used for any other type of order. Also, method 350 provides only one example of grouping orders, they can be grouped in any other way.

Figure 17 is a flowchart of a proxy method 376 for incoming messages. Method 376 may be implemented, for example, by agent 128 and application 126 in user machine 122 . In method 376, agent 128 receives the message from the intelligent router corresponding to the subscription (step 378). The agent 128 determines the channel corresponding to the subscription (step 380), eg, using the channel ID in the message, and calls the channel's API (step 382). The API provides data for the order on the user machine in a GUI or other format (step 384). The processing of incoming messages may employ the inverse of the encoding process described above, the process of decoding data, and this decoding (reverse encoding) may be performed in routers or other network entities.

Wildcard handling

FIG. 20 is a flowchart of the wildcard method 410 . This method illustrates an example of wildcards in expressions that take a set of routing rules against a filter to translate the order. Method 410 may be implemented in a software module, such as represented by agent 128, executed by processor 134 in user machine 122. Alternatively, wildcards may be processed in the network by processor 93 under software control in intelligent router 92 or a corresponding function contained in ASIC 91 . Wildcards include open fields or variable length fields, examples of which are provided in Table 21.

In method 410, a broker 128 or other entity receives a subscription with wildcards (step 412). The body length of the subscription may be specified by the publisher when the content is published, and the body may be pre-processed on the publisher machine to, for example, The fields are counted and thus obtain its field count (length). The agent 128 counts the number of fields in the filter operand (step 414) and initializes a new rule (filter) with field length=N (step 416). The agent 128 The ordered subfield is retrieved (step 418), and it is determined whether the filter operand subfield O[i] is a wildcard (step 420). If the filter operand subfield is not a wildcard, the agent 128 adds a conjunction clause to the rule , field[i]=O[i] (step 422). If the filter operand has more subfields (step 424), agent 128 returns to step 418 to process other subfields. The parameter "i" represents the field, where i is an integer representing the number of fields in this example.

After processing the subfields, the agent 128 determines whether the last filter operand subfield was ">" (step 426), and if so, it changes the length limit to field length > N-1 (step 428). Wildcard processing can take any type of symbol, ">" is just one such example. In this example, "a.>" may mean a.b, a.c, a.d, etc., and all their sub-subjects at all levels (eg, a.b.x, a.c.x, a.b.x.y, etc.). Other notations are also available for other implementations of wildcards.

Agent 128 propagates the transformed rules to intelligent routers or other entities in the network, if necessary (step 430). Therefore, the method rewrites the rules through the above subfields in order to process them, converting wildcards to no-wildcards, that is, rules that do not contain wildcards. Wildcard translations can occur anywhere in the network, such as on subscriber machines or in intelligent routers. Thus, this transformation can be done in one entity with rules that propagate the transformation to other entities, or it can be done dynamically.

Table 23 provides a summary and examples of these exemplary routing rules for handling wildcards. These routing rules can be generated in the intelligent router, for example, or generated in other network entities and propagated to the intelligent router. Additionally, the routing rules in Table 23 are provided for illustration purposes only, and other routing rules for converting wildcards may also be employed.

Alert service

The intelligent content-based routing described above can be used in many implementations, one of which involves Digital Video Surveillance Systems (DVSS). For example, a user (such as a law enforcement or security agency) may enter an order for video clips from a camera in a particular location. Cameras can capture digital video clips and transmit those clips over a network with content-based routing, such as the Internet, where the video clips are processed on a subscription basis in the core of the network. Thus, users receive video clips of interest and their filtering is distributed throughout the network. Besides video clips, any other type of content may be distributed to provide any type of warning, examples include security breaches, fire and fraud detection.

In another example, a particular camera may include an associated motion sensor. When motion is detected, the motion sensor simultaneously triggers the camera to transmit the captured video clip to the network, which uses content-based routing to route the video clip to the subscriber.

Therefore, the content-based routing described above can significantly reduce the burden on the network in processing and routing video clips. For example, video signals generated by each charge-coupled device (CCD) are required to be written to four different destinations by a digital video recorder (DVR), which are local storage managed by the DVR, global storage connected to the network, DVSS system and iDSS management server. Considering the necessary network bandwidth to carry such a huge amount of data, the total amount of CCDs or DVRs managed by iDSS may not meet the capacity requirements of customers. Therefore, bandwidth needs to be limited, for example, with techniques for media or large numbers of subscribers. Figure 21 shows an overall structure view of a surveillance system, where each DVR can manage four or sixteen CCDs.

Architecture overview: Figure 22 illustrates two improvements based primarily on the techniques described above to improve the capabilities of the surveillance system shown in Figure 21. As shown in Figure 22, the first improvement focuses on how to reduce DVR backbone traffic, while the second improvement uses a device called a z-box that provides content-based routing functions such as those described above to improve data transfer efficiency.

Reduced local traffic on the DVR backbone: Inefficiencies in the data distribution scheme can lead to serious scalability issues. That is, when image files generated by a DVR are delivered to other boxes using a TCP-based protocol, bandwidth consumption increases linearly with the number of devices connected to a local area network (LAN). In one view of iDSS, the same streaming video data needs to be sent to networked storage devices (SAN or NAS), iDSS monitors, and each DVSS, where DVSS is remote monitoring software.

One way to solve this problem is to publish only one data stream on the LAN for each DVR, and let other devices connected to the network receive the same data stream as a result of ordering. Thus, if the output rate of the DVR is 10 megabits per second (Mbps), then for example 3 subscribing devices on the same network should only require 10 Mbps of the network, not 30 Mbps.

For this purpose, the publish-subscribe, event notification API described above can be used on the DVR box and on any device that utilizes DVR data (eg iDSS, global storage). API can be simple but effective, it can adopt IP multicast and recovery agreement. The API can also follow the publish-subscribe model above, so that other implementations do not require code changes and can simply be relinked using libraries that provide full versions of the API.

Proxy server for DVSS: Each DVSS can open a connection (based on TCP) to the DVR box to receive streaming video data. Scalability presents the same issues as above.

Referring to Fig. 22, this method can be described as 2 stages, for example in the first stage 1, at the LAN side, a proxy server (such as z-box 1) can be provided to handle all DVSS output data (i.e. output from DVR to DVSS data). This proxy server orders all DVR data on the LAN, and publishes this data to an external network (such as the Internet). DVSS orders this data. Therefore, the proxy server z box 1 provides a subscriber proxy (such as proxy 128) and a publisher agent (such as agent 36), wherein the subscriber agent is used to collect data from the DVR, and the publisher agent is used to publish this data on the entire publish-subscribe network (such as the above-mentioned publish-subscribe network).

Even in phase 1, the traffic will be greatly reduced on the LAN side, but the traffic may still block the output link, especially in some countries, where a typical asymmetric digital subscriber line (ADSL) is only 64 kbit/s This is especially true at uplink speeds of uplinks per second (kbps).

With continued reference to Figure 22, Phase 2 preferably involves leasing or acquiring a connection in the service provider's computer room and setting up a second z-box device (eg, z-box 2) there. For example, z-box devices can be placed on the Hi-Net backbone. A single connection (tunnel) from this device to the z-box 2 can be established at the customer's premises.

In this case, the z-box 2 at the customer's premises acts as a subscriber agent (such as agent 128). Z-box 2 may also function as a routing daemon (eg, routing daemon 216). As a subscriber agent, z-box 2 (as in a Hi-Net computer room) preferably subscribes to content distributed by the DVR through z-box 1 . Between z-box 1 and z-box 2 is a publish-subscribe network as described above. Thus, z-box 1 distributes the video from the DVR, and z-box 2 orders the video required by the DVSS. In this manner, employing the event notification system described herein improves the data delivery efficiency of the alerting service. The z-boxes (such as z-box 1 and z-box 2) preferably include the modules described above for publishing and subscribing on this publish-subscribe network.

digital content delivery

The intelligent content-based routing described above can be used in many implementations, including routing video, music, and software updates through subscriptions. For example, users can order software updates, such as antivirus software, and have the updates automatically routed to them. In other examples, users can order specific video and music content and have the ordered content automatically routed to them as well. Video and music, for example, may be received as streaming digital content. In addition, distributed processing in the network core greatly reduces the processing burden on the servers that deliver software, video and music content. Therefore, using the same network infrastructure to deliver content effectively increases network bandwidth, among other benefits.

Figure 23 shows a specific structure for implementing this routing. It should be noted that this architecture assumes two levels of cache servers C1 and C2, preferably residing at the network service provider's co-located premises. However, these benefits are also obtained when only the C1 cache server is available. The terms C1 and C2 cache servers refer to servers that provide a distributed network cache as described above (see Figures 14-15 and associated description). The structure can be developed, for example, in two stages. The first stage assumes that the C2 cache server does not exist, and it uses a fast file transfer mechanism between the central distributor 450 and the C1 cache server to reduce server load and the time required to send large media files. A fast file transfer mechanism is preferably obtained by adding a routing box (470 in Figure 23) between the central distributor 450 and the C1 cache server. The second stage is to add a routing box on the C2 cache server, and adopt the above-mentioned subscription mechanism between the user (such as the user machine 460) and the C2 cache server.

Benefits of using a routing box : The routing box 470 preferably includes a module for implementing the above-mentioned content-based routing (such as the above-mentioned intelligent router 92). There are two main benefits of using routing box 470 to implement the content-based routing described above. The fast routing and file transfer solution using these routing boxes 470 can increase the speed of file transfer up to 5 times that of traditional file transfer protocols such as FTP or RCP. At the same time, high-efficiency multicast can also be realized on the wide area network (WAN). When data is sent from a central location to a set of receivers, this routing solution will speed up content delivery by leveraging network multicast topology and building multicast tunnels over the WAN to reduce server load and network bandwidth requirements.

Structure: The media content is delivered from the central distributor to the C1 cache server. The C1 cache server stores all content files. Each C1 cache server requires, for example, terra bytes of disk space to store all content. Users (such as using A user machine 460, such as subscriber machine 122, requests content from a C2 cache server, which stores only a portion of the content. The C2 cache server requires, for example, hundreds of gigabytes of disk space.

File transfer between user and C2 cache: When a user 460 requests a media file by placing an order, the request is handled by one of the C2 cache servers. If the requested media file is already cached in the C2 server, this file is delivered immediately. If not cached in the C2 server, an order is sent to the C1 cache server and the requested file is transferred from the C1 cache server to the C2 cache server.

Pre-cache media data from C1 cache to C2 cache: Based on user subscription or subscription model, media files can be pre-cached from C1 cache server to C2 cache server. For example, if a user 460 connected to the C2 cache server is very interested in popular songs, the C1 cache server can push new hit songs to the C2 cache server, even if any user 460 on the C2 cache server requests this Do the same before planting songs.

Implementation Phase: The first phase involves, for example, installing a fast file transfer mechanism with content routing between Distributor 450 and all C1 cache servers. No C2 cache server is required. In this case, all users 460 are directly connected to the C1 cache. The C1 cache server receives new media files from distributor 450 periodically. The structure of Phase 1 is shown in Figure 24.

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

Referring now to Figure 25, there is shown the structure of an embodiment implementing Phase 2. Phase 2 in this example preferably employs a kernel-implemented routing box 470 to route and send data. The kernel-level solution also reduces overhead when sending files because it requires fewer buffer copies and less context-switching time. Additionally, the Phase 2 solution adds a C2 cache server to the structure, as shown in Figure 25. Also, co-location is preferably employed in the service provider network to add a routing box 470 at the C2 site, as shown. This further reduces bandwidth requirements significantly, potentially by a factor of hundreds.

As shown in FIG. 25, files transferred between the C1 cache server and the C2 cache server are transferred via the routing box 470 associated with the C1 cache server and the routing box 470 associated with the C2 cache server. In this manner, employing these routing boxes 470 enables a fast routing and file transfer solution between the C1 and C2 cache servers.

Service Quality Management

The intelligent content-based routing described above can be used, for example, to route content with certain delivery guarantees. For example, based on a Service Level Agreement (SLA), an ISP or content provider may reserve bandwidth to guarantee Quality of Service (QoS). This can be efficiently done by content-based intelligent routing as described above.

Structure: There are at least two possible configurations for guaranteeing QoS in content delivery. The first configuration is to connect multiple links into one or more telephone company (TELCO) networks. The second configuration uses only one network link to the TELCO network. As the example shown in Figure 26, there are two layers of routing boxes (R boxes). R-Box 1 routes packets to R-Box 2 and R-Box 3 based on the content of the data packets. R-box 2 and R-box 3 route data packets into different network links (eg L1-L4), each link is connected to the TELCO network. To reserve bandwidth for premium users, data packets generated for the highest SLA customers are routed onto links with the highest bandwidth (highest priority) to guarantee specific QoS for those customers.

As an example shown in Figure 27, R-box 1 routes data packets to R-box 2 and R-box 3. R-box 2 and R-box 3 route data packets in turn into different communication links, which are then all connected to R box 4. R box 4 obtains data packets from four links based on the QoS level of each link. Then, R box 4 sends the data packets to the Internet ISP through the network link (such as L5). The system can dynamically allocate bandwidth for each link to obtain better QoS management than multi-link configuration.

Technology: QoS guarantees can affect the intelligent and distributed content-based routing technology described above. Mark each packet to be routed for content-based routing. The solution makes for an economically viable QoS deployment for ASP/content providers, and may have other benefits as well.

Benefits: This solution can be provided to Internet service providers (such as IDC) or content providers (such as media on demand (MOD) service providers) to reserve bandwidth for different customers based on the customer's SLA.

Real-time alerts: Alerts can have different priorities. For example, security and fire alerts can be given the highest priority, while new alerts can be given lower priority. Without QoS routing, the highest priority alerts may not reach their subscribers in a real-time manner because the ASP's network bandwidth may be occupied by alerts and traffic with lower priorities. This solution prevents this problem from happening. Also, alerts can be sent to each customer based on the customer's SLA. Premium customers can pay more and have more bandwidth allocated to them.

Real-time data delivery: For some applications, such as audio on demand (VOD), MOD, or voice over IP (VoIP), bandwidth availability affects the quality of these applications. Such a solution may route data packets based on the message type by inspecting the packet content as described above. For some bandwidth-sensitive applications, their data packets can be routed to links with higher priority. In addition to message type, data packets can also be routed to individual subscribers based on their SLA level. This solution can be employed to route packets for higher SLA clients to links with higher priority.

Software or antivirus software updates can also take advantage of this solution. For example, antivirus files can be routed to the highest priority link to ensure real-time antivirus updates, while audio driver files can be routed to lower priority links.

Content-Based Filtering: Using co-location services and placing the R-box inside the TELCO network, the system can perform filtering and dynamic caching outside the ISP, as shown in Figure 28. The R box inside the TELCO network can filter data based on the above-mentioned content filtering technology, so as to reduce the traffic entering the IDC/ISP network. This can be used to prevent hacking attacks such as DOS attacks or unauthorized data access. The R box can also be a cache box for static and dynamic web data, since the content of the request can be inspected. The advantages of this solution include eg security, saving network bandwidth between TELCO and ISP, and saving load on ISP servers.

Caching with Selective Multicast

Message persistence is the ability to store messages and retrieve them at a later time. Mass specific applications such as electronic mail often require extremely long message durations for messages flowing through the network. Ideally, always-connected subscribers should not require any more persistence than is required for these particular applications when the network is not down. In reality, however, messages may be "lost" as they travel through the network for various reasons, such as (1) a failure or buffer overflow either within the network or at the user's end or (2) the user explicitly disconnects The network connects and connects again after a while.

The event notification system persistence model described here is divided into two levels: short-term persistence and long-term persistence. Short-term persistence is dedicated to recovering lost packets due to network congestion or short-term link failures. Long-term persistence is dedicated to recovering from other failures, including, for example, user connection failures or ISP network failures, user computer failures, longer-term network failures, and/or other failures. Examples of these two schemes will be described below.

Short duration: data retransmission and flow control

In data networks, the causes of data loss can be simply divided into link failure and buffer overflow. These issues need to be addressed in order to provide a reliable channel for event notification systems. For link failures, a forward error correction (FEC) scheme can be implemented to correct some errors caused by the link failure. However, there is still a need to provide a scheme for recovering packets when the error is so severe that no FEC scheme can correct it. As far as buffer overflow is concerned, it is necessary to prevent buffer flow from occurring. Flow control schemes are often used in data networks to prevent this kind of problem.

In a short-term persistence scheme, Transmission Control Protocol (TCP) tunnels are preferably used to connect event routers (eg, intelligent router 12) hop-by-hop. There are many reasons for relying on reliable layer 2 tunnels instead of using reliable transport protocols such as RMTP. In a short-term persistence scheme in an event notification system, a message is preferably filtered out by a router if it does not satisfy the filtering rules. Therefore, receiving routers generally cannot detect packet loss by employing a source sequence number-like scheme. Also, it is not desirable for all receiving routers to acknowledge every packet they receive, as this would lead to an excess of acknowledgments (ie, ACK augmentation). Furthermore, to avoid buffer overflows, a flow control scheme is implemented for the short-term persistence model, so that a router can request neighboring routers forwarding messages to it to slow down before the router runs out of buffer space. These schemes are included in TCP.

TCP transmission strategy: In TCP for short-term persistent schemes, the transmission window is preferably used locally at the data sender to assist in tracking data that has been retransmitted. The purpose of employing the transmission window is twofold: firstly, the transmission window ensures that the sender will definitely know that the data has been correctly received by the receiver; secondly, the transmission window allows better utilization of the channel capacity. In TCP, every byte sent by the sender needs to be acknowledged either implicitly or explicitly. Transmission windows help senders keep track of data that has been sent and acknowledged. Transmission windows also improve channel utilization because the sender can send data within the transmission window without having to stall and wait for the previous packet to be acknowledged. Once the previous data is confirmed, the window will automatically advance.

Receiver windows are also maintained in TCP. The receiver window is preferably used to indicate the available buffer space at the receiver side of the data. Its available buffer space value is sent to the sender so that the sender knows how to avoid overflowing the buffer on the receiver side.

TCP Congestion Control: Since TCP is designed as an end-to-end transport protocol, the TCP used in the short-term persistence scheme also solves the buffer overflow inside the publish-subscribe network. To solve this problem, TCP for the short-term persistence model preferably employs a third window: the congestion window. The congestion window is used to make the sender guess the maximum buffer space at the routers along the path. In short, the congestion window size is decreased if the sender detects a loss in packets, or increased vice versa.

Long Persistence: Caching of Persistent Channels

Channels (as described above) can be persistent or real-time. Real-time channels carry data that is generally only useful in real time and does not have any application-specific persistent requirements. A persistent channel stores data that passes through the network for a persistent time frame T. In other words, the persistence of the persistent channel is guaranteed during the time frame T. This persistence of data is achieved by steps such as: caching data at each edge node for the duration of the channel; retrieving data from the cache transparent to the user under failure conditions; Retrieve data from buffers; enable continuous data flow across the network by protecting against router failures and establishing reliable tunnels between routers; and protect against channel component failures during replication.

Therefore, as described below, when a subscriber fails and returns again within the time frame T of the persistent channel, the long-term persistent scheme preferably enables a subscriber registered with a persistent channel to retrieve the last "X" time frame (X <T) earlier data.

In a long-term persistence scenario, a subscriber application (such as application 126) preferably can explicitly pull data (such as a message) from an associated subscriber proxy (such as proxy 128). As described above, the proxy can utilize a proxy server or implement it . After the proxy or proxy server has recovered from a network failure, the proxy preferably retrieves data from the cache transparently for a period of time when it was disconnected from the edge router. Also, in a long-term persistence scheme it is preferred to allow the subscriber to only Data up to the last T time frame is accessible. For this purpose, the time is preferably determined for the edge router connected to the proxy (or proxy server). Retrieved cached data is preferably delivered out-of-band with no real-time guarantees. Long-term persistence schemes Embodiments are primarily targeted at existing subscribers that have failed and re-validated or lost connection to an edge router (such as edge router 16). New subscribers may not be able to get cached information.

Persistence Definition: A subscriber's timed persistence (in terms of time frame T) is defined as the ability to retrieve data for the last time frame T from the publish-subscribe network. If the subscriber leaves the network, any data received on the persistent channel during the subscriber's absence will remain in the network for a period of time frame T (from the time the data was received). If that subscriber returns within time frame T, the subscriber will not lose any data. However, if the subscriber returns between the T and 2T timeframes, the subscriber may lose data. If the subscriber returns after time frame 2T, the subscriber is preferably not guaranteed to have access to any previous data.

The above definition requires that a publish-subscribe network tree that emits leaves at a subscriber should persist for a time frame T after the subscriber disappears, and can be subsequently pruned to preserve new data received within time frame T after the subscriber leaves to time frame T reaches its expiration time.

Architecture: Figure 29 is a block diagram illustrating some components of a publish-subscribe network that provides persistence in cache. As shown, the network includes core routing nodes 548 and edge routing nodes 545 . Each routing node preferably includes an intelligent router 92 (shown as an edge routing node) and a traditional 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 shown in FIG. 29 . The cache manager 218 is described above with reference to FIG. 8 . Intelligent router 92 is preferably responsible for short-term persistence in order to retrieve data that has been lost or to recover from router failure. Cache manager 218 is responsible for caching data to provide long-term persistence of the channel. Cache manager 218 preferably caches this data in cache 540 . Cache 540 preferably includes memory and disk (not shown).

There are several advantages to having a cache manager 218, as opposed to an intelligent router 92 responsible for caching long-term persistent data, including: Computationally intensive operations indexing cached data can be performed on a separate processor, thus The performance of the routing and filtering processors is not affected, and disk I/O operations that periodically move cached data to disk can also be performed on another processor, thus preventing cycle stealing from routing and filtering, Avoid edge routers having to do periodic I/O.

Also shown in FIG. 29 is agent 128, which preferably resides in subscriber machine 122 (not shown in FIG. 29), as shown in FIG. Agent 128 is responsible for communicating with cache manager 218 to retrieve data from cache 540, to receive the retrieved data, and to organize the retrieved data. As noted above, proxy 128 may utilize or be implemented with a proxy server.

In the absence of failures, only the edge router nodes 545 need the cache manager 218 associated with them. However, although not shown in FIG. Each of the routing nodes 548 preferably includes a cache manager 218 for storing data. Upstream is the direction of travel away from the proxy 128 (i.e., away from the subscriber machine 122). The first level of upstream core routing nodes refers to directly at the edge routing nodes 545 Upstream routing nodes. Although publish-subscribe networks typically include multiple first-level upstream core routing nodes, Figure 29 depicts only one first-level upstream core routing node, core routing node 548. As noted above, the cache manager 218 provides a local cache of data on the network node where it resides. Thus, the operation of cache manager 218 at each core routing node (including, for example, core routing node 548) provides local cache of data throughout the network core. Distributed cache. This distributed cache provides backup for the cache at edge routing nodes 545.

FIG. 30 is a diagram illustrating backup caches in upstream routers (eg, core routing node 548). In a long-term persistence scheme, each cache is preferably backed up with the cache of the next upstream router. The upstream cache stores all incoming data and serves as a backup for all next-level downstream edge router caches. Data in the upstream cache is preferably stored using the same mechanism as the edge router cache.

Referring now to Figure 31, the cache structure for persistent channels preferably provides functionality across four distinct modules: Cache Manager 218 - preferably server processing responsible for storing data passing through Intelligent Router 92; Router Cache API 552 - preferably Library responsible for all control plane access to Cache Manager 218 from Intelligent Router 92, such as creating and destroying caches; Proxy (or Proxy Server) Cache API 554 - preferably responsible for accessing Repositories accessed by all control planes of cache manager 218, such as retrieving data; and proxy 128 (or proxy server) - preferably responsible for gathering retrieved data from cache 546 and organizing such data.

Figure 31 illustrates the interaction of these four modules. Both proxy 128 and intelligent router 92 preferably access the cache through cache API libraries 552 and 554 . Cache API libraries 552 and 554 provide APIs for initializing in cache 546 , creating and destroying caches for subjects, retrieving cache addresses, and most importantly retrieving data from cache 546 . Routing daemon 216 preferably sends data to cache manager 218 via a datapath rather than via cache API 552 . Cache APIs 552 and 554 preferably use the control path for all control messages, including data retrieval.

Cache Manager - Cache Management: Referring now to Figure 32, when the cache manager 218 encounters a new channel, the cache manager 218 preferably activates an information server (such as the servers 152, 154 and/or 156 described above) to get the channel manager 150 for the channel. Once the cache manager 218 has the address of the channel manager 150 , the cache manager 218 preferably retrieves the channel characteristics of the channel manager 150 . Channel characteristics preferably include, for example: channel subject tree and attributes, channel persistence characteristics, channel duration time frame (T), cache granularity. Before cache manager 218 can begin caching data flowing over a channel for a given subject, a cache for that subject needs to be created in cache manager 218 . Cache manager 218 expects a create cache message and creates a subject cache in response to the message. This principal cache can then be destroyed, suspended or resumed upon request. Figure 32 illustrates the creation of caches on subscriptions.

Cache Manager - Cache Data Input: Cache Manager 218 preferably accesses data entering Intelligent Router 92 in a variety of ways, e.g. an IP-like solution, in which case Intelligent Router 92 input link The data is also forwarded into the cache manager 218; a sniffing mechanism is employed (in which the cache manager 218 listens to all packets traveling on the network of the intelligent router 92); after filtering, the intelligent router 92 forwards the required Every message traveling over one or more links goes to cache 546; and, cache manager 218 acts as a subscriber for all data entering intelligent router 92.

Cache Manager - Cache Data Storage: Referring now to Figure 33, Cache Manager 218 preferably indexes data in Cache 546 in a variety of ways, such as by Channel ID, Subject, Publisher ID, Timestamp, Time Granularity (G), primary cache attributes, links (in the specific case when caching for failures) or other means. Data can be indexed and stored in a file system or memory in a hierarchical directory structure. Data is preferably high-speed The cache is in memory and is periodically moved to disk. The cache in memory lasts only for the duration of "G" time granularity. After time G expires, all data related to a particular branch in the tree is preferably moved to In the file under that branch, thus covering the earliest file of that branch. (Note that it is better not to implement G as a sliding window, but as an absolute window, because it is expensive to write each message to the disk separately. , while it is more efficient to write all G intervals to disk in one operation). Figure 33 is a diagram of an exemplary index tree. When caching data for persistence, it is preferable to use the first index tree in Figure 33.

Continuing to refer to FIG. 33, the subject is preferably stored hierarchically, and "a" is the parent of the subject (such as "a.b", "a.c", "a.d", etc.). Cache manager 218 preferably maintains a hash table for cache 546 that maps all principals to their corresponding file locations. In some cases, when an upstream router (eg, core routing node 548) detects a failure of a downstream router (eg, edge routing node 545) on its link, cache 546 may need to store data for the failure condition. The first method for recovery is to reboot the downstream router (this may take a few minutes). When the downstream router restarts, the upstream router will need to cache the data being forwarded down that link. This cache (referred to as the FM cache in FIG. 33) is preferably indexed on the output link.

Cache Manager - Garbage Collection: If the channel is not persistent, the cache 546 does not store the data, but pulls it down immediately. If the channel is persistent, cache 546 stores the data. Divide the duration frame "T" of a particular channel into N time granularities, each of size G. The cache in memory only lasts for the duration of G. After the cache manager determines that a time interval G has elapsed, the data is moved to disk. The cache manager 218 will store the data on disk for the duration of the duration frame interval T.

Once the time is greater than the channel's duration timeout (T) + the upper limit of the interval, the data corresponding to the time interval G is deleted from the disk. To better understand this, assume that T of the channel is 2 hours. As an example, cache manager 218 employs a time granularity G of 15 minutes. To remove data from disk, the preferred policy is that when the last data cached during time interval G (15 minutes) has been stored for T (2 hours), the entire cached data during 15 minute intervals will be deleted throw away. Therefore, data cached at the beginning of the 15 minute interval will have been stored for more than 2 hours before being deleted. In this example, the data cached during each 15 minute interval is a data block. If the duration frame T is divided into N intervals, there will be N+1 data blocks in cache 546 for each subject at any point in time (N on disk and 1 in memory).

Cache Manager - Cache Data Retrieval: Referring now to Figure 34, the proxy 128 (or proxy server) preferably activates the GetCache operation to obtain data from the current time back to time "T". In FIG. 34, the Cache Manager 218 to which the Proxy 128 connects to activate the GetCache operation is indicated as the Entry Cache. Due to a router or proxy 128 failure/disconnection, the entry cache may not have all the data requested by the proxy 128 . In this case, the job of the entry cache is to retrieve data from all other caches (eg, upstream caches), compare the data and return it to the proxy 128 . Figure 34 illustrates a retrieval operation from multiple caches (A, B, and C) at different timestamps (TS1, TS2, and TS3).

The cache manager 218 preferably can only retrieve data in blocks of temporal granularity G. So agent 128 may get more data than it expects or requests. Furthermore, during retrieval from multiple caches, there may be some overlapping intervals between the caches, so the agent 128 will also find that there are duplicates of the data, and the agent 128 should replicate the data stream provided by the caches. This inhibition.

Cache Manager Interaction with Other Modules: In the event notification system infrastructure, the cache manager 218 preferably interacts with several modules, as shown in Figure 35. When the cache manager 218 encounters a new channel (in When the cache is created), it preferably activates the information server 550 to get the channel manager 150 for that channel. Once the cache manager 218 has the address of the channel manager 150, it preferably gets the channel characteristics from the channel manager 150. Preferably Allows the administrator module 552 to set/modify some properties, such as cache granularity. Also preferably allows the administrator module 552 to manually create or delete channel caches.

Proxy Cache API-Application-Proxy Interaction: An application (such as application 126) preferably activates the proxy cache API 554 to get the cache 546 with a given principal and filter. Preferably, an application can only retrieve data from cache 546 if it has subscribed to that data. Proxy cache API 554 preferably actually provides two APIs.

The first API allows unsubscribing applications to subscribe and retrieve cache 546 at the same time. If the "fifo" flag is set, a subscription is created and sent to the edge router node 545. However, it is preferred to immediately place the subscription in "pause" mode. After the proxy 128 has received all of the cached data, the proxy 128 first commits all of the cached data, tracking the last sequences that were not seen in the data by the publishers and were subsequently never seen by each publisher The last sequence to start delivering the data that was paused.

For the second API, assume that the application has ordered some data and requested cached data. In this case, some data has been delivered to the application that may not be in order as far as cache data is concerned. Thus, the "fifo" flag in this case simply indicates that the data retrieved from cache 546 should be in order within itself, and not necessarily in regular data flow.

Agent 128 preferably retrieves all events in one chunk of data. After retrieving the data from the cache API 554, the proxy 128 preferably needs to perform the following operations on the data (see above) before activating the callback operation: construct notifications from the notification list; track the last sequence number of each publisher; and filter. When the proxy 128 pushes all events to the callback, it preferably sends a DoneCache event to the callback to indicate that all cached data has been delivered. In this regard, if the subscription is FIFO and the rule's data is pending, the agent 128 preferably forwards all pending notifications. The proxy 128 only delivers those notifications whose sequence number is greater than the last sequence number in the cached data.

Proxy Cache API Interoperates with Cache: When a subscriber requests cached data, the Cache API on side 554 of Proxy 128 preferably first queries the history of the edge routers connected to Proxy 128 and uses GetCache The time interval provided in the request to filter the list. API 554 then sends a GetCache(channel, body, filter, local_pubs, time_period, fifo, router_array) message to the last edge cache it is connected to. The cache manager 218 preferably pushes the data based on the channel id, subject and timestamp, and pushes the data to the proxy 128 . When the cache manager 218 has finished pushing out data, it sends a DoneCache event to the cache API to indicate that the data transfer is complete.

If the cache manager 218 does not find the data locally, it uses the "router list" provided by the proxy 128 to locate the required data. Once the cache manager 218 has gathered all the necessary data, the cache manager 218 compares the necessary data and replicates it before forwarding it to the proxy 128 .

Cache Connection History: In order to be able to retrieve data from cache 546, a cache connection history is preferably maintained at proxy 128 for edge as well as upstream caches. Since such information needs to be closed and destroyed across agents 128, the information should be continuously maintained in files. The on-disk cache connection history is preferably stored in the following files and formats:

Edge Cache Location: The location of the edge cache (e.g. cache 546 on edge routing node 546) is preferably obtained from the channel manager/channel library. This is at boot time and when the edge cache changes (e.g. lost /resume connection, connection move) occurs at any subsequent time. The distributor notifies the agent 128 of any changes in the edge cache connection, and these changes are then passed to the agent 128 cache repository. Whenever a change occurs, the make the change persistent.

Persistent Storage: CACHE_ROOT/channel_id/channel - Exemplary path of cached data.

Data is preferably stored in the following format:

number of edge caches;

edgecache1:interval number, starttime1:endtime1, starttime2:endtime2, ...; and

Edge cache 2: number of time intervals, start time 1: end time 1, start time 2: end time 2, ...

...with the most recent timestamp as first in the list. Note that these two different edge caches will never have overlapping intervals (since the proxy 128 is only connected to one edge cache at a time). Whenever new items are added, old items are checked to see if they are still valid; if they are invalid, they are discarded. if

If the interval end time + the continuous timeout of the channel < the current time, the time interval becomes invalid. An edge cache entry becomes invalid if all intervals in the entry are invalid. Note that an "end time" of 0 means that the interval is currently valid.

Upstream Cache Location: The location of an upstream cache (such as cache 546 on core routing node 548) is subject-dependent. Each principal has its own multicast tree, so the set of first-level upstream caches is a function of the principal. Whenever a user wants to order a subject, intelligent router 92 preferably returns a list of upstream caches associated with the subject. Likewise, any changes in upstream cache locations due to failures or reorganizations in the multicast tree are also preferably communicated to the proxy 128 via the control channel. These changes are archived locally in persistent storage (files).

Persistent Storage: CACHE_ROOT/Channel_Identifier/Body (not by hierarchy, but by whole body). - Exemplary paths for cached data.

Data is preferably stored in the following format:

Number of upstream caches;

upstream cache1: number of intervals, start_time1: end_time1, start_time2: end_time2, ...;

Upstream cache 2: interval number, start time 1: end time 1, start time 2: end time 2, ...

...also with the latest timestamp as the first in the list. Unlike the edge cache spacing, two upstream caches may have overlapping spacing, because for a given principal, proxy 128 may have several upstream caches. The content of the upstream cache file is also garbage collected using the same algorithm as the edge cache.

Cache Availability During Data Retrieval: During the lifetime of the proxy 128, it connects to different edge routers and upstream routers. The proxy cache API 554 preferably stores this connection history in local memory. When the proxy 128 needs to retrieve data from the cache 546 for the last T interval, the proxy cache API 554 preferably looks at the connection history to determine the cache from which the data can be accessed. The algorithm preferred for this purpose is as follows: 1) The cache library probes all edge cache intervals and checks for intervals that fall within the T time frame. If the interval falls within this time frame, it is added to the list _Le of valid edge caches; 2) the list _Le is sorted using the interval start time; 3 ₎ For each interval covered, detect the upstream cache to get all the upstream cache intervals that can cover this interval, and add the valid interval to the list L _u ; append L _u to Le, and use the interval start time to L _e classifies, thus creating L.

This algorithm gives a list of caches L and for each cache the time interval to retrieve data. This cache L list is then 4) assembled into a get cache message and sent to the cache manager 218 . At the end of the cache manager 218, the cache manager 218 preferably 5) ungroups the cache intervals from the obtained cache messages and recreates the list L sorted in increasing order of start time. For each interval in the list L: The cache manager 218 preferably 6) checks whether there is a gap between the previous interval and the current interval, and if so, requests the data from the local cache. If there is no gap, the cache manager 218 preferably 7) talks to the associated cache to get the data. The cache manager 218 preferably 8) compares the data from all caches and sends it to the proxy 128 .

Router Cache API: Router Cache API 552 on Intelligent Router 92 is responsible for activating Cache Manager 218 to create, destroy, suspend and restore caches for specific principals. Router Cache API 552 also handles initial configuration - uploading of cache addresses from Intelligent Router 92 into Channel Manager 150 so that this information is available to Proxy 128 side (Proxy Cache API 554) when needed, and retrieved for other routers The location of the cache 546 (this is used when the intelligent router 92 wants to inform the proxy 128 about the upstream cache for a given principal, such as when ordering replies and after the principal tree has changed).

Use of caches for pull: The above discussion has focused on employing caches to implement persistent channels and allow returning subscribers to pull data from the network. Alternative embodiments allow any subscriber (new or returning) to pull any kind of data from cache 546 (such as including a subscriber who may not have subscribed yet but is in cache 546 due to someone else's subscription) The data). The difference between this embodiment and the previous one is that for returning subscribers the data is guaranteed so far and the location of the data is known, whereas for new subscribers the location of the stored data is Unknown. A simple way to implement this alternative embodiment is to issue a "FindCache" request on the channel. The "FindCache" request contains the channel id, body, filter, time interval, and the location of the proxy 128 that looks for the cache 546 with the requested cached data. All caches 546 listen for "find cache" requests. When each cache 546 receives the request, the cache 546 checks to see if the corresponding data is in its data store and, if so, sends back its own location in a unicast message. The agent 128 selects a cache 546 and activates the GetCache operation on it to get the data.

Latest Data Pull: Other embodiments include a latest data pull feature that allows a subscriber application (such as application 126) to obtain the latest news for a given subject. This is useful for data such as stock quote alerts, for example when the user only wants to know the most recent stock price and not its history.

Cache Manager Implementation: There are preferably three thread types, for example, in a Cache Manager 218 implementation: Data Cache Thread - The Data Cache Thread preferably fetches data from the connection to the Intelligent Router 92 and indexes it in memory and store the data; data storage thread - once the end of the time interval is reached, the data storage thread preferably moves the data stored in memory to disk and also performs garbage collection on expired data in the process; data retrieval thread - The data retrieval thread is preferably responsible for obtaining requests for cached data and retrieving data from the cache memory 546. These three types of threads can be implemented as a single thread or a thread pool. Preferably, the data cache thread and the data store thread are in Synchronize when data is moved to disk. This synchronization between the data store thread and the data retrieval thread prevents data from being deleted while it is being retrieved.

Data Structures: An example of a data structure for caching is provided above in Table 19 and the accompanying description.

Data Storage: Figure 36 is a diagram illustrating a preferred directory structure for storing data files in the cache 546 named "Aquila Cache". Note that each principal-level directory preferably has a set of child principal directories and a data directory that stores data published on that principal. For example, the data released on Fox.Movies on the entertainment channel will enter the files in the directory AquilaCache/entertainment/Fox/movies/data, and the data published on the main Fox will enter the directory AquilaCache/entertainment/Fox/data in the file. To increase the speed of the data storage device, a subject-specific directory hierarchy is preferably created when intelligent router 92 requests cache 546 to begin caching for a given channel and subject.

Data Retrieval: Retrieving data from cache 546 should be efficient so as not to block data storage and stall cache 546 . Data retrieval retrieves data from disk and memory. The steps taken for data retrieval are preferably as follows: 1) locate the data node; 2) lock the data node; 3) locate the timestamp of the data to be retrieved; 3) retrieve the data and store it in memory; 4) unlock the data node ; 5) Filter and sequence the retrieved data stored in memory before pushing it out to the broker 128 client.

While the invention has been described in conjunction with exemplary embodiments, it will be understood that numerous modifications may readily be made by those skilled in the art and that this application is intended to cover any adaptations or variations thereof. For example, various types of publisher machines, user or subscriber machines, channels and their configurations, as well as hardware and software implementations based on content routing and other functions, may be employed without departing from the scope of the present invention. The invention should be limited only by the claims and the equivalents thereof.

Claims (110)

1. one kind is used in the network routing packets said method comprising the steps of in order to the method for alerting service to be provided:

Reception has the grouping of stem part and payload portions, and described payload portions comprises the information that relates to from the video clipping of particular camera;

The described payload portions of checking described grouping in network core is in order to determine whether and how the subscriber is given in the described grouping of route information from described particular camera; With

Based on the optionally described grouping of route of described inspection.

2. the method for claim 1 is characterized in that, described inspection step comprises whether the information of determining in the described payload portions concludes that to the described content in the structure of map network destination information is complementary with content being concluded associating information.

3. the method for claim 1 is characterized in that, carries out on the router of described inspection step in described network core.

4. the method for claim 1 is characterized in that, described inspection step comprises the information in the described payload portions is applied filtrator.

5. method as claimed in claim 4 also comprises with the router of described filter propagation in the described network, in order to carry out described inspection.

6. the method for claim 1 also comprises the router in the described network is programmed, in order to carry out described reception, inspection and route step.

7. the method for claim 1 is characterized in that, described inspection step comprises the inspection attribute, in order to determine the how described grouping of route.

8. the method for claim 1 is characterized in that, described optionally route step comprises optionally described grouping is routed to the digital video surveillance system.

9. the method for claim 1 is characterized in that, described inspection step is carried out in LAN (Local Area Network).

10. the method for claim 1 is characterized in that, described inspection step is carried out in the ISP position.

11. the method for claim 1 is characterized in that, described particular camera comprises digital video recorder and charge-coupled device (CCD).

12. method as claimed in claim 11 also comprises the digital video recorder that generates the described grouping with described stem part and described payload portions.

13. a method that is used for providing at the network route messages alerting service said method comprising the steps of:

Reception has the message of stem part, at least one main body and at least one attribute, and described attribute relates to the video clipping from particular camera;

From described main body of described message retrieval and described attribute;

Order based on described main body retrieval; And

For determine whether and how the described message of route give the subscriber information from described particular camera, in network core, described attribute is applied to described order.

14. method as claimed in claim 13 is characterized in that, the step of the described order of described retrieval comprises the filtrator of retrieval corresponding to described order.

15. method as claimed in claim 13 also comprises the described message of route if described attribute satisfies described order.

16. method as claimed in claim 13 does not also comprise if described attribute does not satisfy described order abandoning described message.

17. method as claimed in claim 13 is further comprising the steps of:

Retrieval is corresponding to a plurality of filtrators of a plurality of orders;

The a plurality of attributes of retrieval from described message;

Each described attribute is applied on each described filtrator, whether is met to determine any described corresponding order; And

Whether be met the optionally described message of route based on any described order.

18. method as claimed in claim 13 also is included in and carries out described applying step on the router in the described network core.

19. method as claimed in claim 13 is characterized in that, described particular camera comprises digital video recorder and charge-coupled device (CCD).

20. method as claimed in claim 19, also comprise described digital video recorder, generation has the described message of described stem part, described at least one main body and described at least one attribute, and described attribute relates to the video clipping from described particular camera.

21. one kind is used in the network routing packets said method comprising the steps of in order to the method for alerting service to be provided:

Reception has the grouping of stem part and payload portions, and described payload portions comprises the relevant information of incident with the specific warnings service;

In network core, check the described payload portions of described grouping, in order to the information that determines whether and how the described alerting service of subscriber is given in the described grouping of route; And

Based on the optionally described grouping of route of described inspection.

22. one kind is used in the network routing packets in order to the device of alerting service to be provided, described device comprises:

Receiver module is used to receive the grouping with stem part and payload portions, and described payload portions comprises the information that relates to from the video clipping of particular camera;

Check module, be used for checking the described payload portions of described grouping, in order to determine whether and how the subscriber is given in the described grouping of route information from described particular camera in network core; And

Routing module is used for based on the optionally described grouping of route of described inspection.

23. device as claimed in claim 22, it is characterized in that, described inspection module comprises whether the information that is used for determining described payload portions mates the module that content in a kind of structure is concluded information, and wherein said structure concludes that with described content information is with the map network destination or instruct the rule of correspondence of handling in the router to be associated.

24. device as claimed in claim 22 also comprises the module that is used for carrying out described inspection step on the router of described network core.

25. device as claimed in claim 22 is characterized in that, described inspection module comprises and being used for the module of filter application on the information of described payload portions.

26. device as claimed in claim 25 also comprises being used for described filter propagation to the router of described network in order to carry out the module of described inspection.

27. device as claimed in claim 22 also comprises being used for the router of described network is programmed so that carry out the module of described reception, inspection and processing.

28. device as claimed in claim 22 is characterized in that, described inspection module comprises and is used to check that attribute is in order to determine the module of the how described grouping of route.

29. device as claimed in claim 22 is characterized in that, described device is located in the network that comprises digital video recorder.

30. device as claimed in claim 22 is characterized in that, described particular camera comprises digital video recorder and charge-coupled device (CCD).

31. a device that is used for providing at the network route messages alerting service, described device comprises:

Receiver module, it is used to receive the message with stem part, at least one main body and at least one attribute, and described attribute relates to the video clipping from particular camera;

Be used for from the module of described main body of described message retrieval and described attribute;

Module based on described main body retrieval order;

Application module, be used for for determine whether and how the described message of route give the subscriber information from described particular camera, in network core, described attribute is applied to described order.

32. device as claimed in claim 31 is characterized in that, the described module that is used to retrieve described order comprises the module that is used to retrieve corresponding to the filtrator of described order.

33. device as claimed in claim 31 also comprises being used for satisfying under the situation of described order and based on service quality at described attribute guaranteeing the optionally module of the described message of route.

34. device as claimed in claim 31 also is included in described attribute and does not satisfy the module that is used to abandon described message under the situation of all orders.

35. device as claimed in claim 31 also comprises:

Be used to retrieve module corresponding to a plurality of filtrators of a plurality of orders;

Be used for from the module of a plurality of attributes of described message retrieval;

Be used for each described attribute is applied on each described filtrator to determine any described corresponding module that whether is met of ordering; And

Whether be met the optionally module of the described message of route based on any described order.

36. device as claimed in claim 31 also comprises the one or more modules that are used for carrying out described application on the router of described network core.

37. device as claimed in claim 31 is characterized in that, described device is located in the network that comprises digital video recorder.

38. device as claimed in claim 31 is characterized in that, described particular camera comprises digital video recorder and charge-coupled device (CCD).

39. one kind in network routing packets comprise in order to the system of alerting service to be provided:

A plurality of digital video camcorders, wherein said digital video camcorder produce digital video output;

Local Area Network, it connects described digital video camcorder;

The publisher agency, it is connected on the described LAN, issues described digital video output;

Issue-the subscribe that comprises a plurality of intelligent routers, it is connected to described publisher agency; And,

Digital video surveillance system (DVSS), it is exported via the digital video that described issue-subscribe receives described issue, it is characterized in that described intelligent router comprises:

Receiver module is used to receive the grouping with stem part and payload portions, and described payload portions comprises the information that relates to from the video content of one of described a plurality of particular camera;

Check module, be used for checking the described payload portions of described grouping, in order to determine whether and how the subscriber is given in the described grouping of route information from described digital video camcorder in network core; And

Routing module is used for based on the optionally described grouping of route of described inspection.

40. system as claimed in claim 39 also comprises the subscriber agency who is connected to described issue-subscribe, it is ordered described digital video output and pushes the digital video output of described order to described DVSS.

41. one kind is used for the network of digital content distribution to the subscriber, described network comprises:

A plurality of subscriber computers;

The central distribution device of regular distributed digital loop content;

A plurality of cache servers, the digital content of its reception and the described distribution of high-speed cache, wherein said cache server is asked from the user of subscriber computer reception about the digital content of certain described high-speed cache termly, and the digital content of described request is transmitted to described subscriber computer; And,

The route box, it receives described distributed digital loop content as file and adopt the issue-order of content-based route that described digital content file is sent to described a plurality of cache server from described central distribution device, wherein, described digital content file is that publication and described user request are to order, and described route box comprises:

Receiver module is used to receive the grouping with stem part and payload portions, and described payload portions comprises the information that relates to digital content file;

Check module, be used to check the described payload portions of described grouping, in order to determine whether and the how described grouping of route; And

Routing module is used for based on the optionally described grouping of route of described inspection.

42. network as claimed in claim 41, it is characterized in that, described route box is that the first via is by box, described network also comprises the secondary route box with described a plurality of cache server co, the wherein said first via by box with described digital content file be routed to described a plurality of cache servers in the described secondary route box of at least one co.

43. network as claimed in claim 41 is characterized in that, described a plurality of cache servers are located at the Internet Service Provider place.

44. network as claimed in claim 41 is characterized in that, described a plurality of cache servers are first order cache servers, the whole described digital content that its storage is distributed by described central distribution device.

45. network as claimed in claim 44 also comprises second level cache server, the described digital content of a part that its storage is distributed by described central distribution device.

46. network as claimed in claim 45, it is characterized in that, described route box is that the first via is by box, described network also comprises the secondary route box with described second level cache server co, wherein, the described first via adopts the issue-order of content-based route that digital content file is sent to described second level cache server from described first order cache server by box and described secondary route box.

47. network as claimed in claim 46 is characterized in that, described routing module optionally is routed to described second level cache server with described grouping from described first order cache server based on described inspection.

48. network as claimed in claim 45 is characterized in that, is based on by the described digital content of a described part of described second level cache server storage that the history of user's request of reception determines.

49. network as claimed in claim 45, it is characterized in that, described second level cache server directly receives described user request, and will be transmitted to described first order cache server about can't help user's request of digital content of described second level cache server storage.

50. network as claimed in claim 41 is characterized in that, and is described

Routing module optionally is routed to described a plurality of cache server with described grouping from described central distribution device based on described inspection.

51. network as claimed in claim 41 is characterized in that, described central distribution device comprises one or more servers.

52. network as claimed in claim 41 is characterized in that, described digital content comprises video, music and software.

53. one kind is used at network digital content distribution being arrived subscriber's method, said method comprising the steps of:

Distribution is from the digital content of central distribution device;

The described distributed digital loop content of content-based route is to a plurality of cache servers;

The digital content of the described content-based route of high-speed cache on described a plurality of cache servers;

Reception is ordered about the user of the digital content of the high-speed cache of being asked; And,

User's order based on described reception is sent to the user with the digital content of being asked from described a plurality of cache servers, it is characterized in that the step of described content-based route may further comprise the steps:

Reception has the grouping of stem part and payload portions, and described payload portions comprises the information that relates to digital content file;

The described payload portions of checking described grouping is in order to determine whether and the how described grouping of route; And

Optionally described grouping is routed to described a plurality of cache server based on described inspection.

54. method as claimed in claim 53 is characterized in that, described inspection step comprises that whether the information determined in the described payload portions conclude information matches with content being concluded information with the described content in the structure that corresponding destination is associated.

55. method as claimed in claim 53 is characterized in that, described inspection step comprises the information of filter application in described payload portions.

56. method as claimed in claim 55 also comprises with the route box of described filter propagation in the described network, in order to carry out described inspection.

57. method as claimed in claim 53 also comprises the route box in the described network is programmed, to carry out described reception, inspection and route step.

58. method as claimed in claim 53 is characterized in that, described inspection step comprises the inspection attribute, in order to determine the how described grouping of route.

59. method as claimed in claim 53 also comprises and carries out described inspection step route box.

60. method as claimed in claim 53, it is characterized in that, described a plurality of cache server is a first order cache server, and described method also comprises utilizes content-based route that the digital content of high-speed cache is sent to second level cache server.

61. method as claimed in claim 60 comprises that also the digital content of determining described request is whether on the cache server of the described second level.

62. method as claimed in claim 61 also comprises based on described and determines that user's order that will be received is sent to described first order cache server.

63. method as claimed in claim 60 is characterized in that, described transfer step utilizes content-based route that the digital content of high-speed cache is sent to described second level cache server based on the history that the user who is received orders.

64. one kind is used for guaranteeing the method for routing packets together at network and service quality, said method comprising the steps of:

Reception has the grouping of stem part and payload portions;

The described payload portions of checking described grouping in network core is in order to determine whether and the how described grouping of route;

The service quality of determining described grouping guarantees; And

Guarantee the optionally described grouping of route based on described inspection and described service quality.

65., it is characterized in that described inspection step comprises that whether the information of determining described payload portions conclude that with the described content in the structure that the map network destination is associated information is complementary with content being concluded information as the described method of claim 64.

66., also be included in and carry out described inspection step on the router in the described network core as the described method of claim 64.

67., it is characterized in that described inspection step comprises the information matches in filtrator and the described payload portions as the described method of claim 64.

68., also comprise with on the router of described filter propagation in the described network, in order to carry out described inspection as the described method of claim 67.

69., also comprise the router in the described network programmed to carry out described reception, inspection and route step as the described method of claim 64.

70., it is characterized in that described inspection step comprises checks that attribute is in order to determine the how described grouping of route or not leave described grouping fully behind as the described method of claim 64.

71. the method for a route messages in network, described method comprises:

Reception has the message of stem part, at least one main body and at least one attribute;

Described main body of retrieval and described attribute from described message;

Order based on described main body retrieval;

The service quality of determining described message guarantees;

For determining whether and how the described message of route is applied to described order in network core with described attribute; And

Guarantee the optionally described message of route based on described application and described service quality.

72., it is characterized in that the step of the described order of described retrieval comprises the filtrator of retrieval corresponding to described order as the described method of claim 71.

73., also comprise the described message of route if described attribute satisfies described order as the described method of claim 71.

74., also do not comprise if described attribute does not satisfy described order abandoning described message as the described method of claim 71.

75., further comprising the steps of as the described method of claim 71:

Retrieval is corresponding to a plurality of filtrators of a plurality of orders;

The a plurality of attributes of retrieval from described message;

Each described attribute and each described filtrator are mated to determine whether any described corresponding order is met; And

Whether be met the optionally described message of route based on any described order.

76., also be included in and carry out described inspection step on the router in the described network core as the described method of claim 71.

77. one kind guarantees the device of routing packets together with service quality in network, described device comprises:

Be used to receive the module of grouping with stem part and payload portions;

At least one described payload portions that is used for checking described grouping in network core is in order to determine whether and the module of the described grouping of route how;

The module that is used for the service quality assurance of definite described grouping; And

Guarantee the optionally module of the described grouping of route based on the check result that obtains from the above step with by the definite service quality of the above step.

78. as the described device of claim 77, it is characterized in that, described inspection module comprise be used for determining described payload portions information whether with content is concluded information is with the map network destination or instruct the described content in the structure that the rule of correspondence handled in the router is associated to conclude the module that information is complementary.

79., also comprise the module that is used on the router of described network core, carrying out described inspection step as the described device of claim 77.

80., it is characterized in that described inspection module comprises the module that is used for the information matches of filtrator and described payload portions as the described device of claim 77.

81., also comprise being used for described filter propagation to the router of described network in order to carry out the module of described inspection as the described device of claim 80.

82., also comprise being used for the router of described network is programmed to carry out the module of described reception, inspection and processing as the described device of claim 77.

83., it is characterized in that described device is a router as the described device of claim 77.

84. a device that is used at the network route messages, described device comprises:

Be used to receive the module of message with stem part, at least one main body and at least one attribute;

Be used for from the module of described message described main body of retrieval and described attribute;

Be used for module based on described main body retrieval order;

Be used to and determine whether and the how described message of route and the module of in network core, described attribute and described order being mated;

The module that is used for the service quality assurance of definite described grouping; And

Be used under described attribute satisfies the situation of described order, guaranteeing the optionally module of the described message of route based on described service quality.

85., it is characterized in that the described module that is used to retrieve described order comprises the module that is used to retrieve corresponding to the filtrator of described order as the described device of claim 84.

86., also comprise being used for satisfying under the situation of described order and guaranteeing the optionally module of the described message of route based on described service quality at described attribute as the described device of claim 84.

87., also comprise the module that is used under described attribute does not satisfy the situation of any described order of storing on the described router, abandoning described message as the described device of claim 84.

88., also comprise as the described device of claim 84:

Be used to retrieve module corresponding to a plurality of filtrators of a plurality of orders;

Be used for from the module of a plurality of attributes of described message retrieval;

Filtering module is used for each described attribute and each described filtrator are complementary to determine whether any described corresponding order is met; And

Be used for whether being met the optionally module of the described message of route based on any described order.

89., also comprise one or more modules that are used on the router of described network core, carrying out described filtration step as the described device of claim 84.

90., it is characterized in that described device is a router as the described device of claim 84.

91. the method for a route and cached data grouping in multicast network said method comprising the steps of:

Reception has the grouping of stem part and payload portions;

Check that in network core the described payload portions of described grouping is in order to determine whether and how described grouping to be routed to the subscriber;

Based on the optionally described grouping of route of described inspection; And

Local cache is from the data of described grouping in described network core.

92., also be included in and carry out described inspection step on the router as the described method of claim 91.

93., it is characterized in that described inspection step comprises the information of filter application in described payload portions as the described method of claim 91.

94. as the described method of claim 93, also comprise with on the router of described filter propagation in the described network in order to carry out described inspection.

95., also comprise the router in described network programmed to carry out described reception, inspection and route step as the described method of claim 91.

96., it is characterized in that described inspection step comprises checks that attribute is in order to determine the how described grouping of route as the described method of claim 91.

97., also comprise the data of time mark high-speed cache as the described method of claim 91.

98., also comprise the data of indexes cached as the described method of claim 91.

99., further comprising the steps of as the described method of claim 91:

Receive requests for data; And

Whether the data of determining high-speed cache satisfy described request.

100., further comprising the steps of as the described method of claim 91:

Local cache is from the data of described grouping on the edge routing node.

101. it is as the described method of claim 91, further comprising the steps of: the data that after the expiration of time frame T, remove high-speed cache.

102. a network that is used for route and cached data grouping, described network comprises:

The edge routing node, the grouping that it receives and route has stem part and payload portions, described edge routing node comprises:

Intelligent router, the grouping that its route receives, described intelligent router comprises the instruction that is used for following operation:

Check that in network core the described payload portions of described grouping is in order to determine whether and how described grouping to be routed to the subscriber; And

Based on the optionally described grouping of route of described inspection; And

Cache manger, it is operably connected to described intelligent router, and described cache manger comprises the instruction that is used for following operation:

Local cache is from the data of described grouping in local cache;

And

The core routing node of one or more receptions and the described grouping of route.

103., also comprise as the described network of claim 102:

Be operably connected to the agency of described edge routing node, it comprises the instruction that is used for following operation:

Determine the position of the data of high-speed cache;

The data of retrieval high-speed cache from described local cache; And

Handle the cached data of being retrieved.

104., it is characterized in that a core routing node in one or more core routing nodes is positioned at the upstream straight of described edge routing node as the described network of claim 102, described upstream straight core routing node comprises:

The intelligent router of the grouping that route receives, described intelligent router comprises the instruction that is used for following operation:

The described payload portions of checking described grouping in network core is in order to determine how described grouping is routed to the subscriber; And

Based on the optionally described grouping of route of described inspection; And

Cache manger, it is operably connected to described intelligent router, and described cache manger comprises the instruction that is used for following operation:

Local cache is from the data of described grouping in local cache.

105., also comprise: a plurality of channel managers that the characteristic of a plurality of channels is provided as the described network of claim 102.

106., it is characterized in that described cache manger also comprises the instruction of the data that are used for the time mark high-speed cache as the described network of claim 102.

107., it is characterized in that described cache manger also comprises the instruction of the data that are used for indexes cached as the described network of claim 102.

108., it is characterized in that described cache manger also comprises the instruction that is used for following operation as the described network of claim 102:

Receive requests for data; And

Whether the data of determining high-speed cache satisfy described request.

109. the device of a route and cached data grouping in multicast network, described device comprise a plurality of processors and are used for the instruction of following operation:

Reception has the grouping of stem part and payload portions;

Check that in network core the described payload portions of described grouping is in order to determine whether and how described grouping to be routed to the subscriber;

Based on the optionally described grouping of route of described inspection; And

Local cache is from the data of described grouping in described network core.

110. as the described device of claim 109, it is characterized in that, described a plurality of processor comprises the first processor and second processor, and wherein said first processor is carried out described inspection and route instruction optionally, and described second processor is carried out the local cache instruction.

Images