Several problems of socket under mobile platform

In the era of page travel, developed using Flash ActionScript 3.0, AS3 provides a relatively simple and robust socket API. In the era of hand-travel, TCP-based socket programming has encountered some difficult problems. Usually, you have to support at least two major platforms: Android, IOS, and they coexist, and there is no sign of which side will fall.

Page tour running in the browser, all the connection success, failure and other operations, can be monitored through the addeventlistener, very convenient, and generally there is no frequent loss of the situation. And the hand travel, because the mobile phone's portability determines its mobility, since it is movable, it will certainly face the network instability situation.

Client-server communication if the use of TCP logic is simpler, but there are some problems, the problem is exposed under the mobile platform is more obvious. QQ client uses UDP instead of TCP, the main reason is because of network instability. What is the main difference between TCP and UDP? is actually the difference between a long connection and a short connection

Long connections are more resource-intensive, but usually the other side is broken, the other party will be more timely to receive the message, the business logic is relatively simple and timely.

TCP-based socket network programming, if you want to cross-platform, usually use C/s-a encapsulation, so that the code level is at least unified. But the main problem with mobile devices is frequent drop-off, Android is better, iOS is actually more troublesome. Below is a list of the effects on the network of Home and Power keys on Android, iOS devices:

Platform	Home key after cut (network status)	Power key (Network status)
Android	Y	Y
Ios	Y	N

Switching between the other 2g/3g/4g/wifi is also cumbersome and must be re-connected (because the client's IP has changed).

When the power button is pressed, iOS will lock the screen. The socket is broken, but the server side does not receive the client drop line. The problem is, not that TCP is a long connection, I fell off the other end should receive the disconnection of the message ah, well, theoretically, the agreement is the same, but first notice such a problem:

The TCP connection uses a three-time handshake

TCP disconnects using four-time handshake

Connection using three times handshake, this is not much to say, the main reason is to ensure that the two ends can confirm that the connection has been established (SYN, ACK). And why is the disconnection four times? Because the socket is duplex (bidirectional communication), the equivalent of two lines of communication, one for receiving, and one for sending. When one side actively shuts down (the write channel is turned off, but at this point the Read channel is still normal), it sends Fin, the other end receives a response to fin+1 (indicating I received your closing request), and then the other end processes its own logic, and then tells the party that the request was closed, I agreed to your closing request (no more data to send to you), at which point the Read channel of the party that initiated the shutdown was normally closed. The party initiating the request shuts down the port it occupies (the connection record is not cleared at this time) after 2MSL (twice times Maximum Segment Lifetime of the maximum message life cycle).

So, you will find Wow, the original closure is also need to confirm. Assuming the server suddenly loses power, the client does not know that the server side has been unable to connect, but also that the data can be sent to the server side. Usually the heartbeat packet is used to detect whether the connection between the two parties is still present.

I have tried to use LIBUV for network communication in COCOS2DX, and it is really cumbersome to write asynchronously. The LIBUV uses the async callback notation, and all callback functions must be static. Usually a game is a two socket long connection: The main game logic, chat server, fortunately LIBUV support callback parameters "entrainment custom Parameters", but also not much of a problem. But I met a wonderful thing is that in the Samsung GTI9000 Android 2.3.6 System, the game into the background, the network status from 2G to WiFi, do not call back to the socket, after the invocation has not triggered the shutdown callback method, the other can be borrowed from the Android device has been tested , there's no problem. WiFi cut to 2g/3g, the background switch to the foreground immediately after triggering the shutdown callback function.

Back-end processing is the case, the establishment of a socket will randomly generate a key string, when the client disconnects, take this key string to the server for authentication, but the server authentication has a special decision, if the request to generate a keychain client IP and the reconnection client IP inconsistent, it is considered an illegal request. That is, 2G switch to WiFi, the IP has changed, the server is actually directly disconnect the connection, but why did not trigger the shutdown callback function, this may be the version of the Android system bug it

Then there are two ways to think about it:

1, for the Android platform, record the network type when connected, and then switch to the foreground and then get the network type, if found two times the network type inconsistent prompts need to re-login to the game;

2, the record to establish the connection when the IP address, when switching to the foreground to obtain the IP, if the two IP is not, also think that it is necessary to re-login game, because no matter what you take any key string will no longer login game, the server considers the request is illegal;

Several problems of socket under mobile platform