Linux under several concurrent server implementation mode of details

  • 2020-06-23 02:37:05
  • OfStack

1 > Single thread or single process

It is equivalent to a short link. After accept, data is received and sent. No new connection is accepted, namely 1 server and 1 client

There is no concurrency.

2 > Loop servers and concurrent servers

1. Loop server: one server can only receive one client once, and the next client connection can only be made after the current client ends its access.

2. Concurrent server: 1 server can respond to many clients at the same time.

3 > select+ multithreading mode

Three ways to implement concurrent servers

1. Multi-process concurrent server

When TCP connects, each client's request is not handled directly by the server, but is handled by a child process created by the server

2. Multithreaded concurrent server

The multi-process server is an improvement over the multi-process server. Since the multi-process server consumes a lot of system resources when creating the process, it USES threads to replace the process, so that the service handler can be created faster. According to statistics, creating a thread is 10100 times faster than creating a process, so it is also called "lightweight" process. A process is different from a process in that all threads within a process share the same information about global memory, global variables, etc.

After the CONNECTION of TCP, each client's request is not processed directly by the server, but created by the server

3. Multiplexing I/O

I/O is to resolve the thread/process blocking in that I/O call, commonly used select or pool

4 > epoll

The practical method of epoll after linux2.6 is to use one thread to listen on the port. When accept receives the connection, set the connection to non-blocking mode, set the epoll time to edge triggering mode, and add epoll management. The receiving thread is blocked at epoll's wait event function. Another thread is dedicated to sending data.

Note:

1. If epoll is set as horizontal trigger, the efficiency will decrease to the level of select.

2. The Unix system has a limit on the number of descriptors opened by a single process, as well as a limit on the number of descriptors opened in the system. The number of open descriptors in the system is limited by both soft and hard links. Hard connections vary depending on the configuration of the machine. The soft connection limit can be modified but must be less than the hard limit.

Application:

Large scale TCP concurrency under Linux.

There are other ways to do current concurrency. Such as thread pools. Process pools, etc. Each model has its advantages and disadvantages, and epoll is better for large scale concurrency.

The time setting of epoll has edge trigger mode and horizontal trigger mode

1. Horizontal trigger mode:

If the file descriptor is ready to perform the IO operation nonblocking, the notification is triggered. Allows the state of IO to be repeatedly detected at any time. It is not necessary to execute IO, select, poll as many times as possible each time the descriptor is ready.

As long as the requirements are met, 1 event is triggered.

2. Edge triggering mode:

A notification is triggered if a new IO activity has arrived since the last state change in the file descriptor. Perform as many IO operations as possible after receiving one IO event notification, because if IO is not completed in another notification, you will need to wait until the next new IO activity to get the ready descriptor. Signal - driven IO belongs to edge trigger.

Each time the state changes, an event is triggered.

eg: now have a 1000 byte message, whether level trigger or edge trigger, will send a read-only notice, when received 100 bytes, trigger level because there is no reading bytes, it will send a read-only notice, but will be 1 straight edge trigger to maintain wait for notification, waiting for the arrival of the next message, until the return to EWOULDBLOCK will abandon the socket edge trigger.


Related articles: