Re: [AMG]: Some thoughts on Multicast.

Stuart,

You've laid out the following two-dimensional taxonomy of multicast:

True multicast
  One-way (1,1)
  Request-Reply (1,2)
Simulation of multicast through sequence of unicasts
  One-way (2,1)
  Request-Reply (2,2)

(1,1) is easily handled through a binding to a multicast transport (MCT). I
can give you the name of a vendor if you're interested ;>). Also, (1,2) is
most commonly used with a single respondent, typically to make the actual
location of the server transparent to the client through the indirection of
a broadcast address. Again, binding to an appropriate MCT does the trick.

The use of (1,2) with multiple respondents is rare and (2,1) and (2,2) are
inherently unscaleable. Even so, (1,2) with multiple respondents, (2,1), and
(2,2) can be accomodated by a "logic layer" (your "magic under the hood")
between the XMLP layer and MCT/HTTP.

For example, suppose you want to use (1,2) with multiple respondents. On the
client side, the XMLP layer passes the request message down to the "logic
layer." The logic layer calls the MCT to publish the request to its
subscribers and waits a suitable amount of time for the MCT to receive
responses. The logic layer then packages up any received responses into a
reply and passes the reply back up to the XMLP layer.

Or, suppose you want to use (2,2) with one or multiple respondents. On the
client side, the XMLP layer passes the request message down to the "logic
layer." The logic layer maintains a list of subscribers and uses HTTP to do
a point-to-point RPC to each.  Again, the logic layer packages up the
responses into a reply and passes the reply back up to the XMLP layer. In
the case of (2,1), the logic layer simply tosses the responses.

In all cases, things look no different on the server side than for any other
RPC, as you point out.

So, as far as the XMLP Layer on the client side is concerned, the logic
layer looks like just another transport, right? In other words, I don't
think consideration of multicast belongs within the scope of the XMLP WG.
Supporting all the different types of multicast simply means creating
bindings to transports that provide the required functionality. Of course,
such a "logic layer" solution implies that all addressing of subscribers be
hidden from the XMLP layer, but isn't that as it should be?

The only possible complication would be in the metadata describing what a
response to the XMLP Layer looks like. In the case of multiple respondents,
that metadata would need to indicate that a sequence/array of the response
type was expected, instead of just one instance of the response type.

Even if you want to get really exotic and allow each of multiple respondents
to return multiple replies, this could still be incorporated in the above
scheme: the metadata would simply need to indicate that the response
returned to the XMLP Layer was a sequence of sequences of the response type.

In sum, I would be very hesitant to try to incorporate various kinds of
multicast support into XMLP. IMHO, support for multicast belongs below the
XMLP layer.

Frank DeRose
Software Architect
TIBCO Software Inc.
3165 Porter Dr
Palo Alto, CA 94303
650-846-5570 (vox)
650-846-1267 (fax)
frankd@tibco.com
www.tibco.com

Received on Thursday, 22 March 2001 23:47:41 UTC