9.5 Reliable Transaction Pattern

Real-time systems use communication protocols to send and receive critical information, both among internal processors, and with external actors in the environment. Within the same system, different messages may have different levels of criticality and so may have different requirements for the reliability of message transfer. Further, different media have different reliability, as do different environments.

The transaction is used when communication reliability is required over unreliable media or when extraordinary reliability is required. For example, suppose the system needs three distinct levels of communications reliability:

• At Most Once (AMO): A message is transmitted only once. If the message is lost or corrupted, it is lost. This is used when lightweight transfer is required and the reliability of message transfer is high compared to the probability of message loss.

• At Least Once (ALO): A message is transmitted repeatedly until either an explicit acknowledgement is received by the sender or a maximum retry count is exceeded. This is used when the reliability of message transfer is relatively low compared to the probability of message loss, but receipt of the same message multiple times is OK.

• Exactly Once (EO): A message is treated as an ALO transaction except that, should a message be received more than once due to retries, only the first message instance will be acted on. This is used when message transfer reliability is relatively low but it is important that a message is acted on only once. Increment or toggle messages, for example, must only be acted on once.

9.5.1 Abstract

The transaction pattern is particularly suited to real-time systems that use a general communication protocol with a rich grammar when different levels of reliability of message transfer are required. It allows the application designers flexibility in their choice of communications method so that they may optimize for speed or reliability.

9.5.2 Problem

The basic problem addressed by this pattern is to support three levels of reliability in the transmission of messages over unreliable communications media.

9.5.3 Pattern Structure

Figure 9-6 shows the structure of the reliable transaction pattern. Ultimately, the sender wants to send a message to the receiver these are object roles played by instances of the class CommunicatingObject. This is mediated by CommStack, which represents a protocol stack. Notice that in the usual case, there are two instances of CommStack for any given message, one is mediating the sending of the message and the other is mediating the reception of the message. The sender and receiver roles are usually connected to different instances of the CommStack class. Each CommStack may, at any time, be sending and receiving dozens or hundreds of messages. Each message may, if at the appropriate level of reliability, be associated with a SendTransaction instance (for ALO and EO protocols) and a ReceiveTransaction instance (for EO protocol).

Figure 9-6. Transaction Pattern

The important classes in the pattern are the SendTransaction and the ReceiveTransaction instances, as they actually mediate the reliable delivery of the messages. Their statecharts are shown in Figure 9-7.

Figure 9-7a. Sender Transaction Statechart

Figure 9-7b. Receiver Transaction Statechart

The AMO semantics are the simplest to implement because no transaction objects are required. The reliability of the communications medium and protocol are sufficiently high, and the consequences of a lost message are sufficiently low, so that no extra measures are needed. Transferring messages using AMO semantics is fast and requires the fewest computation resources.

ALO semantics require that the sending CommStack maintain a transaction object until an explicit acknowledgment is received back from the receiver. If an acknowledgment is received, the transaction object is destroyed. If no acknowledgment is received within the retry period, then the SendTransaction automatically retransmits the message to the receiving CommStack. If the SendTransaction fails to successfully get the message to the receiver (i.e., the MaxRetries count is exceeded), the message originator is notified so that corrective measures can be initiated.

The sending CommunicatingObject cannot distinguish between a loss of the message and a loss of the acknowledgement, so the Receiver object may receive the message more than once. This is normally not a problem for operations like set() when setting an absolute value, but it becomes problematic when the operation is something like increment(). ALO semantics are incompatible with incremental operations.

EO semantics require transaction objects on both sides. The objects on the sending side function exactly as they do to support ALO semantics. What is different is that the receiving CommStack object must now create a ReceiveTransaction. When the receiving CommStack receives a message with an EO transaction type, it creates a ReceiveTransaction object and sets its timeToLive and msgID attributes. The timeToLive attribute is used for a timeout; once this timeout occurs, the ReceiveTransaction object is destroyed. If a duplicate message is received before that occurs, the receiving CommStack sends an evReceive event to the ReceiveTransaction, causing it to reenter the waiting state, restarting its timeout period from zero.

9.5.4 Collaboration Roles

The following objects participate in this pattern.

• ACK: An ACK is a kind of ControlMessage, sent back to the sending CommStack when a message is received by a target CommStack and it has passed whatever integrity tests the protocol defines, such as checksum or CRC.

• CommunicatingObject: A CommunicatingObject knows how to create messages and how to invoke the CommStack::send() service. It can also receive messages from the CommStack.

• CommStack: The CommStack object manages the sending of messages, creating instances of SendTransaction as necessary, and the reception of messages and their delivery to the target objects, creating ReceiveTransaction objects as necessary. When sending, the CommStack object creates a SendTransaction instance to mediate the reliable delivery of the message only for ALO and EO reliabilities. AMO can be sent (and immediately forgotten) without using a SendTransaction. The CommStack creates a ReceiveTransaction only when it receives a message with the EO reliability; messages received with AMO or ALO reliabilities do not require a ReceiveTransaction.

• ControlMessage: A ControlMessage assists in the delivery of other messages. An ACK, or acknowledgement message, is one of these. ControlMessages are never delivered "reliably" that is, they are always transmitted with the AMO level of reliability.

• Message: The Message contains the data of interest to the Source and Target, as well as metadata,^[4] such as a MsgID and Transaction Type. The MsgID must be unique within the lifespan of the transaction object so that it uniquely identifies the message. The Transaction Type tells the Sender and Receiver whether or not transaction objects are required for this message.

  ^[4] Metadata is information about information; for example, a field that tells the size of a message can be considered metadata.

• ReceiveTransaction: This object tracks the receipt of messages using EO semantics. It is created when the Receiver gets a message with the EO transaction type. The purpose of the ReceiverTransaction is to discard extra copies of a received message, which can occur if ACK responses to an ALO or EO message are lost. The statechart for this class is shown in . Note that the timeToLive timeout transition is retriggered (restarts from zero) each time an evReceive event is received from the local CommStack in response to receiving a message with the proper msgID. When no evReceive event has occurred for the timeToLive period, the ReceiveTransaction is destroyed.

• SendTransaction: This is the transaction created (and destroyed) by the CommStack in the sendingStack role. Each transaction corresponds to a single ALO or EO message. It tracks the number of times the message has been transmitted as well as its retry period. If an acknowledgement specifying the original MsgID is not received within the retry period, the message is retransmitted and the transmit count is incremented. If the count exceeds maxRetries, the originating CommunicatingObject source is notified.

9.5.5 Consequences

The reliable transaction pattern simplifies the delivery of messages with three distinct levels of reliability: AMO, ALO, and EO. This is particularly true when many messages may be in transit at any given time, such as when peer-to-peer communications are occurring across a multimastered bus. In a master-slave communications environment, in which a master is in charge of initiating and managing all communications, this pattern is overly complex. The pattern as it is can handle any number of simultaneously active messages.

9.5.6 Implementation Strategies

The implementation of these classes is straightforward. The CommStack is highly protocol specific, of course, but the SendTransaction and ReceiveTransaction objects have simple statecharts.

9.5.7 Sample Model

Figure 9-8a shows the structure of a simple example. In a medical device, the AnesthesiaControl is remote from the Vaporizer. It needs to send an Increment Dose command to the Vaporizer. Because an "increment" style command is one that should be sent with EO semantics, it creates the message with the transactionType attribute set to EO. It adds the source objectID (99) and the target object (54) as needed by the message. Since the CommunicatingObjects don't have anything to do with the actual message transmission, it leaves the msgID attribute of the Message blank for the CommStack to fill in. Because the EO semantics demand both a SendTransaction and a ReceiveTransaction, those are part of the class diagram.

Figure 9-8a. Reliable Transaction Example Structure

Figure 9-8b shows a scenario for sending the Increment Dose message. In this scenario, the returning ACK is lost (indicated by the X) so the sending transaction, not knowing whether the original message or the responding ACK was lost, must retransmit after its timeout. The receiving side, meanwhile, has received the message and forwarded it on to the Vaporizer. It has also created a ReceiveTransaction, which waits and receives (and discards) the second command, before eventually timing out and being destroyed.

Figure 9-8b. Reliable Transaction Example Scenario