ken@gvax.cs.cornell.edu (Ken Birman) (07/30/90)
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
ken@gvax.cs.cornell.edu (Ken Birman) (08/02/90)
Article 359 of comp.sys.isis: Subject: Bypass "configuration" for a trading floor problem Message-ID: <43884@cornell.UUCP> 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. ... 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. I am a graduate student of David Gelernter's at Yale. As my thesis research, I have developed a software architecture, the process trellis, for building parallel real-time monitors which seems similar to the architecture you described. This software architecture organizes a collection of heterogeneous processes into a hierarchical graph. While the interpretation of the layers of the graph is not fixed by the architecture a typical trellis will contain the following layers: raw-data, data-filter, correlation, diagnosis, recommendation. Data flows up the trellis hierarchy and queries (commands to calculate new data) flow down the trellis hierarchy. We have constructed with colleagues from the Yale Med. School a prototype monitor for an intensive care unit that contains roughly 100 processes. With colleagues from the NYU business school we have designed a trellis program to monitor stock transactions and detect insider trading. A process trellis shell provides a high-level interface for writing trellis applications. This shell implements all of the parallelism and all of the inter-process communication, as well as scheduling the processes on a multi-processor. The goal of scheduling is to use the fewest number of processors necessary to guarantee that the program runs in real-time; our real-time guarantee is somewhere between hard and soft real-time. While this shell is implemented in Linda, it is not tightly wedded to Linda, and there is no obvious reason it could not be implemented in ISIS. I have several papers on the process trellis which I would be happy to send you if you are interested. --- mike factor INTERNET: <factor@cs.yale.edu> USMAIL: Dept Comp Sci, Yale University BITNET: <factor@yalecs.bitnet> Box 2158, Yale Station USENET: <factor@yale.uucp> New Haven, CT 06520 203-432-1278