How does ruby ​​create data exchange between two users?

Ruby on Rails can only respond to a client request.

Accordingly, one client can leave a message on the server for another, and another can ask for messages for himself and receive it. Messages can be for a specific addressee, and can be about a specific game room. Models start at discretion.

If the second client is waiting for messages at any time, he may periodically go for messages for himself. The delivery time of each message will thus be limited to the period with which the second client requests messages.

But the smaller this period is, the more the client will make requests per unit of time, and the greater will be the load on the server. Not very good.

Although this is not the whole story.

In Rails 5.0, added ActionCable. Its operation requires a web server capable of handling many hanging connections at the same time (not Unicorn and certainly not a Webrick!), And a “broadcaster” that can quickly receive messages and release those who bring them, but send messages to the recipients (by default in production, Redis is used in its role).

The ActionCable process and the main webserver may be different processes (or may not be), but since messages are sent via Redis, it does not matter. You can even send messages to the same Redis by other services of the same project, and they will also go to users if they are in the correct format.

For a client, it looks as if an application at a certain URL establishes a connection using the Websocket protocol, from which it can receive messages initiated by the server . JavaScript code in the client browser can process incoming messages in an arbitrary manner.

On the server, it is possible to throw a message into the “broadcaster” so that ActionCable sends it to everyone who subscribes to such messages almost immediately , without waiting for an explicit request from the user (but on condition that he has already established the connection). No "solution for outdated browsers without Websocket" (fallback) is currently not provided.

And this is not the whole story either.

In fact, you can exchange data without a server. Almost. And only sometimes. It depends on the network location of the exchanging clients, which in this case are no longer clients, but peers -to-peer, equivalent participants in data exchange.

In browsers, this is implemented by WebRTC technology. It requires that clients somehow exchange the addresses at which they can be tried to find (usually a signal server is made for this, and the addresses are obtained using a STUN server), and they try to establish a direct connection with each other. And if it does not work out (since the clients are located very well relative to each other), a TURN server comes in, pumping the end-to-end-encrypted traffic through itself.

On the Internet, you can find public STUN-servers. Signal is also possible, but more difficult. But TURN is unlikely, this is essentially a general-purpose proxy. You can do without TURN, but connections will often refuse to be established. You can check on almost any small WebRTC-craft without TURN like my ugly chatik .

And there has been a tendency to turn off WebRTC for the reason that it leads to the “leakage” of the real IP address, when the browser works “in a particularly anonymous mode” through a proxy or some kind of VPN. In this case, nothing will just work.

But that's not all ...

I had to meet ActionCable-like construction, even before the release of it, where connections processed the process on Node.js with the help of socket.io, which implements two-way communication more reliably and with respect (moderate) to old browsers.

The connection between it and the web server can be maintained through the same Redis or another messaging server, such as RabbitMQ. Although it makes sense, in an amicable way, only one-sided, from the web server to clients. Clients and normal HTTP requests can send at any time.

In general, there are no easy ways.