RE: HTTP Asynchronous Client Notifications (draft paper)

Is UDP reliable ?. Event notification must be reliable, especially in the
case of business events.
 
Sateesh

-----Original Message-----
From: Collier, Timothy R [mailto:timothy.r.collier@intel.com]
Sent: Friday, May 18, 2001 10:46 AM
To: 'Mike Dierken'; 'Frank DeRose'; xml-dist-app@w3.org
Subject: RE: HTTP Asynchronous Client Notifications (draft paper)


True multicast is based on UDP and does not ack the packets.  A multicast
scheme implemented on top of http/TCP would ack and would have "implosion".
 
    Tim
 

-----Original Message-----
From: Mike Dierken [mailto:mike@DataChannel.com]
Sent: Friday, May 18, 2001 9:05 AM
To: 'Frank DeRose'; eamon.otuathail@clipcode.com; xml-dist-app@w3.org
Subject: RE: HTTP Asynchronous Client Notifications (draft paper)



Do multicast transports inherently suffer from ACK implosion? (every client
does a low level acknowledgement at the exact same time).

What strategies are used to avoid this? 
Can intermediaries mitigate ACK implosion? And if so can they also help
build a multi-hop fan-out approach, which might reduce the resource load on
an individual machine? Then it becomes a cost reduction exercise & using
zero-price software (HTTP, etc) and low-price hardware might be a viable
strategy - especially when the potential network of receivers is as large as
the Web.

Mike 

> -----Original Message----- 
> From: Frank DeRose [ mailto:frankd@tibco.com <mailto:frankd@tibco.com> ] 
> Sent: Friday, May 04, 2001 6:53 PM 
> To: eamon.otuathail@clipcode.com; xml-dist-app@w3.org 
> Subject: RE: HTTP Asynchronous Client Notifications (draft paper) 
> 
> 
> IMHO, building event notification on top of HTTP is a really bad idea. 
> 
> Think about the implications of using Technique 3 in your paper 
> (Delay-until-event, "never-ending-request") to do 
> publish/subscribe with 
> wide fanout (1 publisher -> n subscribers, where n is very large). 
> 
> HTTP (or rather, TCP, the usual underlying transport) is a 
> connection-oriented, point-to-point protocol. 
> 
> So, first of all, you will consume resources just keeping the 
> connections 
> open; as you noted in your paper, long-lived connections can 
> get terminated 
> after an appropriate interval, so they will constantly need to get 
> reestablished (by whom?), with all the attendant round-trips. 
> 
> Secondly, every time a publisher publishes a message, it will 
> have have to 
> multiplex it into n point-to-point messages. 
> 
> In this scenario, the network is quickly overwhelmed. 
> 
> The right way to deliver events is through a multicast 
> transport. Of course, 
> picking the right multicast transport and turning it into a 
> standard that is 
> widely accepted, satisfies all security considerations, and 
> has support in 
> standard software components (like browsers) is a major political 
> undertaking. But, paying the price up front is vastly 
> preferable to trying 
> to graft event notification onto HTTP. 
> 
> Frank DeRose 
> TIBCO Software Inc. 
> 3165 Porter Dr 
> Palo Alto, CA 94303 
> 650-846-5570 (vox) 
> 650-846-1267 (fax) 
> frankd@tibco.com 
> www.tibco.com 
>