[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Properties of carrier protocols
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC