📜 ⬆️ ⬇️

dklab_multiplexor: constant Javascript connection to the server with hundreds of thousands of online clients

Dklab_multiplexor is a tool that allows you to simultaneously hold hundreds of thousands of long-lived open HTTP connections to a server. For example, if there are several hundred thousand visitors on your site at the same time, each of them can be connected to a server with a persistent connection established from JavaScript. This is for example useful when organizing online chats or instant notifications.

Dklab_multiplexor does not claim to be universal or exclusive (by the way, if you know analogues close in simplicity to multiplexor, write in the comments). This is just the simplest tool that finally got around to publish.

Why do you need it?


Suppose visitors to your site can send each other messages. If the recipient at the time of sending is on the site (viewing any page), he will immediately receive a notification (pop-up window in JavaScript).
')
This problem can be solved in two ways.
  1. Wrong way. Once every 10 seconds, make a request from JavaScript to the server to check if new messages have appeared. This method does not work if there is a very large number of users on the site at the same time, because server load is growing too fast. In addition, user traffic consumption is also extremely high.
  2. The right way. Establish a permanent and long-lasting connection to the server, waiting for data to be received through it. If there are no messages, the connection simply keeps open for several minutes. If the connection is closed for any reason, it opens again. As a result, and traffic is consumed little, and the load on the server is small. This is how GMail, My Circle, etc. work, and it is on this principle that the dklab_multiplexor is built.
 + ------------------- + ------------------ 
 |  Processing Server |  |  |  <=== WAIT === Customer A
 |  and databases |  ====== IN =======> |  Multiplexer |  <=== WAIT === Client B
 |  (eg Apache + PHP | | | <=== WAIT === Client C
 + ------------------- + ------------------ 
 (indicates the direction of establishing TCP-connections).

Brief instructions for use


A multiplexer is an event-oriented daemon written in Perl using the libevent library. The working memory consumption is about 10M per 1000 simultaneous connections. Begin by viewing the default dklab_multiplexor.conf configuration file .

Run the multiplexer

Start the Multiplexer and let it work:

 # cd / path / to / dklab_multiplexor
 # perl dklab_multiplexor.pl> /var/log/multiplexor.log 2> & 1 &

If the Multiplexer does not start, most likely, your system does not have libevent and Event :: Lib libraries. You can install them in the RHEL system using the commands:

 # yum install libevent-devel
 # perl -MCPAN -e "install Event :: Lib"

Let's pretend to be a client browser

Now let's try to emulate the Client browser with the identifier 1z2y3z. Run the command:

 # wget -O- http: // localhost: 8088 /? identifier = 1z2y3z

The wget -O- command opens an HTTP connection at the specified URL and prints the server response. You will see that wget is “stuck”. This is normal: the “browser” waits for someone to send a data block to the Multiplexer for the user with the identifier 1z2y3z. The default wait time for WAIT_TIMEOUT is 300 seconds. If during this time the answer does not come, the connection is forcibly closed, and the client’s JavaScript code that you write must establish a new connection.

So, in a real situation, the JavaScript code of the Client establishes an HTTP connection with a Multiplexer using XMLHttpRequest. When executing a GET request, JavaScript specifies the user ID to receive only messages for this user. The client is waiting for either the arrival of data on new messages from the Multiplexer (then it displays it), or the completion of the connection after 300 seconds. In both cases, the Client immediately establishes a new connection with the Multiplexer and waits for a new response from it, and so on ad infinitum. Thus, due to slow connections, a low server load is maintained, and the instantaneous transmission of a new message from Server to Client is ensured.

We will transmit data to the Multiplexer for the Client.

Open the second console on the server where you just have wget running. Let's transmit to the Multiplexer on port 10010 (see IN_ADDR) the “Hello!” Line and indicate that it is intended for the client with the identifier 1z2y3z. Type in the console command:

 # telnet localhost 10010
 HTTP / 1.1 200 OK
 X-Multiplexor: identifier = 1z2y3z

 Hello!

After that, press Ctrl +], then q and Enter to complete the data transfer. Try to keep within 20 seconds (see IN_TIMEOUT), because otherwise, the Multiplexer will close the connection without waiting for the data.

A multiplexer implements data buffering. Thus, if at the moment of sending the message some Client was not connected to the Multiplexer (for example, it just goes to another page of the site), the Multiplexer will save the message (maximum 100 seconds, see OFFLINE_TIMEOUT) and transmit it to the Client as soon as it connects .

In fact, we now "hands" emulated what the script should do on the site when a new message arrives for the user 1z2y3z. Relevant PHP code might look like this:

 $ f = fsockopen ("localhost", "10010");
 fwrite ($ f, 
   "HTTP / 1.1 200 OK \ n".
   "X-Multiplexor: identifier = 1z2y3z \ n".
   "\ n".
   "Hello! \ N"
 );
 fclose ($ f);

Instead of X-Multiplexor, you can use any other header. The multiplexer searches for the identifier = * line anywhere in the transmitted data.

Hurray, earned!

If you did everything correctly, wget -O- in the next console “hung up”, and the line “Hello!” Appeared on the screen. You can see that the client received exactly the data that was sent to the Multiplexer, “byte per byte”. With the exact protocol of transferring information between the server and the JavaScript part you have to decide for yourself when developing scripts for your site.

Download the utility and read technical details here: dklab.ru/lib/dklab_multiplexor

Source: https://habr.com/ru/post/69457/


All Articles