In a WAN environment, neither Flex LCDS nor BlazeDS can guarantee that the messages you are sending are coming in the same order that they were sent. For gaming or trading applications, the consequences can be very serious.
What if your Buy and Modify requests come in the wrong order? How would you feel about placing the straight-up roulette bet at 20, then moving to 21 after the ball stops on 21? Actually, some sequencing mistakes can be beneficial for the gambler and some can cause substantial losses of money. But developers of such client/server communications must remain neutral and ensure that the bets are placed in the right order. Naturally, these things will not happen on the development local area network (LAN), but hey, people want to place bets while sitting in a small Internet café in a French village or from their laptops by the Tiki Bar in Miami Beach.
Maintaining the proper order of the client messages is done the same
way it’s done for server-born messages: quarantine received out-of-order
messages and let them out only when the missing number comes in. The
proper place to do this is the server-side custom endpoint:
SerializingRTMPEndpoint (see Example 5-34).
All classes involved in the solution are highlighted in Figure 5-12.
Figure 5-12. Classes involved in guaranteed and orderly delivery of the client-initiated messages
The logic implemented ...