Linux Network Server

There are two types of network server models in Linux: Concurrent Server and cyclic server. A concurrent server can process requests from multiple clients at the same time. A cyclic server can respond to requests from a client at the same time. For TCP and UDP sockets, the two server implementation methods have different features.
1. TCP cyclic server: the TCP server first accepts the connection request from a client, processes the connection request, disconnects the client after completing all the requests, and then accepts the request from the next client.
The algorithm for creating a TCP cyclic server is as follows:
Socket (......); // Create a TCP socket
BIND (......); // Specify the accepted port number
Listen (......); // Listener Client Connection
While (1) // start to receive client connections cyclically
{
Accept (......); // Receives the connection from the current client
While (1)
{// Process the current client request
Read (......);
Process (......);
Write (......);
}
Close (......); // Close the current client connection and prepare to receive the next client connection
}
The TCP cyclic server only processes requests from one client at a time. If one client occupies the server, other client connection requests will not receive timely responses. Therefore, the cyclic server model is rarely used for TCP servers.
2. TCP concurrent server: the idea of a concurrent server is that the request of each client is not directly processed by the master process of the server, but created by the master process of the server for processing.
The algorithm for creating a TCP concurrent server is as follows:
Socket (......); // Create a TCP socket
BIND (......); // Specify the accepted port number
Listen (......); // Listener Client Connection
While (1) // start to receive messages from the client cyclically
{
Accept (......); // Receives a client connection
If (Fork (......) = 0) // create a sub-process
{
While (1)
{// The sub-process processes the connection of a client.
Read (......);
Process (......);
Write (......);
}
Close (......); // Close the client connection processed by the sub-process
Exit (......) ; // Terminate the sub-process
}
Close (......); // The parent process closes the socket Descriptor and prepares to receive the next client connection.
}
The TCP concurrent server can solve the problem that the TCP cyclic Server Client exclusively occupies the server. However, it also brings about a major problem: in response to client requests, the server needs to create sub-processes for processing, and creating sub-processes is a resource-consuming operation.
3. UDP cyclic server: The UDP server reads a client's datagram request from the socket each time, processes the received UDP datagram, and then returns the result to the client.
The algorithm for creating a UDP loop server is as follows:
Socket (......); // Create a datagram socket
BIND (......); // Well-recognized short slogans
While (1) // start receiving client connections
{// Receive and process UDP datagram from the client
Recvfrom (......);
Process (......);
Sendto (......);
// Prepare to receive the datagram from the next client
}
Because UDP is non-connection-oriented, no client can exclusively occupy the server. As long as the processing process is not an endless loop, the server can always process requests from each client.
When the datagram traffic of a UDP cyclic server is too large, the customer technical datagram may be lost due to heavy processing tasks. However, because the UDP protocol itself does not guarantee the reliable arrival of the datagram, The UDP protocol is especially likely to lose the datagram.
In view of the above two points, the general UDP server adopts the loop mode
4. UDP Concurrent Server
Apply the concept of concurrency to UDP and get the concurrent UDP server. Like the concurrent TCP server model, subprocesses are created for processing.
The algorithm for creating a UDP concurrent server is as follows:
Socket (......); // Create a datagram socket
BIND (......); // Well-recognized short slogans
While (1) // start receiving client connections
{// Receive and process UDP datagram from the client
Recvfrom (......);
If (Fork (......) = 0) // create a sub-process
{
Process (......);
Sendto (......);
}
}
Unless the server takes a long time to process client requests, this UDP concurrency server model is rarely used.
5. multiplexing I/O concurrent servers: creating sub-processes will consume a lot of system resources. To solve this problem, a multiplexing I/O model is used for concurrent servers. The algorithm for using the select function to create a multiplexing I/O model for concurrent servers is as follows:
Initialization (socket, bind, listen );
While (1)
{
Sets the listener's read/write file descriptor (FD _*);
Call select;
If the listener socket is ready, a new connection request is established.
{
Establish a connection (accept );
Add it to the listener file descriptor;
}
Otherwise, it indicates a descriptor that has been connected.
{
Read or write operations );
}
}
Multiplexing I/O can solve the Resource Restriction problem. This model actually uses the UDP loop model on TCP. This also causes some problems. For example, if the server processes client requests in sequence, the client may wait for a long time.