Resending Channel Guarantees Delivery

The next customization goes to the client’s channel. It has to monitor the server’s acknowledgments for each message, and if they are not received in a timely fashion, it must resend the messages. Does this idea sound familiar? The naming convention of the channel also will follow the same pattern as in the server-side adapters and be called ResendingRTMPChannel.

This custom channel maintains a Dictionary based on the unique messageId of the unconfirmed message records:

private  var unconfirmed:Dictionary ;

Every incoming message stays in this dictionary until acknowledged by the server. If the duration of the stay is longer than a specified timeout, the channel resends the message. The process is spiced up by the fact that the channel is shared by all the client’s producers, and during the resend, we need to know which producer has to resend. That is why unconfirmed stores the reference to the producer’s base class, MessageAgent, along with the message itself; the unconfirmed messages that arrived from different clients will be represented by different instances of MessageAgent:

override public function send(
   agent: MessageAgent, message:IMessage
) : void {

  if (message is ReliableClientMessage) {
    unconfirmed[ message.messageId] = {
       message:message,
      registeredTs: new Date().valueOf(),
      agent:agent
    };
  ...
}

To intercept the server’s acknowledgment in the Flex application, you can listen to MessageAckEvent.ACKNOWLEDGE. To intercept the acknowledgment ...

Get Agile Enterprise Application Development with Flex now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.