Web cross-browser process communication (Web Cross-domain) _javascript Tips

In a previous article, you tried Cross-browser data sharing, and finally mentioned that using LocalConnection also enables Cross-browser message interaction.

It took two nights. A brief study of the localconnection of one-way communication is very simple, but to achieve multiple terminal interaction, you must implement a set of message mechanism, see wisdom see benevolence.

For a simple demonstration, this example uses a broadcast-based Observer pattern: Each terminal can subscribe to topics of interest to it, or it can send messages to the broadcast, notifying other interested terminals.

demo:http://www.etherdream.com/funnyscript/webipc/(open a few more browser page Small window, you can test)

　　Unfortunately, the latest version of Chrome browsers still cannot interact with other browser processes:

If no errors occur, it should be the following:

The actions on any one page are immediately synchronized to other pages, as long as observe the topic of interest.

Why use the Observer model? Because communication across processes is more resource-intensive, messages that are not of interest can be subscribed directly, rather than received and discarded.

LocalConnection is designed for a single communication, and although it is simple to use, there are few interfaces available. Want to use it directly to broadcast events, or message routing, the door is not.

So there is not much to choose from on the bottom of the message, only a simple point-to-point send. We have to create multiple localconnection to implement the aggregation and distribution of messages.

There are only two ways localconnection can really work:

　　　　Connect (name)--Creates a pipe (each localconnection can only create one pipe, one for each pipe name)

Send (name, ...)-Sends data to pipe

If only two terminals communicate, then everything is so simple ...

　　

Simply send the message to each other.

However, there are a number of terminals that are very different. Since we are local interprocess communication, there is no third-party server hosting, plus localconnection can only point to point to send messages. This means that each broadcast should be sent to all other terminals once, so the complexity is greatly increased.

To simplify the structure, we simulate a localconnection as host, which runs on the first boot. The rest as a client, each broadcast message is submitted to the host, scheduled by it.

　　

Host maintains a list of callbacks. When the client is interested in a topic (subject), it can send a < subject ID, its own pipe name > to the host to subscribe. The host then adds the name of the client's pipe to the callback list for that topic. If you have a message for that topic later, you can notify the subscribing client based on the callback list.

To make the host and client communication simpler, use the channel+id naming convention to create the pipe name.

The ID of the host is empty, so the client sends the data just send (channel);

The ID of the client from 1~100, select a unused to be used as a pipe name. The host callback can notify the corresponding client simply by send (Channel+id).

However, this host service is only a sham. We simply cannot run a third party service outside the page, and everything can only be done on the page! So we have the first launch of the page as host. When this page closes, we then notify the second page to create the host, and so on ...

　　

Because there is no third-party server, each client can be a part time host. Here, you are not thinking of the LAN game? Because there is no server, the first player to create is the host. When he quits, the host is handed over to the second player. If he did not follow the normal steps, forced to quit the game, it will be able to cause the loss of the host, the data can not be transferred to the next player, resulting in the end of the game disconnected.

Similarly, when our host page closes, an exit message is sent to all the client. As for who inherits the throne, do not care, who first learned who to do ~ ~ The only noteworthy is: many browsers do not normally trigger the Window.unload event, this unexpectedly host may not have come to the callback list to his successor has hurried away, so posterity can not take over. in order not to let this happen, whenever the new host takes office, send a request to all the client, asking everyone to resend the topic of their concern (the previous focus is kept, for this time). Therefore, even if the new host has nothing, everyone will tell him the status quo, can immediately put into work.

If the host's page process is forced to close, then everything will hang after the hosts are lost. At this time all the client sent data will have to go no back, only to wait until after the failure of the data sent to know the host has been hung. Who first discovers this mistake, who takes over the host work.

Of course, you can also consider adding a heartbeat mechanism, even if the host is not dead, but its process is long CPU, causing localconnection unable to respond to message events, you can also consider the transfer of host.

Due to time constraints, this example has a lot of bugs, and then slowly improve.

Want to see code can browse: http://code.google.com/p/webipc/source/browse/

In fact, the pure local communication is not very meaningful, only with the remote service for the interaction of messages, it is more meaningful. For example, users open a number of microblogging pages, the traditional model must be a long connection to each page to maintain real-time data reception. If you use cross-browser communication, just let the host initiate a connection, and the rest of the client subscribe to the topic you want, and you end up with just one connection.