Properties of carrier protocols

[Peter Furniss <peter.furniss@choreology.com>]

This was written on Wednesday (over the Atlantic) and hard-copy available
but not discussed in Mt Laurel. Intention is that it can now be discussed on
this list (or on models + messaging).

This started out to be a contribution on the failure and recovery model, but
I think it's more relevant to what goes in the main state table for the
protocol. Or perhaps it isn't relevant, and just repeats things everyone
already knew.


We anticipate at least the possiblity of mapping to alternative carriers.
The question then is what is a communication failure, in the abstract -
alternatively, what are the properties that we demand of any carrier. Some
of the demandable characteristics of carriers (not that these are demanded,
but they could be)

a) messages (application and btp, requests and responses) are either
delivered correctly or not at all - they are not corrupted.

b) for at least some messages, if it is not delivered to the intended
recipient, the sender is informed

c) as b), but for all messages

d) for defined sets of messages from a particular sender to a particular
receiver (addressee), they are delivered in the order they were sent


I think we can assume a) for any plausible transport - it would apply to UDP
and email as well as a direct TCP connection or an HTTP(carried) message.
Checksums are somebody else's problem.

b) is a property of request-response carriers,  but only for requests - if
the request doesn't arrive, the respponse doesn't come back, and the failure
is reported in some way.  It is impossible (without a whole bunch of extra
messages) to avoid getting false reports of failures - if the response gets
lost, it will be indistinguishable from the losing the request, as perceived
by the original sender [ there is stuff about this in the literature, but be
careful it is answering the question you asked ]

c) can be done if our messages always go on something that does a re-reply
(e.g. if we always map even our responses to underlying requests (such as
HTTP POST), a loss of the carrier's response is detected and can be reported
as a possible loss of our own messsage)

d) applies to messages that are on the same underlying transport-layer
connection (for most likely transports)


I believe we want BTP to able to apply to scenarios where there are
scheduled and unscheduled interruptions to the running of the systems
involved, which implies they are capable of restoring their state and
carrying on the message exchanges of BTP.  This in turn implies they may
send some messages more than once, or at least that they may be received
more than once. So the state tables (and the state behaviour of the
implementations) have to be able to cope with receiving duplicate messages.


For failure purposes, should we demand that the carrier report an error
whenever a message has got lost (accepting that it will report such errors
in some cases where the message WAS delivered). Or apply this only to
requests which have a defined response (which is effectively what happens
with OTS over CORBA for example).

Peter

------------------------------------------
Peter Furniss
Technical Director, Choreology Ltd
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N 2JX