Testing applications for real world

RIA applications are extremely susceptible to network problem. Even small probability of the lost/misdelivered packages, becomes significan when multiplied by the sheer amount of the small packages. Lost/duplicate/reordered packages and high latency/low bandwidth cause significant issues for applications fully tested on 100% reliable intranets and then released in the wild of unreliable WAN communications.

For the last 2 years we have been using different linux boxes (VMs and physical ones) to simulate different WAN problems. The setup process is tedious, and has limited resolution as most of the linux kernels are working on 100/250Hz. Fortunately, finally there is a product that solves most of setup problems with simple portable appliance that has to be in the toolbox of any Web 2.0 professional.

Mini Maxwell – Easy to Use, Portable, Network Emulator

Bringing latency up to realistic 200ms and package loss to unrealistic 10% would quickly expose problems in error handling code. It will also give you quick feel for robustness of the code. Next to check if duplicate/out-of-sequence packages affect the application. Financial applications also need to check for effect of corrupted data.

Depending on the protocols used by application, different remedies are available. Obviously, if you are using WebServices and similar old high-level protocols you have very loosely bound communications making implementation of QoS layer impossible. As number of HTTPRequests is limited by browser (2 for IE), latency can cause performances slowdown and timeouts. Missing packages escalate the issue with connection startving even further.

If you are using any AMF implementation, your case improves significantly. First, latency is less of a problem as Flex would automatically batch the requests together. Implementing symmetrical checkpoints on both client and server endpoints allows trivial package recovery in case of loss and duplicates. Nevertheless, lost packages are still a problem as they cause timeouts.

Robustness gets much better if you move to connected protocols – either RTMP or new BlazeDS long pull. Usually you can service anywhere between 80% to 100% of the users with them. Using opened connections and 2 way sockets is ideal for high performance and reliable protocols. Comparing them to HTTPRequests is like comparing highway with multiple lines going in each directions to single-line road. More applications started using connected solutions for tasks different from regular RPC to modules loading implementing streaming the same way you stream movies. As they evolve, we should see more open source products that provide transparent implementations using mixture of protocols. In meanwhile, we can do most of it using Flex built-in fallback channels.

Hope this helps,

Anatole