RE: HTTP Asynchronous Client Notifications (draft paper)

Absolutely agree.  I hit the quick send with the assumption (unstated) that
by multicast it was meant opening a multicast socket (in the 224.x.x.x
range) joining it for receipt etc.  I was not thinking multicast in the
broad sense.  Multicast sockets of that type are based on UDP, but multicast
as a logical design could be implemented in a large variety of ways.

	Tim  

-----Original Message-----
From: Noah_Mendelsohn@lotus.com [mailto:Noah_Mendelsohn@lotus.com]
Sent: Friday, May 18, 2001 12:21 PM
To: Narahari, Sateesh
Cc: xml-dist-app@w3.org
Subject: RE: HTTP Asynchronous Client Notifications (draft paper)


Sateesh Narahari writes:

>> True multicast is based on UDP and does not ack the packets. 

Sorry, but I believe that is a significant oversimplification.  As far as 
I know, multicast is a term used to describe a broad range of techniques 
for sending information to a specified group of receivers:  I.e. 
transmission is (typically) to more than one recipient, but unlike 
broadcast is not to everyone listening.  A specific group of listeners is 
targeted.  There is a tremendous amount of literature, describing a very 
broad range of multicast techniques, including reliable, unreliable, 
causally ordered, etc..  For example, here is a bibliography that I 
stumbled on from a Google search: [1].

As far as I know, a broad range of techniques are used by one system or 
another multicast system for dealing with acknowledgments.  Yes, it is 
possible to send acknowledgments for each recipient directly back to an 
originator.  That technique tends to work in cases where multicast groups 
are known to be small (so, few acks come back).  Other systems of reliable 
multicast use a tree topology for transmission, and fold acknowledgements 
along the reverse paths.  Each point in the tree folds only 
acknoweldgements from the systems to which it transmitted.  Specialized 
systems involve techniques such as voting to handle acknowledgements (see 
[2]: unfortunately, I am not aware of any online copies of this paper). In 
such systems, one may consider a message to have been successfully 
delivered if, for example, any three out of five nodes acknowledge receipt 
successfully.  (To reliably read data resulting from the message in such 
systems, you must find a majority of nodes that agree on a value.  If you 
think about it, you cannot get stale data with such an algorithm.  If at 
least three nodes accepted the multicast 
with an update in the example above, then there is no way to put together 
a group of three nodes that all agree on anything less than the latest 
information.) 

Anyway, multicast is not a single technique and it is certainly not tied 
to any one underlying technology such as UDP.  If and when we consider 
multicast as a message pattern for SOAP/XMLP, the first thing we will have 
to do is to decide what sort of multicast and to solve what sort of 
problems.  In the long run, it is quite reasonable to assume that one user 
or another will wish to build quite a variety of multicast implementations 
on top of the core protocol.  It would be nice if the core protocol 
provided just the right hooks to allow such open-ended extensibility.

[1] http://www.roads.lut.ac.uk/DS-Archive/MTP.html
[2] Gifford, D.K. Weighted voting for replicated data. Operating Systems 
Review 13, 5, Dec. 1979, pp 150-162. 

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------

Received on Friday, 18 May 2001 15:47:27 UTC