NaradaBrokering
Santhosh Kumar Saminathan
Indiana University Bloomington
Abstract
NaradaBrokering is a content distribution
infrastructure for Publish / Subscribe architecture that
was developed by Community Grids Lab at Indiana
University. The system has no bounds on spatial matter
and, rate and scope of the information encapsulated
within these streams or on the number of entities within
the system. NaradaBrokering provides support for the
scalable and efficient dissemination of these data streams.
The substrate incorporates capabilities to mitigate
network-induced effects, and also to ensure that these
streams are secure, reliable, ordered and jitter-reduced.
All components within the system utilize globally
synchronized timestamps.
In this survey paper we are going to give details about the
Naradabrokering system such as the framework,
topology, the matching engine and the web services
supported by the system. We primarily focus on the
analysis of the system.
1. Introduction
The Naradabroker is typically a brokering system for
Publish/Subscribe messaging pattern. In general the
Publish/Subscribe architecture is one designed to enable a
selective topic filtering mechanism for end nodes to
receive the required data. The popularity of this system is
due to the ability of this architecture to decouple senders
and receivers. This allows us a greater scalability in
distribute environment over the traditional RPC methods.
It is not necessary for this system to maintain a state on
the publisher and subscriber, as any one of these can be
up any point of time and send/receive the data. The
receiver can be selective about the data it needs in this
system. This selectivity is achieved using a message
filtering mechanism by creating separate classes when
uploading a new topic. Similar to traditional distributed
systems, Naradabroker also works on multiple nodes.
This case is similar to the DNS and thus reducing the
chances of possible failure and improving the overall
efficiency.
2. Overview
The intersystem communication is established using
messaging broker, which also hosts the information of the
system. A dedicated queuing system ensures allocation of
an independent queue for every different class. Once the
data is placed in the allocated queue the sender may go
down, but the broker will maintain this data unless until
explicitly asked to remove the data from the queue.
The Naradabroker is one such resource brokering
system, which allows voluminous data to be sent at
exceptionally quick rates. It supports a variety of
protocols including TCP/IP, UDP, Multicast, SSL, HTTP,
RTP and HHMS. In addition to such flexibility, it
provides a number of useful features such as reliable
storage interface, a mechanism to compress/decompress
messages internally. Since the state is not stored, the
failure of a single node due to abrupt crash due issues like
imbalanced load distribution will not affect the data stored
in each broken node. It is arranged as a cluster topology
including many other broker nodes, thus reducing the load
on the overall network. Broker nodes are hierarchically
arranged in a form of a tree structure with each node
holding a map (Broker Network Map) to facilitate
traversal through the nodes.
An event is created in order to accommodate the
deliver of matched events after reconnect. Narada allows
you to subscribe to an event that matches to an event
template. The event consumers may create consumer
constraints to specify properties regarding the delivery of
events. The consumer constraints can specify the
conditions like reliable and ordered delivery of events.
Similarly the producer can specify constraints related to
publishing of messages. This includes message
compression, fragmentation and security. The Time To
Live (TTL) field is one of the most important parameters
as it is mandatory to have a countable value to avoid the
count to infinity problem and prevent unwanted
deadlocks. Like most of the brokering system, the
NaradaBroker also supports the message queue models in
the API. An example of such API is Java Message
Service (JMS). The Naradabrokering functionalities such
as scalability, resilience and providing a distributed
solution rather than having a single server are provided to
JMS clients. Further it insulates JMS clients from
knowledge of other brokers. The broker locators are used
to find the valid brokers.
3. BROKER LOCATING AND ROUTING
As already mentioned earlier, the messaging broker is
made up of a number of other broker nodes, which are all
located in a tree pattern. Logically, each broker has
knowledge on how to locate other brokers but however
there is a problem in the form that the client must still
locate the broker nodes and connect to it before
downloading data.
There exists a separate broker locator program, which
propagates certain location specific details to the client.
Such details include the IP of the broker, the port on
which it is listening to and the transport protocol, which it
supports and which will be used. This is all the
information that the client might need to establish a
dedicated connection. One client will have only one
dedicated connection to a single broker, however it is
possible for a client to maintain a number of connections
to many brokers at once thus providing load balance.
When maintaining subscriptions to information, there
are two types of subscriptions to maintain, broker level
and client level. The client level subscriptions refer to the
various clients who have subscribed to different brokers
and the broker level subscriptions refer to the various
information that is maintained at a particular broker node.
Even these client subscriptions are maintained in
hierarchy within the system. The broker is left in charge
with the client subscriptions whereas the cluster controller
handles the broker subscriptions.
There exists a matching engine that matches the received
events to the profiles and the destinations that are
computed. Each node maintains its profile separately.
This profile is built based on the interest on certain
events. There is a constraint included in the profile of
each node, which must be satisfied before being routed.
Each and every profile has a unique ID and a matching
destination, which is most probably recognized as a
subscription. There are many cases of such subscriptions
hierarchically overloading a super super – cluster system
but this can be handled by adding more cluster
controllers. The choice of the constraints on the profile
greatly affects the performance of the system in certain
matching aspects, which will be seen later in this paper.
Regular expressions constraint:
*
This is used to make the search effective in case of
text based content.
5. Narada Transport Framework
The cluster controller is used to manage broker
destinations while the broker manages the client
destinations. Each broker has a set of destinations and the
best path of these destinations is calculated based on the
number of broker hops.
4. MATCHING ENGINES
This forms the crux of the system. This is the part of
the system that matches the requesting client to the
required information at a broker node. There exists a
possibility that there might be more than one matching
engine per node. The efficiency of the matching as
already mentioned earlier depends greatly on the
constraints specified in the profile of the node. Different
types of constraints can be specified on subscriptions like
string based topics separated by a ‘/’ or integer topics,
regular expressions, tag – value pairs or even XPath
queries for that matter.
String based constraint:
* This includes simply mentioned constraints as a string
and separates them using a ‘/’ character.
* Eg. /Uniformity/Recursive
* Subscription to a particular topic in this chain does not
guarantee subscription to all sub topics. This is a factor
that must be taken into account for.
Tag – Value pair constraint:
* This is similar to the string constraints but there is a
fact that the tag value pairs are separated by the tag value
pairs.
*
This mechanism also allows for a * wildcard to look
for all tag, value pairs.
XPath constraint:
* These constraints are mainly used to search on XML
documents. It is used to identify even parts if needed.
* In addition these are also mentioned to search for
XML advertisements across the broker.
The transport framework plays a vital role in the
Narada. The broker nodes communicate through
communication links. Different underlying transport
protocols provide the service. The transport interface
provides the links to the broker node by consulting the
link factory using a transport handler. Based on the links
obtained, the administrative link chooses an optimal
transport link. Thus a reliable communication mechanism
is provided in this system.
6. Naradabroker Capability
The Naradabroker provides various kinds of
capabilities to work in sync with the existing
technologies. It supports interfaces for several systems.
The filters can be used to modify the properties of the
messages to be coherent with many devices such as
PDAs, palmtops, etc. Portability is one of the most
attractive features of Naradabroker. Another capability of
Naradabroker is its compatibility with P2P grids. In P2P it
starts out without broker nodes using only file based web
services. Extra brokers are added in later if a performance
gain is needed or the initial architecture is a success.
7. Analysis
8. Conclusion
We begin by monitoring the performance of
Naradabroker. Upon noting the performance of
Naradabroker while running against varying constraints in
the profile of each client and broker node, we were able to
find that as the specific constraints increased in size per
profile, the CPU cost increased proportionally. It is very
much feasible for use in real time applications as the
delay between nodes increased only by one second as the
string size doubled. Plotted below is the average delay
scatter chart in case of video clients tested against Java
Media Framework (JMF). It was seen that Naradabroker
performs very much better as compared to JMF.
Naradabroker has no significant disadvantage
compared to other technologies of similar use in the
domain of distributed computing. The fact that this
system is not being regularly updated to keep it at pace
with other emerging technologies like Apache ActiveMQ,
RabbitMQ puts Naradabroker at a slight disadvantage.
However on comparing performances with other
technologies it was found that there was no significant
gain or loss for byte oriented data between Naradabroker
and its competitors.
Platform dependence to Windows is still an issue,
which is being worked out, and it is another reason why
complete portability of an existing code has not been
achieved. A few stability and firewall chinks are being
looked at for improving reliability and security.
Taking all factors into consideration it is fair to say
that
even
with
these
minor
disadvantages
Naradabrokering is a technology that is at par with other
systems of its kind.
9. References
[1] The Naradabroker: A flexible messaging
infrastructure, Rahim Lakhoo, Distributed Systems
Group, DSG Seminar, April 2004.
[2] http://en.wikipedia.com
[3] NaradaBrokering: Grid Computing: Making the global
infrastructure a reality, Dr. Russ Miller, Chapter 22
[4] NaradaBrokering User’s Guide, Community Grids
Lab, Indiana University
[5] Deploying the NaradaBrokering substrate in aiding
efficient web and grid service interactions, Geoffrey Fox
and Shrideep Pallikara
[6] NaradaBrokering User’s Guide, Community Grids
Lab, Indiana University
[7] NaradaBrokering and its Applications, Community
Grids
Laboratory
(CGL),
Indiana
University,
http://grids.ucs.indiana.edu/ptliupages/
The above plotted 3 dimensional graph measures the
transmit delay with the size and rate at which the data is
sent. This evaluation had been done using 22 brokers, 102
clients and varying matching frequencies. It can be clearly
seen that the transmit delay increases with the match rate.
[8] Support for high performance real-time collaboration
within the NaradaBrokering Substrate, Shrideep Pallikara,
Hasan Bulut, Pete Burnap, Geoffrey Fox, Ahmet Uyar,
David Walker, Community Grids Lab, Indiana University