Rethinking app design with "8 Myths of Distributed Systems"

As a mobile and web developer, there are plenty of out-of-the-box Web development code that can be used directly in development. Unfortunately, there is no set of code to take the place of our overall consideration of network unreliability, especially on mobile devices. Fortunately, there are some well-known conclusions and some famous patterns that can help us think about how to gracefully handle real-world problems. Next, let's consider the famous "8 great fallacies of distributed systems" and how we can avoid them.

The following is the famous "8 major fallacy of distributed systems"
1, the network is reliable;
2, the network does not exist time delay;
3, the network bandwidth is unlimited;
4, the network is safe;
5, the network topology structure is not changed;
6, only one administrator;
7, the network transmission is not required any cost;
8, the network is isomorphic.

Fallacy 1: The network is reliable;
However the fact is:
1, your network suddenly can not work in a certain period of time;
2, the device can be connected to the network, but the request is not data;
3, the device constantly sends duplicate data because the request is not answered, so your server will receive duplicate requests;
4, the device or server received dirty data or partial data;
5, the host can not be used;

How do we deal with it?

-Your app will save the request in the queue and can automatically retry sending the request.
continuously asynchronously acquires the network availability of the device by using Apple's reachability class (or directly using the underlying scnetworkreachability interface), but also needs to understand the drawbacks of invoking the API. First, the broken host may not be able to connect, it does not require multiple attempts, and on the other hand, a connected host may fail to receive or answer the request. In addition, it will take some time for the device to establish a network link so that it takes a while to determine if the network connection is available.
I find it very necessary to save a network request in a queue. When the network is unreachable, I can populate the queue with the request first. Or, try connecting again when the connection fails. Finally, these requests are removed from the queue when they are no longer valid, or if the request does not appear to have the possibility of succeeding. Of course, the policies that govern this queue depend on the business needs of the app and the nature of the request. For example, if the purpose of a request is to synchronize data, it is not worth trying multiple times. A request to save the user's data to the server must be successful, even if the app is restarted to recreate the request.

-The server can disconnect the request and can consider repeating the request.
The vast majority of my application's network requests are based on HTTP or HTTP-like protocols at least, so the server must take into account the problems caused by unreliable networks.
When mobile phones switch between different base stations, or people walk through tunnels with their mobile phones, and consider that the phones are surrounded by high-rise buildings, the phone is actually losing the mobile network, and then trying to reconnect to the mobile network. The Web Kit and Nsurl tool classes can easily handle these anomalies, but the server side is faced with a lot of long links and only waiting for the timeout mechanism to break the links. If the link to some of the requests is coincidental to occupy important system resources, then the server cannot process more requests, even if the bandwidth is very good.
At the same time, the app will automatically resend these requests without a successful reply. In fact, sometimes the server really sent a response, but for some reason did not reach the mobile phone, this time the server will receive a number of a touch of the same request. If the server cannot tell if this is a retry request, or if a user has actually made multiple requests, it can cause a lot of trouble for our system. This can be done by adding a serial number, a timestamp, or some sort of indication to the request.
When UIWebView is loading the content, I will consider showing the content first when the resource is not loaded. Should I load the content before loading the pictures or other resources? Or does it say that the progress bar is displayed until all the pages have been loaded?

-Gracefully Handle the case of intermittent network or disconnection.
Finally, you need to consider how to present the page in the event of a network exception when developing the app. I don't know. Every time the network is out of the question, a dialog box pops up. And I'm definitely not going to pop a bunch of cue boxes when a series of network errors occur. I will try to tell the user that the app is processing the request, and if a problem occurs, the user can continue until the request is complete.
In practice, the phone can not simply get or push the request, but to synchronize the network situation, when the view of a sending request is closed, but also to record the request and response. When the request is still in transit, the user's continued operation cannot be prevented.

-Test: How to create a non-reliable network
While developing and debugging, the network in the development environment always seems to be reliable, but that is not the case. I use Charles to simulate a bad network environment on my local WiFi network when I do manual testing or a bug replay. In the agent down breakpoint, you can have the choice of interrupt request, at any time interrupt network connection.

The English text is here, tomorrow continue to translate the next chapter: http://blog.carbonfive.com/2010/11/17/fallacy-1-the-network-is-reliabl/

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Rethinking app design with "8 Myths of Distributed Systems"