How to implement a multi-terminal bridging platform based on websocket in JS

1. What to debug

We mainly need to know what to debug and what the final result will be:

1. Debug the interface, enter the interface address, and get the corresponding result; and you can debug multiple devices at the same time;

2. Debug jsapi and enter the corresponding method, then the effect can be displayed in the news client.

In terms of the debugging interface, we actually have a way to debug easily, but there are two restrictions: Android system and beta client, so bridge through the Chrome browser. However, this method is ineffective in iOS system and official version of the client.

2. Features of websocket

The biggest feature of the WebSocket protocol is that the server can actively push information to the client, and the client can also actively send information to the server. It is a true two-way equal dialogue and a type of server push technology.

Other features include:

1. Built on the TCP protocol, the server-side implementation is relatively easy.

2. Good compatibility with HTTP protocol. The default ports are also 80 and 443, and the HTTP protocol is used during the handshake phase, so it is not easy to be blocked during the handshake and can pass through various HTTP proxy servers.

3. The data format is relatively lightweight, with low performance overhead and efficient communication.

4. Both text and binary data can be sent.

5. There is no same-origin restriction, the client can communicate with any server.

6. The protocol identifier is ws (or wss if encrypted), and the server URL is the URL.

3. Establish a socket connection

To meet the debugging goals we set in Part 1, the functions we need to implement here are:

1. The PC is equivalent to the room owner. After the room is created, other devices can enter the room. One device can only enter one room.

2. The client has a disconnection reconnection mechanism. When the client is disconnected, you can try to reconnect;

3. The server maintains a heartbeat detection mechanism. When a new device enters or a previous device exits, the device list in the current room should be updated in a timely manner;

3.1 How to create a room

Enter the room ID on the browser. If the browser successfully establishes a websocket connection with the server, a corresponding QR code will be created on the browser. Scan with WeChat/Mobile QQ or other devices that scan QR codes, and you can jump to the corresponding debugging page in the news client through the pre-set scheme protocol.

If the client successfully establishes a websocket connection with the server, it is equivalent to entering the room successfully, and a corresponding icon will appear on the PC.

ws.open(serverId)
    .then(() => {
        // After the PC successfully establishes a connection setStatus("linked"); // Update the status of the page // Generate a QR code qrcode(`/tools/index.html#/newslist?serverId=${serverId}`).then(url => {
            setCodeUrl(url);
        });
    })
    .catch(e => {
        // Failed to establish connection console.error(e);
        Modal.error({ title: "There is a problem with the current server and it is being repaired" });
        setStatus("unlink");
    });

3.2 Client disconnection recurrence mechanism

There is a feature of the page on the mobile terminal. When the screen goes black or for other reasons, the client will automatically disconnect the socket connection.

In order to facilitate debugging, you don't need to click manually or re-enter the page every time after disconnecting. I implemented a simple disconnection and reconnection mechanism here. When the websocket connection is disconnected, the onclose callback will be executed. Therefore, we can implement a reconnection mechanism in the onclose event.

At the same time, in order to prevent unlimited reconnection attempts, I have also set a limit here. The maximum number of reconnections is 3. If the connection is not reconnected after 3 times, the connection will be stopped; if the reconnection is successful, the number of reconnections will be reset to 3.

When disconnecting:

// When disconnecting ws.onclose(() => {
    timer = setTimeout(() => {
        setStatus("unlink");
        setCodeUrl("");
    }, 500);

    reconnectNum--;
    // Limit the number of reconnections if (reconnectNum >= 0) {
        _open(); //Try to reconnect}
});

When the connection is successful:

ws.open(serverId).then(() => {
    // After the PC successfully establishes a connection + reconnectNum = 3;
    +timer && clearTimeout(timer);

    setStatus("linked"); // Update the status of the page // Generate a QR code qrcode(`/tools/index.html#/newslist?serverId=${serverId}`).then(url => {
        setCodeUrl(url);
    });
});

3.3 Heartbeat Detection

Just like when we chat in a QQ group, it is clear at a glance who is online. If someone enters the chat group or someone leaves, the host must be notified and the group list must be updated in a timely manner.

There are two main types of heartbeat detection: heartbeat detection initiated by the client and heartbeat detection maintained by the server. Let’s take a look at these two types:

1. Heartbeat initiated by the client: At fixed intervals, a ping data is sent to the server. Under normal circumstances, the server will return a pong to the client. If the client can monitor it through the onmessage event, it means that the request is normal.

2. Heartbeat maintained by the server: Check the status of all connections at regular intervals. If the status is disconnected, remove it from the list.

Here I use the heartbeat detection maintained by the server. When the number of devices in the room changes, the server pushes the latest device list to the client:

//Continuously monitor the client's connection status //If the connection is disconnected, clear the client let aliveClients = new Map();
let lastAliveLength = new Map();
setInterval(() => {
    let clients = {};
    wss.clients.forEach(function each(ws) {
        if (ws.isAlive === false) {
            return ws.terminate();
        }
        const serverId = ws.serverId;
        if (clients[serverId]) {
            clients[serverId].push(ws);
        } else {
            clients[serverId] = [ws];
        }

        ws.isAlive = false;
        ws.ping(() => {});
    });
    for (let serverId in clients) {
        aliveClients.set(serverId, clients[serverId]);
        const length = clients[serverId].length;

        // If the number of devices connected to the current serverId changes, send a message if (length !== lastAliveLength.get(serverId)) {
            // Send messages to all devices with the current serverId sendAll("devices", clients[serverId], serverId);

            //Store the last connection count of the current serverId lastAliveLength.set(serverId, length);
        }
    }

    const size = wss.clients.size;

    console.log("connection num: ", size, new Date().toTimeString());
}, 2000);

4. Debug the interface

We have successfully connected the PC and the news client in Section 3, so how do we communicate data between the two ends?

4.1 Interface Debugging

We are passing in 3 fields here:

1.serverId: the room number. The server needs to broadcast the information to all members with serverId;

2.type: type, what this instruction is going to do;

3.msg: the incoming parameters;

During interface debugging, the parameters passed in are:

const params = {
    type: "post", // type msg: {
        // Parameter url: "https://api.prize.qq.com/v1/newsapp/answer/share/oneQ?qID=506336"
    }
};

When the client completes the interface request normally, the interface result, cookie and device information are returned to the PC:

// Request method const post = url => {
    if (window.TencentNews && window.TencentNews.post) {
        window.TencentNews.post(url, {}, window[id], { loginType: "qqorweixin" }, {});
    } else if (window.TencentNews && window.TencentNews.postData) {
        window.TencentNews.postData(url, '{"a":"b"}', id, "requestErrorCallback");
    }
};

// Data sent from the mobile terminal to the server ws.send({
    type: "postCb", // Execution result msg: {
        method: "post",
        result,
        cookie: document.cookie,
        appInfo
    }
});

In this way, the results can be displayed on the front end, and it is a real data request.

4.2 Storage of historical records

In terms of historical records, our classmates around us still have a very urgent need for it during the trial process. Otherwise, every time you want to test the previous interface address, you need to re-enter or paste it, which is very inconvenient.

We store relatively complete information such as the URL requested by the user, the returned results, cookies, device information, etc. in the boss, and only store historical URLs locally. When the user needs to test the previous interface again, just click it. If you need to view the previously debugged interface, you can check it on Hawkeye.

Local storage is done using localStorage. More importantly, we also use mobx's responsive tools, so that we can see the results in the history log on the side immediately after the user completes the request.

5. Debugging jsapi in news client

In addition to debugging interfaces, you can also debug jsapi in some news clients. There are two ways to call the jsapi of our news client:

// Directly call window.TencentNews.login("qqorweixin", isLogined => console.log(isLogined));

// Invoke window.TencentNews.invoke("login", "qqorweixin", isLogined => console.log(isLogined));

Here I chose to use the invoke method to call jsapi.

The PC initiates a jsapi call:

ws.send({
    type: "call",
    msg: {
        method: method,
        params: slice.call(arguments)
    }
});

After receiving the request from the server, the mobile terminal calls the jsapi and returns the execution result to the PC terminal:

const handleNewsApi = async (msg: any): Promise<any> => {
    await tencentReady();

    const { method, params } = msg;
    return new Promise(resolve => {
        window.TencentNews.invoke(method, ...params, (result: any) => {
            resolve({ method, result });
        });
    });
};

6. Conclusion

At this point, my "multi-terminal bridging platform based on websocket" has basically been built. However, there are still two issues that need to be briefly explained.

6.1 Why do I need to enter the serverId manually?

At first, I thought that when the user creates a room, the system will randomly generate a uuid, but then I thought that if the user refreshes the page, the uuid will change, making it impossible to connect to the previous uuid, so I switched to manual input here.

6.2 How to ensure that all socket requests from a client enter the same process

When we use multiple processes in the background, if we do not intervene in the user's request, it will cause random access to the request and generate 400 requests. After all, the initial connection is in process A, and now the request is sent to process B, and process B does not know how to handle it.

There are multiple ways to handle this:

The platform I use here is an internal debugging platform. The number of users is not large, so there is no need to use a sledgehammer to crack a nut. Moreover, we only have one machine, so we consider the same IP entering the same process. Here I borrow the ip_hash idea from nginx: when the request comes to the main process, I perform weighted calculation on the IP and then take the modulus according to the number of processes.

Obviously, this method may also have the problem of too many socket connections in a process, but it is completely acceptable when the number of users is not large (I have also considered other methods for this problem, such as the waterfall flow method. Each time a connection is assigned to a child process, the process with the least number of connections is first obtained, and then the connection is assigned to this process. However, a table must be maintained and calculated each time).

6.3 Communication between multiple processes

In the same room, when the socket connection on the PC side and the connections on multiple mobile terminals are not in the same process, there will be a cross-process problem. As an extreme example, each socket connection is in a different process, so we need to consider how to notify other processes that a request needs to be sent to the client.

A relatively simple way to use our mechanism is that each PC user is the host and can create a room. Mobile devices are members of the room. Each room is independent and does not interfere with each other. In this way, we put all the socket connections in the room into the same process through the room identifier, so there will be no cross-process problems. But one problem with this approach is that when there are too many connections in a room, the same process is required to handle them all, while other processes are idle.

You can also use redis: use the publish/subscribe mode of redis to broadcast the room ID and information in the current process to other processes. Other processes have socket connections with the same room ID and perform corresponding operations.

The above is the details of how JS implements a multi-terminal bridging platform based on websocket. For more information about JS's multi-terminal bridging platform based on websocket, please pay attention to other related articles on 123WORDPRESS.COM!