RE: [AMG]: Some thoughts on Multicast.

Hi Frank,

Thanks for your thoughful comments. Broadly I think we share similar views
on this topic. A few comments mingled in below.

Regards

Stuart

> -----Original Message-----
> From: Frank DeRose [mailto:frankd@tibco.com]
> Sent: 23 March 2001 04:42
> To: xml-dist-app@w3.org
> Subject: 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)

That's a really neat and compact summary... I think it captures it all...

> (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 ;>). 

S'ok... I think I know where I can lay my hands on one ta ;->>

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

I'm not so sure I'd think of that as multicast so much as addressing by
'function' or 'role'.

> The use of (1,2) with multiple respondents is rare and (2,1) and (2,2) are
> inherently unscaleable. 

Agreed.

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

Sure... there is a but here, which is that group membership (subscriptions)
need to be managed somehow (magic) in the  2,x cases.

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

Also, do we want to know where the responses came from?

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

It's not a place I have strong motivations to go right now. I was just
responding to an action from an AMG telecon to give somethought to multicast
in conjunction with request/response.

> 
> 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 Monday, 26 March 2001 15:58:01 UTC