[comp.sys.isis] What will the pg_client "bypass" interface look like?

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....