PreCache NetInjector Documentation Center : PreCache NetInjector Administration

Welcome to PreCache NetInjector

   







NetInjector Overview

— a brief consideration of the basic concepts


Push and pull

The traditional publisher posts content to a server and waits for a member of the target audience to find the content and request it.

This 'pull' model is resource intensive and depends on a wide range of complex transactions for success. Not least of these is the requirement that the interested parties find one another in the first place.

Publishing content in a distributed 'push' environment reverses this model: the publisher posts content to a pool of receptive members. There is no need to create redundant content, to manage server farms holding enormous volumes of content, or to facilitate the hapless surfer's search efforts: members of the group receive data automatically, according to the terms of their relationship with the publisher.

In creating a stock quote service, the traditional internet news site must store all data related to every stock and post it to everyone who requests the information.
The NetInjector news provider can post stock quotes targeted to the specific interests of existing subscribers, rapidly responding to their known preferences.

Channels

A key construct of the NetInjector solution is the channel. Each channel is a namespace of subjects and attributes. The channel exists as a communications port, facilitating the transfer of data from publisher to subscriber. The channel also assures security and provides stable quality of service.

Each area of interest or content type is a subject. Subjects provide a category for content within a channel. Publishers create content for a subject; subscribers receive the subject content.

Channels are further defined by a set of attributes, which enhance content distribution. These attributes provide additional flexibility for sorting and routing information and, therefore, packets.

The stock service for a news service would be organized as a subject within a NetInjector news channel. The channel's subjects could include, in addition to stocks, other areas of interest such as sports and politics.
Within the channel, predefined attributes would allow the publisher and subscriber to filter information by ticker symbol, price, dates, or other data contained within the media provider's information feed.

Agents

Each client accesses the channel via an agent or proxy; the agent is implemented via a proxy. The proxy connection to the router provides an interface for the client to publish and receive notifications for the channel and its subjects.

Proxies receive notifications for the duration of each session. However, the event agent supports methods to pause, suspend, and restart open proxies, avoiding the need to close connections.

Notifications

When a publisher posts new content for a subject within a channel, a notification is prepared for the subscriber base. This notification conforms to the parameters established by the initial configuration of the channel and subject, as well as to the programming logic of the event agent or application.

As the notification passes through the system, the NetInjector router determines the ultimate destination of the notification. At each network node, the notification advances toward the greatest number of subscribers.

Thus, content which targets several subscribers only passes through the network once for a given network node or router. By such content-based routing, NetInjector routes packets based on content rather than by explicit request, greatly reducing loads.

Each notification to a subscriber would contain information about the stock which met the subscriber's particular criteria, consistent with the application logic.
Thus, if the application supports filtering by share volume, then a subscriber could ask to be notified when a stock's daily volume reached a certain level of trading activity. So, too, the agent could be programmed to deliver notifications based on price or any other criteria.

Filtering

Subscribers request content based on their interests. However, the entire data stream for a subject could be vast, exceeding both the requirements of the publisher to serve a target audience and the subscriber's need for content.

By writing filters to better tailor content to a subscriber's interests, the application developer can take best advantage of NetInjector's ability to reduce server load and accelerate the distribution of meaningful content.

These filters may sort data by the predefined criteria established when the channel was created, or they may be created as a concatenation of filters. The application developer may also create filters for specific instances.

In delivering notifications, the stock service could allow a subscriber to receive notifications for a given stock once its price exceeded a certain level and trading activity crossed a predetermined barrier.
Furthermore, the service could allow the subscriber to create unique filters based on any data within the stream, facilitating notifications by such constructs as moving averages or price/earnings ratios.

Infrastructure

NetInjector supports a two-stage router environment. One stage routes publisher content; the second delivers subscriber content. Together, this simple topology facilitates efficient data flow between the publisher and the subscriber. Because NetInjector maintains a logical distinction between stages, no data flows within a stage.

Data flow

In a traditional network, each request from a subscriber results in a unique transaction with the server.

In a NetInjector network, the publisher's notification only propagates to those subscribers interested in the content. If all of the subscribers in a neighborhood request the same data, NetInjector generates only one notification.

Each data flow is finely tuned to the subjects and attributes of the channel, ensuring that content is distributed to interested subscribers.

The publisher creates content for the channel, creating a data stream for all subscribers. The routers distribute the content based on subscription information. Each notification propagates towards the neighborhood of interested subscribers.