How to organize a highly loaded TCP server?

Question

Nginx

There is a constantly updated database. The server must select data from the database and give it to clients, both synchronously (immediately after the client request) and asynchronously. In other words, a two-way connection is established between the clients and the server. The target platform for the server is Debian, for clients - Windows, Android (+ web interface, but without asynchrony here). All interactions via the Internet (the server has a white IP; the client can be anywhere you want - behind NAT, behind Proxy).
Question: what is the best way to implement such a TCP server (language, libraries, examples) so as not to make a lot of bicycles?
Unformed ideas as an attempt at a symbiosis of quick Google and existing skills:
- write your own TCP server (Erlang?), Starting with synchronous / asynchronous sockets, multithreading, and so on.
- or write a module for Apache? (I don’t have a good idea of ​​what it looks like, and it’s hardly suitable)
- your protocol for interaction between the client and the server based on JSON?
- use STUNT to bypass NATs?
- use SOCKS to pass a TCP stream through a proxy?
- use SSL to secure TCP traffic?
Anyone with experience please help!

Answer 1

Based on the discussion above, I recommend looking at:
1) zeromq.org
2) ampq.org

Answer 2

Well, I think you answered your own question - erlang seems to me the best way out. But it’s hardly worth writing a bicycle - take a yaws thread (I think it will be easiest for you with http - yaws from the server side and heaps of libraries - for android and completely built-in - for the client).
Which protocol is not so important, although probably which binary thread would be more efficient. Moreover, Erlang is not bad with the processing of binary data. Something like rest, I think it will be best here.
NAT transversal for a server with a white IP is not needed at all. Now, if your server was behind Nat itself, then yes. You rightly noticed - this is more and more relevant for p2p.
And as for encryption... Yes, you can probably tie ssl, but I recommend TLS v2 and older (versions younger and ssl versions broke not so long ago).
As for the proxy, I did not understand at all. The standard request mechanisms from the android side of the same are more than sufficient IMHO for processing all sorts of proxies. Leave this matter to the user's system, do not meddle in it.

Answer 3

Maybe a tornado?