\documentclass[11pt,twoside]{article}\makeatletter

\IfFileExists{xcolor.sty}%
  {\RequirePackage{xcolor}}%
  {\RequirePackage{color}}
\usepackage{colortbl}
\usepackage{wrapfig}
\usepackage{ifxetex}
\ifxetex
  \usepackage{fontspec}
  \usepackage{xunicode}
  \catcode`⃥=\active \def⃥{\textbackslash}
  \catcode`❴=\active \def❴{\{}
  \catcode`❵=\active \def❵{\}}
  \def\textJapanese{\fontspec{Noto Sans CJK JP}}
  \def\textChinese{\fontspec{Noto Sans CJK SC}}
  \def\textKorean{\fontspec{Noto Sans CJK KR}}
  \setmonofont{DejaVu Sans Mono}
  
\else
  \IfFileExists{utf8x.def}%
   {\usepackage[utf8x]{inputenc}
      \PrerenderUnicode{–}
    }%
   {\usepackage[utf8]{inputenc}}
  \usepackage[english]{babel}
  \usepackage[T1]{fontenc}
  \usepackage{float}
  \usepackage[]{ucs}
  \uc@dclc{8421}{default}{\textbackslash }
  \uc@dclc{10100}{default}{\{}
  \uc@dclc{10101}{default}{\}}
  \uc@dclc{8491}{default}{\AA{}}
  \uc@dclc{8239}{default}{\,}
  \uc@dclc{20154}{default}{ }
  \uc@dclc{10148}{default}{>}
  \def\textschwa{\rotatebox{-90}{e}}
  \def\textJapanese{}
  \def\textChinese{}
  \IfFileExists{tipa.sty}{\usepackage{tipa}}{}
\fi
\def\exampleFont{\ttfamily\small}
\DeclareTextSymbol{\textpi}{OML}{25}
\usepackage{relsize}
\RequirePackage{array}
\def\@testpach{\@chclass
 \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else
  \ifnum \@lastchclass=7 5 \else
   \ifnum \@lastchclass=8 \tw@ \else
    \ifnum \@lastchclass=9 \thr@@
   \else \z@
   \ifnum \@lastchclass = 10 \else
   \edef\@nextchar{\expandafter\string\@nextchar}%
   \@chnum
   \if \@nextchar c\z@ \else
    \if \@nextchar l\@ne \else
     \if \@nextchar r\tw@ \else
   \z@ \@chclass
   \if\@nextchar |\@ne \else
    \if \@nextchar !6 \else
     \if \@nextchar @7 \else
      \if \@nextchar (8 \else
       \if \@nextchar )9 \else
  10
  \@chnum
  \if \@nextchar m\thr@@\else
   \if \@nextchar p4 \else
    \if \@nextchar b5 \else
   \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi
   \fi \fi  \fi  \fi  \fi  \fi  \fi \fi \fi \fi \fi \fi}
\gdef\arraybackslash{\let\\=\@arraycr}
\def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}}
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\def\abbr{}
\def\corr{}
\def\expan{}
\def\gap{}
\def\orig{}
\def\reg{}
\def\ref{}
\def\sic{}
\def\persName{}\def\name{}
\def\placeName{}
\def\orgName{}
\def\textcal#1{{\fontspec{Lucida Calligraphy}#1}}
\def\textgothic#1{{\fontspec{Lucida Blackletter}#1}}
\def\textlarge#1{{\large #1}}
\def\textoverbar#1{\ensuremath{\overline{#1}}}
\def\textquoted#1{‘#1’}
\def\textsmall#1{{\small #1}}
\def\textsubscript#1{\@textsubscript{\selectfont#1}}
\def\textxi{\ensuremath{\xi}}
\def\titlem{\itshape}
\newenvironment{biblfree}{}{\ifvmode\par\fi }
\newenvironment{bibl}{}{}
\newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par }
\newenvironment{citbibl}{}{\ifvmode\par\fi }
\newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi }
\newenvironment{docDate}{}{\ifvmode\par\fi }
\newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi }
\newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par }
\newenvironment{msHead}{\vskip 6pt}{\par}
\newenvironment{msItem}{\vskip 6pt}{\par}
\newenvironment{rubric}{}{}
\newenvironment{titlePart}{}{\par }

\newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}}
\newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}}
\newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}}
\newcolumntype{P}[1]{){\arraybackslash}p{#1}}
\newcolumntype{B}[1]{){\arraybackslash}b{#1}}
\newcolumntype{M}[1]{){\arraybackslash}m{#1}}
\definecolor{label}{gray}{0.75}
\def\unusedattribute#1{\sout{\textcolor{label}{#1}}}
\DeclareRobustCommand*{\xref}{\hyper@normalise\xref@}
\def\xref@#1#2{\hyper@linkurl{#2}{#1}}
\begingroup
\catcode`\_=\active
\gdef_#1{\ensuremath{\sb{\mathrm{#1}}}}
\endgroup
\mathcode`\_=\string"8000
\catcode`\_=12\relax

\usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry}
\usepackage{framed}

\definecolor{shadecolor}{gray}{0.95}
\usepackage{longtable}
\usepackage[normalem]{ulem}
\usepackage{fancyvrb}
\usepackage{fancyhdr}
\usepackage{graphicx}
\usepackage{marginnote}

\renewcommand{\@cite}[1]{#1}


\renewcommand*{\marginfont}{\itshape\footnotesize}

\def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif}

  \pagestyle{fancy}

\usepackage[pdftitle={A Multicast Protocol For Content-Based Publish-Subscribe Systems},
 pdfauthor={}]{hyperref}
\hyperbaseurl{}

	 \paperwidth210mm
	 \paperheight297mm
              
\def\@pnumwidth{1.55em}
\def\@tocrmarg {2.55em}
\def\@dotsep{4.5}
\setcounter{tocdepth}{3}
\clubpenalty=8000
\emergencystretch 3em
\hbadness=4000
\hyphenpenalty=400
\pretolerance=750
\tolerance=2000
\vbadness=4000
\widowpenalty=10000

\renewcommand\section{\@startsection {section}{1}{\z@}%
     {-1.75ex \@plus -0.5ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large\bfseries}}
\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
     {-1.75ex\@plus -0.5ex \@minus- .2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large}}
\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
     {-1.5ex\@plus -0.35ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\large}}
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
     {-1ex \@plus-0.35ex \@minus -0.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\normalsize}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}%
     {1.5ex \@plus1ex \@minus .2ex}%
     {-1em}%
     {\reset@font\normalsize\bfseries}}


\def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt}
 \@tempdima 1.5em \begingroup
 \parindent \z@ \rightskip \@pnumwidth 
 \parfillskip -\@pnumwidth 
 \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par
 \endgroup}
\def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}}
\def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}}
\def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}}
\def\l@subparagraph{\@dottedtocline{5}{10em}{5em}}
\@ifundefined{c@section}{\newcounter{section}}{}
\@ifundefined{c@chapter}{\newcounter{chapter}}{}
\newif\if@mainmatter 
\@mainmattertrue
\def\chaptername{Chapter}
\def\frontmatter{%
  \pagenumbering{roman}
  \def\thechapter{\@roman\c@chapter}
  \def\theHchapter{\roman{chapter}}
  \def\thesection{\@roman\c@section}
  \def\theHsection{\roman{section}}
  \def\@chapapp{}%
}
\def\mainmatter{%
  \cleardoublepage
  \def\thechapter{\@arabic\c@chapter}
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \pagenumbering{arabic}
  \setcounter{secnumdepth}{6}
  \def\@chapapp{\chaptername}%
  \def\theHchapter{\arabic{chapter}}
  \def\thesection{\@arabic\c@section}
  \def\theHsection{\arabic{section}}
}
\def\backmatter{%
  \cleardoublepage
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \setcounter{secnumdepth}{2}
  \def\@chapapp{\appendixname}%
  \def\thechapter{\@Alph\c@chapter}
  \def\theHchapter{\Alph{chapter}}
  \appendix
}
\newenvironment{bibitemlist}[1]{%
   \list{\@biblabel{\@arabic\c@enumiv}}%
       {\settowidth\labelwidth{\@biblabel{#1}}%
        \leftmargin\labelwidth
        \advance\leftmargin\labelsep
        \@openbib@code
        \usecounter{enumiv}%
        \let\p@enumiv\@empty
        \renewcommand\theenumiv{\@arabic\c@enumiv}%
	}%
  \sloppy
  \clubpenalty4000
  \@clubpenalty \clubpenalty
  \widowpenalty4000%
  \sfcode`\.\@m}%
  {\def\@noitemerr
    {\@latex@warning{Empty `bibitemlist' environment}}%
    \endlist}

\def\tableofcontents{\section*{\contentsname}\@starttoc{toc}}
\parskip0pt
\parindent1em
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\newenvironment{reflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemsep}{0pt}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\itshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{sansreflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\itemsep}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\upshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{specHead}[2]%
 {\vspace{20pt}\hrule\vspace{10pt}%
  \phantomsection\label{#1}\markright{#2}%

  \pdfbookmark[2]{#2}{#1}%
  \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}%
  }{}
      \def\TheFullDate{2010-03-15 (revised: 15 March 2010)}
\def\TheID{\makeatother }
\def\TheDate{2010-03-15}
\title{A Multicast Protocol For Content-Based Publish-Subscribe Systems}
\author{}\makeatletter 
\makeatletter
\newcommand*{\cleartoleftpage}{%
  \clearpage
    \if@twoside
    \ifodd\c@page
      \hbox{}\newpage
      \if@twocolumn
        \hbox{}\newpage
      \fi
    \fi
  \fi
}
\makeatother
\makeatletter
\thispagestyle{empty}
\markright{\@title}\markboth{\@title}{\@author}
\renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@
\belowdisplayskip \abovedisplayskip
\abovedisplayshortskip \z@ plus2\p@
\belowdisplayshortskip 4\p@ plus2\p@ minus2\p@
\def\@listi{\leftmargin\leftmargini
               \topsep 2\p@ plus1\p@ minus1\p@
               \parsep 2\p@ plus\p@ minus\p@
               \itemsep 1pt}
}
\makeatother
\fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm}
\fancyhf{} 
\setlength{\headheight}{14pt}
\fancyhead[LE]{\bfseries\leftmark} 
\fancyhead[RO]{\bfseries\rightmark} 
\fancyfoot[RO]{}
\fancyfoot[CO]{\thepage}
\fancyfoot[LO]{\TheID}
\fancyfoot[LE]{}
\fancyfoot[CE]{\thepage}
\fancyfoot[RE]{\TheID}
\hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true}
\fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}}

\date{}
\usepackage{authblk}

\providecommand{\keywords}[1]
{
\footnotesize
  \textbf{\textit{Index terms---}} #1
}

\usepackage{graphicx,xcolor}
\definecolor{GJBlue}{HTML}{273B81}
\definecolor{GJLightBlue}{HTML}{0A9DD9}
\definecolor{GJMediumGrey}{HTML}{6D6E70}
\definecolor{GJLightGrey}{HTML}{929497} 

\renewenvironment{abstract}{%
   \setlength{\parindent}{0pt}\raggedright
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
   \textcolor{GJBlue}{\large\bfseries\abstractname\space}
}{%   
   \vskip8pt
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
}

\usepackage[absolute,overlay]{textpos}

\makeatother 
      \usepackage{lineno}
      \linenumbers
      
\begin{document}

             \author[1]{Prof. Vishal  Nagar}

             \author[2]{Yashpal  Singh}

             \author[3]{D.C.  Dhubkarya}

             \affil[1]{  CSe Jhnai-India,UPTU Lucknow-India}

\renewcommand\Authands{ and }

\date{\small \em Received: 10 February 2010 Accepted: 3 March 2010 Published: 15 March 2010}

\maketitle


\begin{abstract}
        


The publish/subscribe (or pub/sub) paradigm is a simple and easy to use model for interconnecting applications in a distributed environment. Many existing pub/sub systems are based on pre-defined subjects, and hence are able to exploit multicast technologies to provide scalability and availability. An emerging alternative to subject-based systems, known as content-based systems, allow information consumers to request events based on the content of published messages. This model is considerably more flexible than subject-based pub/sub, however it was previously not known how to efficiently multicast published messages to interested content-based subscribers within a network of broker (or router) machines. In this paper, we develop and evaluate a novel and efficient technique for multicasting within a network of brokers in a content-based subscription system, thereby showing that content-based pub/sub can be deployed in large or geographically distributed settings.

\end{abstract}


\keywords{Multicast, Publishers, Subscribers, information  spaces, OMG, content-based routing}

\begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) 
\textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark}
\end{textblock*}

\begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) 
\textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}}
\end{textblock*}


\let\tabcellsep& 	 	 		 
\section[{INTRODUCTION}]{INTRODUCTION}\par
he publish/subscribe paradigm is a simple, easy to use and efficient to implement paradigm for interconnecting applications in a distributed environment. Pub/sub based middleware is currently being applied for application integration in many domains including financial, process automation, transportation, and mergers and acquisitions. Pub/sub systems contain information providers, who publish events to the system, and information consumers, who subscribe to particular categories of events within the system. The system ensures the timely delivery of published events to all interested subscribers. A pub/sub system also typically contains message brokers that are responsible for routing messages between publishers and subscribers. The earliest pub/sub systems were subject-based. In these systems, each unit of information (which we will call an event) is classified as belonging to one of a fixed set of subjects (also known as groups, channels, or topics). Publishers are required to label each event with a subject; consumers subscribe to all the events within a particular subject. For example a subject-based pub/sub system for stock trading may define a group for each stock issue; publishers may post information to the appropriate group, and subscribers may subscribe to information regarding any issue. In the past decade, systems supporting this paradigm have matured significantly resulting in several academic and Yashpal Singh 1 , Vishal Nagar 2 , D.C.Dhubkarya 1 yash\textunderscore biet@yahoo.com, vishal\textunderscore biet@yahoo.com, dcd3580@yahoo.com 1.BIET Jhansi, 2. CSE Jhansi , India industrial strength solutions \hyperref[b3]{[4]}[10] \hyperref[b11]{[12]}[13] \hyperref[b14]{[15]}. A similar approach has been adopted by the OMG for CORBA event channels \hyperref[b10]{[11]}.An emerging alternative to subject-based systems is content-based subscription systems \hyperref[b5]{[6]} \hyperref[b13]{[14]}. These systems support a number of information spaces, each associated with an event schema defining the type of information contained in each event. Our stock trade example (shown in Figure  {\ref 1}) may be defined as a single information space with an event schema defined as the tuple [issue: string, price: dollar, volume: integer]. A contentbased subscription is a predicate against the event schema of an information space, such as (issue=?IBM? \& price < 120 \& volume > 1000) in our example.With content-based pub/sub, subscribers have the added flexibility of choosing filtering criteria along as many dimensions as event attributes, without requiring pre-definition of subjects. In our stock trading example, the subject-based subscriber is forced to select trades by issue name. In contrast, the content-based subscriber is free to use an orthogonal criterion, such as volume, or indeed a collection of criteria, such as issue, price and volume. Furthermore, content-based pub/sub removes the administrative overhead of defining and maintaining a large number of groups, thereby making the system easier to manage. Finally, content-based pub/sub is more general in that it can be used to implement subjectbased pub/sub, while the reverse is not true. While contentbased pub/sub is the more powerful paradigm, efficient and scalable implementations of such systems have previously not been developed. In order to efficiently implement a content-based pub/sub system, two key problems must be solved:\par
i. The problem of efficiently matching an event against a large number of subscribers on a single message broker. ii.\par
The problem of efficiently multicasting events within a network of message brokers. This problem becomes crucial in two settings: 1) when the pub/sub system is geographically distributed and message brokers are connected via a relatively low speed WAN (compared to high-speed LANs), and 2) when the pub/sub system has to scale to support a large number of publishers, subscribers and events. In both cases it becomes crucial to limit the distribution of a published event to T only those brokers that have subscribers interested in that event.One of the strengths of subject-based pub/sub systems is that both problems are trivial to solve: the matching problem is solved using a mere table lookup; the multicast problem is solved by defining a multicast group per subject, and multicasting each event to the appropriate multicast group. For content-based pub/sub systems, however, previous literature does not contain solutions to either problem, matching or multicasting. In this paper we present the first efficient solution to the multicast problem for content-based pub/sub. In a companion paper \hyperref[b1]{[2]} we present an efficient soution to the matching problem for these systems.There are two straightforward approaches to solving the multicasting problem for content-based systems: (1) in the match-first approach, the event is first matched against all subscriptions, thus generating a destination list and the event is then routed to all entries on this list; and (2) in the flooding approach, the message is broadcast or flooded to all destinations using standard multicast technology and unwanted messages are filtered out at these destinations. The match-first approach works well in small systems, but in a large system with thousands of potential destinations, the increase in message size makes the approach impractical. Further, with this approach we may have multiple copies of the same message going over the same network link on its way to multiple remote subscribers. The flooding approach suffers when, in a large system, only a small percentage of clients want any single message. Furthermore, the flooding technique cannot exploit locality of information requests, i.e., when clients in a single geographic area are, for many applications, likely to have similar requests for data.\par
The central contribution of this paper is a new protocol for content-based routing, an efficient solution to the multicast problem for content-based pub/sub systems. With this protocol, called link matching, each broker partially matches events against subscribers at each hop in the network of brokers to determine which brokers to send the message. Further, each broker forwards messages to its subscribers based on their subscriptions. The disadvantages of the match-first approach are avoided since no additional information is appended to the message headers. Further, at most one copy of a message is sent on each link. The disadvantages of the flooding approach are avoided as the message is only sent to brokers and clients needing the message, thus exploiting locality. We illustrate, using a network simulator, that flooding overloads the network at significantly lower publish rates than link matching. We also describe our implementation of a distributed Java based prototype of content-based pub/sub brokers. The remainder of this paper is organized as follows. In section 2, we present a solution to the matching problem (i.e., the case when the network consists of a single broker).\par
In section 3, we discuss how to extend the solution to the matching problem into a solution to the content-based routing problem in a multi-broker network. In section 4, we evaluate the performance of this approach and compare it to the flooding approach.\par
II. 
\section[{THE MATCHING ALGORITHM}]{THE MATCHING ALGORITHM}\par
This section summarizes a non-distributed algorithm for matching an event against a set of subscriptions, and returning the subset of subscriptions that are satisfied by the event. (A more detailed presentation of matching along with experimental and analytic measures of performance are the subject of our companion paper \hyperref[b1]{[2]}.) This matching algorithm is the basis of our distributed multicast protocol, presented in the following section.\par
Our approach to matching is based on sorting and organizing the subscriptions into a parallel search tree (or PST) data structure, in which each subscription corresponds to a path from the root to a leaf. The matching operation is performed by following all those paths from the root to the leaves that are satisfied by the event. Intuitively, this data structure yields a scaleable algorithm because it exploits the commonality between subscriptions as shared prefixes of paths from root to leaf. Figure  {\ref 2} shows an example of a matching tree for an event schema consisting of five attributes a1 through a5. These attributes could represent, for example, the stock issue, price, or volume attributes mentioned above. The root of the tree corresponds to a test of the value of attribute a1, the nodes at the next level correspond to a test of attribute a2, etc. The branches are labeled with the values of the attributes being tested. In the example, we only show equality tests (although range tests are also possible), so the right branch of the root represents the test a1 = 1. The left branch of the root, with label *, means that the subscriptions along that branch do not care about the value of the attribute. Each leaf is labeled with the identifiers of all the subscribers wishing to receive events matching the predicate, i.e., all the tests from the root to the leaf. For example, in Figure  {\ref 2}, the rightmost leaf corresponds to a subscription whose predicate is (a1 =1 \& a2=2 \& a3=3 \& a5=3\par
). Since a4 does not appear in this subscription, it is represented by a label * in the PST. Given this tree representation of subscriptions, the matching algorithm proceeds as follows. We begin at the root, with current attribute a 1 . At any non-leaf node in the tree, we find the value v j of the current attribute a j . We then traverse any of the following edges that apply: (1) the edge labeled v j if there is one, and (2) the edge labeled * if there is one. This may lead to either 0, 1, or 2 successor nodes (or more in the general case where the tests are not all strict equalities). We initiate parallel subsearches at each successor node. When any of the parallel subsearches reaches a leaf, all subscriptions at that leaf are added to the list of matched subscriptions. For example, running the matching algorithm with the matching tree of Figure  {\ref 2} and the event a = <1, 2, 3, 1, 2> will visit all the nodes marked with dark circles and will match four subscription predicates, corresponding to the dark circles at leaf nodes.\par
The way in which attributes are ordered from root to leaf in the PST can be arbitrary. In our experience, however, performance seems to be better if the attributes near the root are chosen to have the fewest number of subscriptions labeled with a *.\par
In the companion paper \hyperref[b1]{[2]}, we have analytically shown that the cost of matching using the above algorithm increases less than linearly as the number of subscriptions increase. 
\section[{A. Optimizations}]{A. Optimizations}\par
A number of optimizations may be applied to the parallel search tree to decrease matching time --these optimizations are explained fully in \hyperref[b1]{[2]}.\par
Factoring-Some search steps can be avoided, at the cost of increased space, by factoring out certain attributes. That is, certain attributes ---preferably those for which the subscriptions rarely contain -don't care? tests ---are selected as indices. A separate subtree is built for each possible value (or for ranges, each distinguished value range) of the index attributes.\par
Trivial Test Elimination-Nodes with a single child which is reached by a *-branch may be eliminated. Delayed Branching-Following *-branches may be delayed until after a set of tests have been applied. This optimization prunes paths from that *-branch which are inconsistent with the tests.\par
It is worth noting that, under certain circumstances, after applying optimizations, the parallel search tree will no longer be a tree but instead a directed acyclic graph.\par
III. 
\section[{THE LINK MATCHING ALGORITHM}]{THE LINK MATCHING ALGORITHM}\par
The previous section described a non-distributed algorithm for matching events to subscriptions. This section presents the central contribution of this paper --an extended matching algorithm for a network of brokers, publishers, and subscribers (as shown in Figure  {\ref 3}). The problem, in this case, is to efficiently deliver an event from a publisher to all distributed subscribers interested in the event.\par
One straightforward solution to this problem is to perform the matching algorithm of the previous section at the broker nearest to the publisher, producing a destination list consisting of the matched subscribers. This destination list may be undesirably long in a large network with thousands of subscribers, and it may be infeasible to transmit and process large messages containing long destination lists throughout the network. Link matching is our strategy for multicasting events without using destination lists. After receiving an event, each broker receiving an event performs just enough matching steps to determine which of its neighbors should receive it. As shown in Figure  {\ref 3}, neighbors may be brokers or clients (this figure shows a spanning tree derived from the actual non-tree broker network). That is, each broker, rather than determining which subset of all subscribers is to receive the event, instead computes which subset of its neighbors is to receive the event, i.e., it determines those links along which it should transmit the message. Intuitively, this approach should be more efficient because the number of links out of a broker is typically much less than the total number of subscribers in the system.\par
To perform link matching, we use the parallel search tree (PST) structure of the previous section, where each path from root to leaf represents a subscription. We augment the PST with vectors of trits, where the value of each trit is either -Yes,? (Y) -N o,? (N) or -M aybe? (M). We begin by annotating leaf nodes in the PST with a trit vector of size equal to the number of links out of that broker.\par
For each link out of a broker, a position in a trit vector determines whether to send matched events down that link, based on whether there exists a subscription reachable via that link. Leaf annotations are then propagated to non-leaf nodes in a bottom-up manner. A -Yes? in a trit annotation means that (based on the tests performed so far) the event will be matched by some subscriber that is best reached by sending the message along the given link; -No ? means that the event will definitely not be matched by any subscriber along that link; and -M aybe? means that further searching must take place to determine whether or not there is such a subscriber. Annotations are described in more detail below.\par
The link matching algorithm consists of the following three steps. First, at each broker, the parallel search tree is annotated with a trit vector encoding link routing information for the subscriptions in the broker network.\par
Second, an initialization mask of trits must be computed at each broker for each spanning tree used for message routing.\par
(Collectively, the masks for a single spanning tree across all the brokers encode the spanning tree in the network.) Third, at match time the initialization mask for a given spanning tree (based on the publisher) is refined until the broker can determine whether or not to send a message on each link, that is, until all values in the mask are either Yes or No. These three steps are described in detail in the following three subsections respectively. 
\section[{A. Annotating the PST}]{A. Annotating the PST}\par
Each broker in the network has a copy of all the subscriptions, organized into a PST as discussed in the previous section, and illustrated in Figure  {\ref 2}. Note that the approach we describe here for computing tree annotations is limited to trees with only equality tests and don't care branches. A more general solution requires the use of a parallel search graph and is not described here to conserve space.Each broker annotates each node of the PST with a trit vector annotation. This annotation vector contains m trits, one per outgoing link from the broker. As mentioned earlier, the trit is Yes when a search reaching that node is guaranteed to match a subscriber reachable through that link, No when a search reaching that node will have no subsearch leading to a subscriber reachable through that link, and Maybe otherwise.Annotation is a recursive process starting with the leaves of the parallel search tree, which represent the subscriptions. We label each leaf node trit in link position l with Y if one of that leaf node's subscribers is located at a destination reached through link l, and N otherwise. After all the leaves have been annotated, we propagate the annotations back toward the root of the PST using two operators: An example is shown in Figure  {\ref 5}. 
\section[{B. Computing The Initialization Mask}]{B. Computing The Initialization Mask}\par
We assume that each broker knows the topology of the broker network as well as the best paths between each broker and each destination. To simplify the discussion, we ignore alternative routes for load balancing or recovery from failure and congestion. Instead, we assume that events always follow the shortest path. From this topology information, each broker constructs a routing table mapping each possible destination to the link which is the next hop along the best path to the destination. We also assume that the broker knows the set of spanning trees, only one of which will ever be used by each publisher.\par
In the case where the broker network is acyclic (Figure  {\ref 3}), computation of the spanning tree is straightforward. If the broker topology is not a tree, then computing the spanning tree is more complex. However, even in this case, there will be a relatively small set of different spanning trees. At worst, there will be one spanning tree for each broker that has publisher neighbors and in most practical cases, where the broker network is -t ree-like?, there will be significantly fewer spanning trees. Using these best paths and spanning trees, each broker computes the downstream destinations for each spanning tree. A destination is downstream from a broker when it is a descendant of the broker on the spanning tree. Based upon the above analysis, each broker associates each unique spanning tree with an initialization mask, one trit per link. The trit at link l has the value Maybe if at least one of the destinations routable via l is a descendant of the broker in the spanning tree; and No if none of the destinations routable via l are descendants of the broker 1 . The significance of the mask is that an event arriving at a broker should only be propagated along those links leading to descendant destinations --that is, those links whose mask bit is M and will eventually be refined to a Y via matching, described below. 
\section[{C. Matching Events}]{C. Matching Events}\par
When an event originating at a publisher is received at a broker, the following steps are taken using the annotated search tree:\par
i. A mask is created and initialized to the initialization mask associated with the publisher's spanning tree. ii.\par
Starting with the root node, the mask is refined using the trit vector annotation at the current node. During refinement, any M in the mask is replaced by the corresponding trit vector annotation. If the mask is now fully refined ---that is, it has no M trits ---then the search terminates, returning the refined mask. Otherwise, step 3 is executed. iii.\par
The designated test is performed and, 0, 1, or 2 children are found for continuing the search as mentioned in Section 2. A subsearch is executed at each such child using a copy of the current mask.\par
On the return of each subsearch, all Maybe trits in the current mask for which a Yes trit exists in the subsearch mask, are converted to Yes trits. After all the children have been searched, the remaining Maybe trits in the current mask are made No trits. The current mask is returned. iv.\par
The top-level search terminates and sends a copy of the event to all links corresponding to Yes trits in the returned mask.\par
This concludes the description of the link matching algorithm.\par
IV. 
\section[{IMPLEMENTATION AND PERFORMANCE}]{IMPLEMENTATION AND PERFORMANCE}\par
We have implemented the matching algorithms described above and tested them on a simulated network topology as well as on a real LAN, as explained in the following two subsections respectively. 
\section[{A. Simulation Results}]{A. Simulation Results}\par
The goals of our simulations were twofold i.\par
To measure the network loading characteristics of the link matching protocol and compare it to that of the flooding protocol. ii.\par
To measure the processing time taken by the link matching algorithm at individual broker nodes and compare it to that of centralized matching (i.e., the non-trit matching algorithm described in Section 2). 
\section[{i. Simulation Setup}]{i. Simulation Setup}\par
The simulated broker network topology is shown in Figure  {\ref 6}. The topology has 39 brokers and 10 subscribing clients per broker, each client with potentially multiple subscriptions. In addition, there is an unspecified number of publishing clients --three of these publishers, shown as P1, P2, and P3 in the figure, publish events that are tracked by the simulator and the rest simply load the brokers by publishing messages that take up CPU time at the brokers. As shown in Figure  {\ref 6}, the 39 brokers form three trees of 13 brokers each. The root of each of these three trees are connected to the roots of the other two. Also, as shown, there are a small number of lateral links between non-root nodes in the trees to allow messages from some publishers to follow a different path than other publishers. This topology is intended to model a real-world wide-area network with each of the three rooted trees distributed far \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore \textunderscore  from each other (intercontinental), but the brokers within a tree closer to each other (interstate). The top-level brokers are modeled to have a one-way hop delay of about 65 ms, links from them to their next level neighbors is 25ms, the third level hop delay is about 10ms, and the hop delay to clients is 1ms.\par
The broker network simulates an information space with several control parameters, such as the number of attributes in the event schema, the number of values per attribute and the number of factoring levels (i.e., the preferred attributes of Section 2.1). Subscriptions are generated randomly, but one of the control parameters is the probability that each attribute is a * (i.e., don't care). For non-* attributes, the values are generated according to a zipf distribution. In addition, we simulate -l ocality of interest? in subscriptions by having subscribers within each subtree of the broker topology have similar distributions of interested values whereas subscriptions across from the other two subtrees have different distributions.\par
Events are also generated randomly, with attribute values in a zipf distribution. Events arrive at the publishing brokers according to a Poisson distribution. The mean arrival rate of published events, which is a key parameter, is controlled by a user specified parameter.\par
In the simulation, time is measured in -t icks? of a virtual clock, with each tick corresponding to about 12 microseconds. The virtual clock, used only for simulation purposes, is implemented as synchronized brokers' clocks.\par
Each event carries with it its -current? virtual time from the beginning of the simulation. An event spends time traversing a link (-hop delay?), waiting at an incoming broker queue, getting matched, and being sent (software latency of the communication stack).\par
ii. 
\section[{Network Loading Results}]{Network Loading Results}\par
As mentioned earlier, the purpose of this simulation run was to determine, for the link matching and the flooding protocols, the event publish rate at which the broker network becomes -ov erloaded? (or congested), for a varying number of subscriptions. A broker is overloaded when its input message queue is growing at a rate higher than the broker processor can handle. This simulation run was performed with the following parameters. The event schema has 10 attributes (with 2 attributes used for factoring), and each attribute has 5 values. The subscriptions are generated randomly in such a way that the first attribute is non-* with probability 0.98, and this probability decreases at the rate of 85\% as we go from the first to the last attribute. This means that subscriptions are very selective --on average, each event matches only about 0.1\% of subscriptions. The number of events published is 500.\par
The results from the simulation run are shown in Chart 1.\par
The chart shows that a broker network running the flooding protocol saturates at significantly lower event publish rates than the link matching protocol for any number of subscriptions. In particular, when each event is destined to only a small percentage of all clients, link matching dramatically outperforms flooding. In the case where events are distributed quite widely, the difference is not as great, since most links are used to distribute events in the link matching protocol. This result illustrates that link matching is well-suited to the type of selective multicast that is typical of pub/sub systems deployed on a WAN. 
\section[{iii. Matching Time Results}]{iii. Matching Time Results}\par
As mentioned earlier, the purpose of this simulation run was to measure the cumulative processing time taken by the link matching algorithm and the centralized (non-trit) matching algorithm. The processing time taken per event in the link matching algorithm is the sum of the times for all the partial matches at intermediate brokers along the way from publisher to subscriber. This simulation run was performed with the following parameters. The event schema has 10 attributes (with 3 attributes used for factoring), and each attribute has 3 values. The subscriptions are generated randomly in such a way that the first attribute is non-* with probability 0.98, and this probability decreases at the rate of 82\% we go from the first to the last attribute. Again, this means that subscriptions are very selective --on average, each event matches only about 1.3\% of subscriptions. The number of events published is 1000.\par
The results from the simulation run are shown in Chart 2.\par
For the link matching algorithm, six lines, -LM 1 hop? through -LM 6 hops?, are shown --these correspond to the number of hops an event had to traverse on its way from a publishing broker to a subscriber. On the Y axis, the chart shows the number of -m atching steps? performed on average. A matching step is the visitation of a single node in the matching tree. Although our current implementation has traded off time efficiency in favor of space efficiency, we estimate that a time efficient implementation can execute a matching step in the order of a few microseconds.\par
The chart shows that the cumulative matching steps for up to four hops using the link matching algorithm is not more than the number of matching steps taken by the centralized algorithm. For more than four hops the link matching algorithm takes more matching steps, however the link matching protocol is still a better choice over the centralized algorithm because (1) the extra processing time for link matching (of the order of much less than 1ms) is insignificant compared to network latency (of the order of tens of ms), (2) the gain in latency to regional publishers and subscribers obtained by distributing brokers is significant, and (3) for really large numbers of subscribers (i.e., much beyond 10000), the slopes of the lines in Chart 2 indicate that centralized matching may take more steps than link matching. 
\section[{B. System Prototype}]{B. System Prototype}\par
We have implemented the matching algorithms in a network of broker nodes where brokers are connected using a specified topology. A broker network may implement multiple information spaces by specifying an event schema (one per information space) defining the type of information contained in each event. Clients subscribe to an information space by first connecting to a broker node, then providing subscription information which includes a predicate expression of event attributes. This section describes the implementation of such a broker node. As illustrated in Figure  {\ref 7}, each broker node consists of a matching engine, client and broker protocols, a connection manager and a transport layer. The matching engine which implements one of the matching algorithms described earlier, consists of a subscription manager, and an event parser. A subscription manager receives a subscription from a client, parses the subscription expression, and adds the subscription to the matching tree. An event parser first parses a received event, then un-marshals it according to the pre-defined event schema. The matchine engine then uses the implemented matching algorithm to get a list of subscibers interested in the un-marshaled event.\par
The broker to client protocol is implemented by the client protocol object, whereas the broker to broker protocol is implemented using the broker protocol object. These protocol objects are robust enough to handle transient failures of connections by maintaining an event log per client. Once a client re-connects after a failure, the client protocol object delivers the events received while the client was dis-connected. A garbage collector periodically cleans up the log. The connection manager object maintains the connections to clients and the other brokers in the network.\par
The transport layer sends and receives messages to and from clients and other brokers in the network. To improve scalability, it implements an asynchronous -sen d? operation by maintaining a set of outgoing queues, one per connection.\par
A broker thread sends a message by en-queueing it in the appropriate queue. A pool of sending threads is responsible for monitoring these queueues for outgoing messages, and sending them to destinations using the underlying network protocol.\par
Currently, broker nodes are implemented in Java using TCP/IP as the network protocol. In an experimental setup where a 200 MHz pentium pro PC is used as a broker node, and low end PCs (using 133 MHz pentium processors) are used as clients connected using a 16MB token ring network, the current implementation of the broker can deliver upto 14,000 events/sec. Also, as shown in Chart 3 for the pure matching algorithm, brokers can perform matching very quickly, at the rate of about 4ms for 25,000 subscribers. In fact, our matching algorithms are so efficient that the transport system and network costs of a broker outweigh the cost of matching at a broker.\par
V. 
\section[{RELATED WORK}]{RELATED WORK}\par
As mentioned earlier, alternatives to the link matching approach were either to (1) first compute a destination list for events by matching at or near the publisher and then distributing the event using the distribution list, or (2) to multicast the event to all subscribers which would then filter the event themselves.\par
Computing a destination list is a good approach for small systems involving only a few subscribers. For these cases, the matching algorithm presented in section 2 provides a good solution. However, scalability is essential if contentbased systems are to fill the same infrastructure requirements as subject-based publish/subscribe systems. In cases where destination lists may grow to include hundreds or thousands of destinations, the match-first approach becomes impractical. Multicasting an event and then filtering also has its disadvantages. Lack of scalability and an inability to exploit locality was shown for the flooding approach for event distribution. Flooding is a good approximation of the broadcast approach since most WAN multicast techniques require the use of a series of routers or bridges connecting LAN links. IP multicast \hyperref[b4]{[5]}[1] allows subscriptions to a subrange of possible IP addresses known as class D addresses. Subscriptions to these groups is propagated back through the network routers implementing IP. Pragmatic General Multicast \hyperref[b15]{[16]} has been proposed as an internetwide multicast protocol with a higher level of service. This protocol is an extension of IP multicast that provides -TC P-like? reliability, and therefore is also reliant on multicastenabled routers. A mechanism for multicast in a network of bridge-connected LANs is proposed in \hyperref[b6]{[7]}. In this approach, members of a group periodically broadcast to an all-bridge group their membership in a multicast group. Bridges note these messages and update entries in a multicast table, including an expiration time.\par
The content-based subscription systems that have been developed do not yet address wide-area, scaleable event distribution, i.e. although they are content-based subscription systems, they are not content-based routing systems. SIENA allows content-based subscriptions to a distributed network of event servers (brokers) \hyperref[b5]{[6]}. SIENA filters events before forwarding them on to servers or clients. However, a scaleable matching algorithm for use at each server has not been developed. The Elvin system \hyperref[b13]{[14]} uses an approach similar to that used in SIENA. Publishers are informed of subscriptions so that they may -qu ench? events (not generate events) for which there are no subscribers. In \hyperref[b13]{[14]}, plans are discussed for optimizing Elvin event matching by integrating an algorithm similar to the parallel search tree. This algorithm, presented in \hyperref[b7]{[8]}, converts subscriptions into a deterministic finite automata for matching. However, no plans for optimizations for broker links (such as our optimization through trit annotation) are discussed. Another algorithm for optimizing matching is discussed in \hyperref[b8]{[9]}. At analysis time, one of the tests aij of each subscription is chosen as the gating test; the remaining tests of the subscription (if any) are residual tests. At matching time, each of the attributes aj in the event being matched is examined. The event value vj is used to select those subscriptions i whose gating tests include aij = vj. The residual tests of each selected subscription are then evaluated: if any residual test fails, the subscription is not matched; if all residual tests succeed, the subscription is matched. Our parallel search tree performs this type of test for each attribute, not just a single gating test attribute. One outlet for the work presented in this paper could be through Active Networks \hyperref[b16]{[17]}. Active Networks have been touted as a mechanism for eliminating the strong dependence of route architectures on Internet standards. Active Networks allow the dynamic inclusion of code either at routers or by replacing passive packets with active code. The SwitchWare project \hyperref[b2]{[3]} follows the former approach and is most appropriate to the type of router customization proposed in this paper. With SwitchWare, digitally signed type-checked modules may be loaded into network routers.\par
Our matching and multicasting component could be one such module. 
\section[{VI. CONCLUSIONS}]{VI. CONCLUSIONS}\par
In this paper, we have presented a new multicast technique for content-based publish/subscribe systems known as link matching. Although several publish/subscribe systems have begun to support content-based subscription, the novel contribution of link matching is that routing is based on a hop-by-hop partial matching of published events. The link matching approach allows distribution of events to a large number of information consumers distributed across a WAN without placing an undo load on the network. The approach also exploits locality of subscriptions. We evaluate how an implementation of content-based routing protocol performs by showing that a broker network stays up while running the link matching algorithm whereas brokers get overloaded for the same event arrival rate running the flooding algorithm, since brokers have larger numbers of events to process in the flooding case. We also describe a broker implementation that can handle message loads of up to 14000 events per second on a 200 MHz Pentium PC. This shows that content-based routing using link matching supports a more general and flexible form of publish-subscribe while admitting a highly efficient implementation. Future work is concentrating on further validation of our approach to content-based routing. We are currently working to deploy our content-based routing brokers on a large private network. This will allow us to conduct system tests under actual application loads. Sample applications will include some from the financial trading and process control domains. In addition to these system tests, we are also continuing work with our simulator to examine different types of messaging loads. In particular, since many publish/subscribe applications exhibit peak activity periods, we are examining how our protocol performs with bursty message loads. VII.\begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-2.png}
\caption{\label{fig_0}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-3.png}
\caption{\label{figure3}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-4.png}
\caption{\label{figure4}}\end{figure}
 			\footnote{In some cases, where some destinations reachable through a link downstream on some spanning trees and are not on others, the search may be optimized by splitting the link into two or more "virtual" links.} 		 		\backmatter  			  				\begin{bibitemlist}{1}
\bibitem[Hanson et al. ()]{b8}\label{b8} 	 		‘A predicate Matching Algorithm for Database Rule Systems’.  		 			Eric N Hanson 		,  		 			Moez Chaabouni 		,  		 			Chang-Ho Kim 		,  		 			Yu-Wang Wang 		.  	 	 		\textit{SIGMOD 1990},  				May 23-25 1990. p. .  	 
\bibitem[Tennenhouse et al. (1997)]{b16}\label{b16} 	 		\textit{A Survey of Active Network Research,? IEEE Communications Magazine},  		 			J Tennenhouse 		,  		 			W D Smith 		,  		 			D Sincoskie 		,  		 			G Wetherall 		,  		 			Minden 		.  		January, 1997. 35 p. .  	 
\bibitem[Birman (1993)]{b3}\label{b3} 	 		 			K P Birman 		.  	 	 		\textit{T he process group approach to reliable distributed computing,? pages},  				Dec. 1993. 36 p. .  	 
\bibitem[Mishra et al. (1991)]{b9}\label{b9} 	 		\textit{Consul: A Communication Substrate for Fault-Tolerant Distributed Programs, Dept. of computer science},  		 			Shivakant Mishra 		,  		 			Larry L Peterson 		,  		 			Richard D Schlichting 		.  		 TR 91-32.  		Nov. 1991.  		 			The University of Arizona 		 	 
\bibitem[CORBA services: Common Object Service Specification (1998)]{b10}\label{b10} 	 		\textit{CORBA services: Common Object Service Specification},  		July 1998.  		 			Object Management Group ; Object Management Group 		 	 	 (Technical report) 
\bibitem[Aguilar ()]{b0}\label{b0} 	 		‘Datagram Routing for Internet Multicasting’.  		 			Lorenzo Aguilar 		.  	 	 		\textit{? ACM Computer Communications Review}  		1984. 14  (2)  p. .  	 
\bibitem[Deering ()]{b6}\label{b6} 	 		 			Stephen E Deering 		.  	 	 		\textit{M ulticast Routing in InterNetworks and Extended LANs},  				1988. 18 p. .  	 
\bibitem[Carzaniga et al.]{b5}\label{b5} 	 		\textit{Desi gn of a Scalable Event Notification Service: Interface and Architecture},  		 			Antonio Carzaniga 		,  		 			David S Rosenblum 		,  		 			Alexander L Wolf 		.  		 \url{http://www.cs.colorado.edu/users/carzaniga/siena/index.html}  		 	 
\bibitem[Segall and Arnold (1997)]{b13}\label{b13} 	 		\textit{El vin has left the building: A publish/subscribe notification service with quenching,? Proceedings of AUUG97},  		 			Bill Segall 		,  		 			David Arnold 		.  		September, 1997. Brisbane, Austrailia.  	 
\bibitem[Gough and Smith ()]{b7}\label{b7} 	 		 			John Gough 		,  		 			Glenn Smith 		.  		\textit{Eff icient Recognition of Events in a Distributed System,? Proceedings of ACSC-18},  				 (Adelaide, Australia)  		1995.  	 
\bibitem[Powell Guest Editor (1996)]{b12}\label{b12} 	 	 	 		\textit{Group Communication?},  				 			David Powell,  			( Guest Editor 		 (ed.)  		April 1996. 39 p. .  	 
\bibitem[Aguilera et al. ()]{b1}\label{b1} 	 		‘Matching Events in a Content-Based Subscription System’.  		 			Marcos Aguilera 		,  		 			Rob Strom 		,  		 			Daniel Sturman 		,  		 			Mark Astley 		,  		 			Tushar Chandra 		.  		 \url{http://www.research.ibm.com/gryphon}  	 	 		\textit{Upcoming IBM Technical Report}  		1998.  	 
\bibitem[Oki et al. (1993)]{b11}\label{b11} 	 		 			Brian Oki 		,  		 			Manfred Pfluegl 		,  		 			Alex Siegel 		,  		 			Dale Skeen 		.  	 	 		\textit{T he Information Bus -An Architecture for Extensible Distributed Systems,? pages},  				Dec. 1993. 27 p. .  	 
\bibitem[Speakman et al. (1998)]{b15}\label{b15} 	 		 			Tony Speakman 		,  		 			Dino Farinacci 		,  		 			Steven Lin 		,  		 			Alex Tweedly 		.  		\textit{PGM Reliable Transport Protocol,? IETF Internet Draft},  				August 24. 1998.  	 
\bibitem[Alexander (1998)]{b2}\label{b2} 	 		\textit{Th e SwitchWare Active Network Architecture,? IEEE Network Special Issue on Active and Controllable Networks},  		 			Scott Alexander 		.  		July 1998. 12 p. .  	 
\bibitem[Uyless Black. TCP/IP & Related Protocols ()]{b4}\label{b4} 	 		\textit{Uyless Black. TCP/IP \& Related Protocols},  				1995. McGraw-Hill. p. .  	 	 (Second Edition) 
\bibitem[Skeen]{b14}\label{b14} 	 		\textit{Vitria's Publish-Subscribe Architecture: Publish-Subscribe Overview},  		 			Dale Skeen 		.  		 \url{http://www.vitria.com/}  		 	 
\end{bibitemlist}
 			 		 	 
\end{document}
