The need for a broken line to reconnect

Especially on mobile phones, users’ socket connections may be disconnected due to network instability or other reasons. At this time, if you simply let the player quit the game and log in again, it will undoubtedly affect the user experience. Therefore, according to this requirement, there is a need for programs to realize the technology of automatic reconnection after disconnection, so that users can quickly start the game again and fight.

1. Principle of broken line reconnection

In fact, it is very simple, is in the disconnection, according to the user click (some short time do not need to click, the default is automatic reconnect), the program automatically identify, is to refresh to re-enter the game or to help the user automatically reconnect. The client automatically does things for the user based on the automatic reconnect flag. For example, automatic login, role selection, scene entry, request synchronization background data and so on.

According to the implementation mechanism, there are roughly two implementation methods. The main ones are auto-reconnection in game (without refresh) and auto-reconnection in game (without refresh). We’ll talk more about the two implementation mechanisms and the related pros and cons.

Ii. Automatic reconnection within the game (no refresh)

This is difficult because if you don’t refresh the game, the client data will be out of sync with the server data due to a period of disconnection from the game. Things like monster locations, bonuses, progress, etc. These need to be designed from the beginning, and if the plan requires this at the end, it’s almost impossible to do, it’s too much change. So let’s say it’s this many, it’s something like this. 1. The client and server agree that the data needs to be synchronized by the client. 2. How long can the disconnection be automatically reconnected (plan and technical implementation to evaluate each other) The server provides the protocol for automatic reconnection, and the user should not destroy the relevant data at the first time of disconnection (complicated here, such as whether the automatic battle should always hang on the server, and some other related operations) 4. Instead of refreshing the game, the client reconnects to the server using a new interface and automatically updates and synchronizes the corresponding data (such as synchronizing the positions of monsters or other characters, etc.).

This technique is usually used in turn-based games and generally does not involve combat systems. If arPG, only a short period of time can be automatically reconnected, otherwise the variable is too big. Or you might need to make some variations, such as a pure scene monster refresh, but a world boss scene would have to be reloaded or something special.

Three, refresh the game automatically reconnect

Personally, I find this simple, crude and practical. Most games are suitable for use, as long as a refresh, the game data is gone, all start again, the client only need to do some automatic operations according to the mark, much easier. At the same time, the server does not need to change, stable and not prone to error. The only downside is that the user experience will be slightly worse.

Reconnection data

String data:

// IP + user id + server ID + server name
var reload:string = ip + "#" + token + "#" + serverId + "#" +serverName;Copy the code

// The reload strings are all here

Reconnect mark:

reload  / / stringCopy the code

Note: Refresh only refreshes your own page. (e.g. in iframe)

Location.replace Resets URL reconnection

This is simpler and doesn’t have any compatibility issues. That is, when reconnecting, you record the previous login user and the server address by attaching parameters to the URL, and then you parse it out in the actual use, by determining if the properties are overloaded,

The replace() method of the Location object: replaces the current document with a new one. By passing in a new URL (actually the original URL + with reconnecting data)

location.replace(oldUrl + "reload#" + reload);Copy the code

Yes must go to the URL, and also need to be compatible with the original parameter processing. In a game game it might look like this:

http://localhost:63342/game/index.html? reload=1&host=ws:// 192.168.0.10:1050 / ws&token=soda1&serverId=1&Servername = local debuggingCopy the code
  1. document.cookie


    Cookies are variables stored on the visitor’s computer. This cookie is sent whenever the same computer requests a page through the browser. You can use JavaScript to create and retrieve cookie values.


    Using the local storage function of cookies is also convenient, but some mobile browsers may not be able to read them. 

document.cookie = "reload#" + reload;Copy the code
  1. Using HTML 5window.localStorage


    The localStorage property allows you to access a localStorage object. LocalStorage is similar to sessionStorage. The difference is that data stored in localStorage has no expiration time, whereas data stored in sessionStorage is purged when the browsing session ends, when the browser shuts down. It should be noted that the data stored in either localStorage or sessionStorage is limited to the protocol on that page.


Since it is H5 game, of course, the focus is to use this, first look at localStorage API


。 

window.localStorage.setItem("reload", reload);Copy the code

Read:

var reload = window.localStorage.getItem("reload");Copy the code
  1. Native saving with Egret is more convenient with Egret encapsulation, which is supported by both H5 and packaging locations. localStorage.ts
Egret. LocalStorage interface//Save the dataexport let getItem:(key:string)= >string;
//Delete the dataexport let removeItem:(key:string)= >void;
//Clear all dataexport let clear:(a)= >void;Copy the code

Web implementation class WebLocalStorage.ts

namespace egret.localStorage.web {
    function getItem(key:string):string {
        return window.localStorage.getItem(key);
    }
    function setItem(key:string, value:string):boolean {
        try{
            window.localStorage.setItem(key, value);
            return true;
        }
        catch(e){
            egret.$warn(1047, key, value);
            return false; }}function removeItem(key:string):void {
        window.localStorage.removeItem(key);
    }

    function clear(a):void {
        window.localStorage.clear();
    }

    localStorage.getItem = getItem;
    localStorage.setItem = setItem;
    localStorage.removeItem = removeItem;
    localStorage.clear = clear;
}Copy the code

You can see that the internal implementation is window.localStorage, while doing a process, and finally the localStorage interface is assigned to the external call. Here’s how to use it in practice:

// Use the native egret storage method for egreT.localStorage.setItem("reload",reload);Copy the code

// Game fetch

var reload:string = egret.localStorage.getItem("reload");Copy the code

4. Reconnection mechanism is dealt with in actual projects

The code here is to refresh and re-enter the game, and then parse the data from the previous data (URL or local cache) to determine.

Parsing the url

var reload:string = location.href;Copy the code

Local cache retrieves data

var reload:string = egret.localStorage.getItem("reload");
console.info("Reload data." + reload);if(reload && reload ! ="")
{
    var cooks:string[] = reload.split("#");

    console.info("Disconnecting and reconnecting to refresh.");
    this.session.isReload = true;
    this.session.host = cooks[0];
    this.session.token = cooks[1];
    this.session.serverId = Number(cooks[2]);
    this.session.serverName = cooks[3];
}Copy the code

Use in-game variables for judgment processing

if(this.session.isReload)
{
    // Start automatic reconnection, walk extra protocol and automatic processing
}
else
{
    // Follow the normal process
}Copy the code

Final conclusion

Here is mainly about some ideas and the application of the actual project. The code is pseudo 5 code, readers should design according to their own project actual situation, make some corresponding changes, the principle is the same.

We encountered one of these problems in a project, because we did not consider the problem of automatic reconnection at the beginning, neither on the client side nor on the server. So there was no way to reconnect without refreshing the game (mainly because it was too expensive, and it was an ARPG game), and the mechanic of refreshing the game itself was chosen. Of course, there will be some pitfalls, such as access to some platforms, can only refresh their OWN HTML, not refresh the platform HTML (game embedded), resulting in platform SDK issues (affect recharge, attention, etc.). But in the end, it was resolved through workarounds and the like.