Web cross-browser Process Communication (Web cross-origin) _ javascript skills

Web cross-origin is a common topic. This time, we tried communication between cross-origin browser processes. In the past, we tried cross-browser data sharing based on network transfer, finally, we mentioned the feasibility of using LocalConnection to achieve cross-browser message interaction.

It took two nights to make a brief research. LocalConnection's one-way communication is very simple. However, to realize interaction between multiple terminals, you must implement a messaging mechanism by yourself.

For simple demonstration, this example uses the broadcast-based observer mode: each terminal can subscribe to topics of interest, or send messages to broadcast to notify other terminals of interest.

Demo: http://www.etherdream.com/FunnyScript/WebIPC/ (open a few more browser page window, you can test)

　　Unfortunately, the latest Chrome browser still cannot interact with other browser processes :(

If no error occurs, it should be as follows:

Operations on any page are immediately synchronized to other pages, as long as the topics of interest are Observe.

Why should we use the observer mode? Because cross-process communication is resource-consuming, messages that are not interested can be directly not subscribed, rather than discarded.

LocalConnection is designed for a single communication. Although it is easy to use, there are few available interfaces. There is no portal to broadcast events or message routing directly.

Therefore, there is not much room for sending messages at the underlying layer, so it can only be simple point-to-point transmission. We must create multiple localconnections for message aggregation and distribution.

LocalConnection can only be used in two ways:

　　　　Connect (name) -- create an MPS Queue (only one MPs queue can be created for each LocalConnection, and only one MPs queue can be created for each LocalConnection)

Send (name,...) -- send data to the MPs queue

If there are only two terminals for communication, everything is so simple...

　　

Simply send the message to the other party.

However, there are multiple terminals, which are quite different. Because we communicate between local processes and are not hosted by a third-party server, and LocalConnection can only send messages point to point. This means that each broadcast must be sent to all other terminals, which greatly increases the complexity.

To simplify the structure, we simulate a LocalConnection as the Host and run it at the first startup. The rest are submitted to the Host for scheduling every broadcast message as the Client.

　　

Host maintains a callback list. When the Client (Subject) When you are interested, you can send <主题id，自己的管道名> Subscribe to the Host. The Host adds the MPs queue name of the Client to the callback list of the topic. If a message of this topic is available in the future, the subscribed Client can be notified Based on the callback list.

To make it easier for the Host to communicate with the Client, useChannel + IDTo create the MPs queue name.

The Host ID is empty, so the Client only needs to send (channel) data;

The Client ID ranges from 1 ~ 100. Select an unused pipe name. When the Host callback is performed, you only need to send (channel + id) to notify the corresponding Client.

However, this Host service is just an illusion. We simply cannot run a third-party service outside the page. Everything can only be done on the page! So we use the page that we started for the first time as the Host. When this page is closed, we will notify the second page to create a Host, and so on...

　　

Since there is no third-party server, each Client can work as a Host on a part-time basis. So far, Do you think of LAN games? Since there is no server, the first player created is the host. When he exits, the host is handed over to the second player. If he does not follow the normal steps to force the game to exit, the host may be lost, and the data may not be transferred to the next player, resulting in the game disconnection.

Similarly, when the Host page is closed, an exit message is sent to all clients. As for who inherits the throne, don't worry. Who knows who will do it first ~~ The only thing worth noting is that many browsers cannot trigger windows normally. the unload event. In this case, the Host may not have handed over the callback list to his successor, so the Host may have left in a hurry, so future generations will not be able to take over.In order not to let this happen, every time a new Host takes over, a request is sent to all clients, asking everyone to resend their respective topics of interest (the previous topics are saved, for this purpose). Therefore, even if the new Host has nothing, everyone will tell him the status quo and can immediately put into work.

If the page process of the Host is forcibly disabled, everything will be suspended after the Host is lost. At this time, all the data sent by the Client will be rejected, and only after the data fails to be sent Will the Host be suspended. In this case, whoever finds this error will take over the Host.

Of course, you can also consider adding the heartbeat mechanism. Even if the Host is not suspended, but the process in which it is located occupies the CPU for a long time, so that LocalConnection cannot respond to message events, you can also consider transferring the Host.

Due to time constraints, there are still many bugs in this example, which will be improved later.

To see the code can browse: http://code.google.com/p/webipc/source/browse/

In fact, pure local communication is of little significance. It is more meaningful only when it is used with remote services for message interaction. For example, if a user opens multiple Weibo pages, the traditional model must initiate a persistent connection for each page to maintain real-time data reception. If you use cross-browser communication, you only need to have the Host initiate a connection. The other clients subscribe to the desired topic, and eventually only need one connection.