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