W3C home > Mailing lists > Public > ietf-discuss@w3.org > November 2001

Re: Requirements for reliable message delivery

From: Graham Klyne <GK@Ninebynine.org>
Date: Mon, 26 Nov 2001 11:15:00 +0000
Message-Id: <5.1.0.14.2.20011126105037.046172d0@joy.songbird.com>
To: "John Ibbotson" <john_ibbotson@uk.ibm.com>
Cc: Brian E Carpenter <brian@hursley.ibm.com>, Discuss Apps <discuss@apps.ietf.org>, "Richard P King" <rpk@us.ibm.com>
John,

Thanks for your clarifications, though I must confess I am still struggling 
to understand the rationale for what you seem to be describing:

(1) Complexity of distributed commit:  it seems to me that the simplest 
option would be if the "reliable message transfer" were just a single 
end-to-end hop, without the issues of cascading.  This suggests that 
intermediate hops may be best effort if the message-passing endpoint has 
the recovery logic.

(2) Achieving reliability:  it is my view that reliability is mostly 
achieved by strong implementation and operational deployment, not protocol 
design.  But however good a system is, there is still a possibility of 
failure.  I think the challenge for protocol design is to make the 
behaviour deterministic, in the sense that the sender of a message has a 
reliable indication of the eventual outcome of message transfer (or, in a 
transactional context, I suppose it would be better to say that the two 
endpoints have a reliable way to synchronize their record of state).

I see a problem with this scenario, which I must assume you've considered, 
so I hope it will flush out any misunderstandings:

      +------+     +------------+     +--------+
      |Sender|-->--|Intermediary|-->--|Receiver|
      +------+     +------------+     +--------+

   (a) First hop:  sender hands off to intermediate.
       On completion, assumes that delivery is (or will be) done.

   (b) Intermediary falls over.  Message (or record of state) held at 
intermediary is lost.

   (c) Sender and Receiver are now out of sync, with no outstanding 
unresolved state

(3) You talk about transferring state information with the message;  it 
seems to me that such state information can only ever be partial with 
respect to whatever function it is that the endpoint applications are 
trying to perform.  So the need for some kind of end-to-end synchronization 
doesn't go away.

#g
--


At 03:27 PM 11/22/01 +0000, John Ibbotson wrote:
> >From our experience with reliable transactional messaging, we believe that
>a single hop approach is the starting point. Certainly end-to-end
>reliability is required at an application level, but we believe this should
>be built on a single-hop model with multiple hops being considered as
>cascaded single hops. An important consideration here is transactionality.
>The complexity of distributed 2 phase commit can be simplified by adopting
>the single hop model. A unidirectional message over a single hop can be
>managed as a single unit of work with commit/rollback being applied when a
>message is reliably delivered to the endpoint. Therefore in an asynchronous
>request/response single hop model, there are three units of work - the
>request, the processing and the response. This extends to the multi hop
>case so for N hops, there are 2N +1 units of work. Issues such as
>end-to-end security, authentication, non-repudiation etc can then be
>implemented at the application layer on top of the messaging.
>
>A reliable messaging protocol requires the definition of "state machines"
>at the endpoints of the single hop together with state information
>transferred as part of the message between the endpoints. These may be
>abstracted to a set of operations that we have briefly described in the
>requirements document. Separation of the state machines from the state
>information means that alternative bindings of the state information to
>different transports can be implemented.
[...]


------------
Graham Klyne
GK@NineByNine.org
Received on Monday, 26 November 2001 08:53:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 23 March 2006 20:11:29 GMT