Instant messaging and browser multi-tab Communication

Document directory

• Multi-tab Communication Technology
• Problems and Solutions

Summary

The real-time communication technology between browsers and servers solves the problems related to online chat and other products in complex network environments. The multi-tab communication technology is used to handle cross-page communication of modern browsers, analyzes technical solutions for specific problems.

Tag

Instant communication and multi-tab Communication

Content

Key Technologies

1. Message push: implemented through web server-based persistent connection technology
2. Front-end multi-tab Data Interaction: Implemented Using Flash's local connection and jsonobject Technology

Client-server interaction model

Hierarchical Design

Multi-tab Communication Technology

• Main functions:

1. Maintain a maverick tab in multiple tabs

2. Multi-tab communication: Support for broadcasting, multicast, and unicast

3. cross-browser Data Storage

4. Send HTTP requests across domains

The uniqueness of Flash localconnection ensures that multiple tabs in multiple browsers on the client have only one page to interact with the server. This is called Server tab.

Only the Server tab will communicate with lightthy.

After the Server Tab receives the lightthy message, it obtains the ID of other tabs from the local storage named mongodobject and passes it to them through localconnection.

Problems and Solutions

Problem:

• Communication time is too long. The local connections constructed by localconnection are all in serial form. Each time you connect to your computer, the transmission time of IE is about 40-100 ms when the machine is in normal state; the next connection must be completed only after the previous connection returns successful. Then, if we broadcast 20 windows at a time. The last window is about two seconds after the message is received. If a message fails or is blocked in the middle, the time will be longer.
• In the form of broadcast alone, no matter what the message is, all the receivers are woken up once, and the receiving end determines whether to process the received message. This wastes a lot of resources. Therefore, you can consider using multicast to reduce this consumption. In-group unicast is more efficient for some special applications.

Solution:

• Store the list of receivers, divided by groups.
• In the local protocol, groups are implemented.

Problem:

• Multi-page concurrency frequently writes to mongodobject, which can easily cause mongodobject to crash (the file is deleted without reason and creation fails again ).
• Considering that a computer cannot log on to only one user, and the storage capacity of mongodobject is limited, it is critical to delete useless data effectively.

Solution:

• The write queue + file lock mechanism is used to avoid concurrent write operations.
• To avoid client exceptions, such as killing the browser process, the file lock cannot be unlocked, and the automatic unlocking timeout issue needs to be handled.
• For very frequent special write operations, you can use policies such as deleting useless receiver IDs from reclist, buffering time, and batch operations.
• For storage space restrictions, our solution is to store the list data of only the 10 users who have recently performed operations.

Problem:

To reduce the pressure on the server, the original design is that the front-end should pick out a unique window in multiple browser windows to initiate the listen. The server tab concept ensures that the front end can generate a unique window for initiating listen. The implementation principle is to use the connect name uniqueness of localconnection and round-robin connect to ensure that once the originally initiated listen window is closed, a window can be automatically selected as the Server tab and the listen is initiated. However, we still encountered some strange problems in the shell browser, and the window was cached as a false dead state. This mechanism cannot run properly.

Solution:

• The server tab ID is not permanent, but time-related. That is to say, add a lifecycle to the Server tab. It can solve some problems caused by the false death of windows in Shell browsers.
• In mainstream browsers (ie, Firefox ...) When window. Unload is used, the server and polling of the page are closed. In other non-mainstream browsers, window. beforeunload is used for this operation. Further reduce the chances of such exceptions.
  

The following is a local registration process after a window is opened.