Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!rochester!cornell!ken
From: ken@gvax.cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: Bypass "configuration" for a trading floor problem
Message-ID: <43884@cornell.UUCP>
Date: 29 Jul 90 23:50:24 GMT
Sender: nobody@cornell.UUCP
Reply-To: ken@cs.cornell.edu (Ken Birman)
Distribution: comp
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 49

I recently spent some time with a group that uses ISIS in a trading
floor situation and was asked about the following.  The trading system
this group is developing has a multi-tiered structure, in which
various sorts of servers compute things (interest rates, market
volatility, dividend projections, etc) and feed this information
to one another in a sort of layered scheme.

Typical interactions are thus ones in which some small set of
servers either 
	1) sends to subsets of a large set of possible destinations
	   (namely, the clients "interested" in the current quote)
	2) deals fault-tolerantly with request-reply interactions.

This architecture raises lots of problems -- resource management,
best scheme for handling fault-tolerance, integration of ISIS with
other systems (quote "publication" systems, databases, etc). However,
a core question concerns performance: how should the system be designed
so that performance will be as good as possible in ISIS V2.1 and beyond.

The answer is to implement each of these services using a pair of
process groups.  One will be a "diffusion" group, in which the servers
would broadcast using process lists to obtain the subset functionality
needed here.  The second would be a client-server group, overlayed on
top of the diffusion group, and handling request-response operations
(i.e. using coordinator cohort or some other replication scheme).

The interface will be this, assuming that BYPASS is enabled everywhere:

1) To create the "diffusion" group, 
	servers use pg_join(...., PG_DIFFUSION, ....) /* to be added */
	clients use pg_client to hook up.
2) To create the client-server group,
	servers use pg_join as usual
	clients use pg_client to hook up, as usual
3) To send in the diffusion group, servers use process lists (pl_create...)
4) To send in the client-server group, both clients and servers just
   multicast on the group address.  We plan to optimize coord-cohort for
   this purpose.  You should try to use cbcast throughout.

To get really good performance in the diffusion group, you'll need to
use some sort of ethernet or FDDI multicast hardware mechanism, and we
plan to have "transport" protocols capable of doing this available in the
future.  

I wonder if people have other architectures or problems we should be
thinking about?  If so, please consider posting a brief description of
your problem.  

Ken