- From: Mike Dierken <mike@DataChannel.com>
- Date: Fri, 18 May 2001 09:05:02 -0700
- To: "'Frank DeRose'" <frankd@tibco.com>, eamon.otuathail@clipcode.com, xml-dist-app@w3.org
- Message-ID: <8E864C73E16B864BB594712EDB3C89A0015C4459@belmail2.datachannel.com>
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 >
Received on Friday, 18 May 2001 12:05:37 UTC