RE: HTTP Asynchronous Client Notifications (draft paper)

Hi. 
 
We have to be very careful on what we mean by "reliable".  There is
transport level reliability like TCP which is limited to 
an ack and does not conform to exactly once semantics end to end especially
over multiple hops. You could also lose messages in an end to end scenerio.
You can get exactly once semantics (message not lost or duplicated end to
end, if 
not delivered a negative response) only if many things are addressed:
 
1. There is persistence on send side and receive side of messages. 
2. There is a handoff algorithm between a sending message handling layer and
the transport and the transport and 
    the receiving  message handling layer. 
3. In a very rigid definition of exactly once the scope is exactly once from
senders DB to receivers DB. This is 
    difficult to achieve without cooperation of the sending and receiving
applications. There is handoff algorithms 
    between  the application and the sending message handling layer, and the
receiving message handling layer
    and the application. There might also be a need for duplicate
elimination at the receiving application level (because 
    of the window between a DB commit, and return to the message handling
layer for successful processing). 
4. There is a higher level protocol built in with end to end negative acks
and positive acks, and retries with retry interval 
    and timeouts. The alternative approach to this item is exactly once as
defined in MOM products like MQSeries.  
 
A useful reference is exactly once as defined in ebXML. It permits both
approaches defined in 4, with different approaches
used in different hops. 

-----Original Message-----
From: Narahari, Sateesh [mailto:Sateesh_Narahari@jdedwards.com]
Sent: Friday, May 18, 2001 11:23 AM
To: xml-dist-app@w3.org
Subject: 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 
>

Received on Friday, 18 May 2001 15:00:53 UTC