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.