ken@gvax.cs.cornell.edu (Ken Birman) (08/02/90)
From private mail... > >You've indicated several times that the pg_client mechanism will be >extended to support "diffusion" and "client server" interfaces over the >bypass protocol suite. Can you indicate how this will work and how it >will look? > Definitions: 1) diffusion group: small set of servers send to many clients, perhaps using the process list mechanism to send to subsets of a larger set. 2) client-server: small set of servers, many clients, request-reply interactions. The interface we have in mind is this: 1) servers create the process group in the usual way, with pg_join. To have the option of using diffusion multicasts they specify a new option PG_DIFFUSION at start time. 2) clients register with the group by calling pg_client() 3) clients can multicast to the servers using cbcast/abcast and it runs in bypass mode. Clients can also use point-to-point RPC selecting any single server. 4) servers can multicast to: a) the server group only, using the normal group multicast. b) the server group plus any single client, using a destination listing the group address plus the client's address. c) if PG_DIFFUSION was specified, to the server group extended by the full list of clients, using a new bcast option 'D' servers can also send point-to-point messages to any single server or client of the group, including "reply" and "nullreply" messages. ... note that this covers essentially any possible ISIS comm. pattern We would continue to allow applications to use many groups and overlapping groups. How it would work: The client-server and diffusion groups are described by a vector-time much like a normal BYPASS group, but the VT vector is longer. For a normal group of N members, the VT is of length N. For a client-server group with S servers and C clients the length is something like S+C, although if many of the clients are silent for periods of time (don't initiate new messages) the vector could be longer; the C part of it is really a count of the number of "recently active" clients. For a diffusion group with S servers the vector length would just be S. For a group being used both ways, the vector length would be 2S+C (or less). These changes are pretty simple. A trickier one concerns the implementation of subset diffusion multicasts (process lists used to multicast to a subset of the clients of a diffusion group). There is a choice here between sending to all the clients and throwing away extra copies, which is how it works now, and sending a VT of length S*C but sending only to the actual destinations. This VT sounds big to me, so we currently plan to throw messages away on reception if the destination isn't supposed to get a copy. The last issue concerns transport protocols: we are hoping to have an ethernet and an FDDI multicast mechanism in ISIS, connected to the diffusion group facility, sometime later this year. This would obviously be a big win if a diffusion group actually has a lot of clients.
ken@gvax.cs.cornell.edu (Ken Birman) (08/02/90)
In article <44078@cornell.UUCP> ken@cs.cornell.edu (Ken Birman) writes: >.... > For a client-server group with S servers and C clients the length is > something like S+C, although if many of the clients are silent for periods > of time (don't initiate new messages) the vector could be longer; the ^^^^^^` Oops, SHORTER, not longer....