Highly loaded socket server?

Question

C++ / C#

Good day, dear Khabrovites!

I am writing my first high-loaded socket server (about 5000k clients) under *nix. The algorithm is such that the connection with the client must be kept until he breaks it himself.
Question. How to properly organize multithreading and IPC?
OS: *nix.
Language: C++.

What was already looking for. Google gives implementations in which processes with threads process the request and turn off ...
But I need active threads to interact with the parent, or something else, to constantly update statistics ... (the variant with the database is not yet acceptable)
Tell me, please, an idea or where to dig, how to implement a server with such a load, i.e. what is the correct order of accept()+fork()+pthread_create() and what kind of IPC is best suited for this kind of workload? What type of IPC can withstand loads of 5-10k clients? with a minimum of delays, of course ...

Studying the source codes of Open Source web servers, I didn’t get anything ... because “they process the request and turn off” ...

did I understand correctly that this is not a painfully trivial problem?

Thank you.

Answer 1

1. Forget about threads and especially processes, no axis can withstand 5-10k threads.
2. Accordingly, only non-blocking I/O. One thread only deals with i / o and dumps the received data to other threads ... You would still say what your task is, otherwise it’s a finger in the sky.
3. Normally it is difficult to implement non-blocking i / o from the first time, from the second too ... There are a lot of “tricks” inside each axis that will block your flow. I highly recommend using libevent or something like that.
4. If you are already collecting statistics and all that, do not reinvent the wheel and take at least SQLite. Otherwise, again, you will collect a bunch of rakes and jambs with competition, mutual blocking of threads, crash of the database when the server crashes, flights and other delights of multithreading. SQLite can be built right into your program, for an external observer it will not exist.

Answer 2

It seems to me that it is better for you to look towards an openSource DBMS like PostgreSQL, because the DBMS should just keep the connection until it is terminated by the client.
Although, of course, I suspect that picking out this mechanism from there will not be easy.

Answer 3

I'm not an expert, but the phrase 'which of the IPC mechanisms will withstand' is a bit strange, what's the difference if there is only one in the OS - message queue, shared memory and semaphore, whatever you choose, will use them (especially curves one thing) .
Not exactly a web project, but to parallelize the task, I had to use both queues and semaphores (very active use), I recommend not passing data in the queue, it ends quickly ... maximum identifiers and details through shared memory or other mechanisms.
Perhaps you shouldn’t create one semaphore for everything, it’s better to use a semaphore for an object or at least a group (to block only access to the group and not everyone to everything) - this approach can probably give the maximum possible increase when you hit the ceiling (it's especially sad when the processors are not yet loaded and the demons are waiting for something), this is in the sense of organizing a multiprocessor daemon (or a daemon per core, it's more convenient).

Answer 4

If you need a high-performance socket server, it is better not to write a multi-threaded application, but to process all operations with sockets in one thread, as nginx does, for example.

Answer 5

look towards libev, livevent, libux.
You can see the source texts of Node.JS. Or just write in Node.JS, the speed will surprise you.

Answer 6

Try looking at the sources of the raknet project . This is an open source engine for online games. It might help.

Answer 7

Are you sure you will do better than the team that made erlang?
I advise you to look at it, it was just developed for your requests + there are a lot of goodies that will be useful to you during the update and operation of the system.