Some problems in RPC
1. Data Protocol
Serialization method (packet size, serialization optimization)
To support more data formats (xml, json, etc.)
----> The protocol header of the custom data, the end of the custom data.
2. IO model
2.1 Common IO models
----->Synchronous blocking IO (Blocking IO): traditional IO model
----->Synchronous non-blocking IO (Non-blocking IO): The sockets created by default are blocked.
Non-blocking IO requires socket to be set to NONBLOCK. The NIO mentioned here is not java, not java's NIO library (new io)
----->IO Multiplexing: The Reactor design pattern is also known as asynchronous blocking IO.
Selector in java and epoll in linux are both this mode
----->Asynchronous IO (Asynchronous IO): Proactor design pattern asynchronous non-blocking IO.
2.2 Synchronous and asynchronous: how user threads interact with the kernel
----> Synchronization means that after the user thread initiates an IO request, it needs to wait or poll for your IO operation to complete before continuing to execute.
---->Asynchronous means that after the user thread initiates the IO request, it continues to execute. When the kernel IO operation is completed, the user thread will be notified, or the user thread will be called to register the callback function.
2.3 Blocking and non-blocking
The way the user thread calls the kernel IO operation. Blocking means that the IO operation needs to be completely completed before returning to the user space.
Non-blocking means that the IO operation returns to a state immediately after the IO operation is called, without waiting until the IO operation is completely completed.
2.4 Synchronous blocking IO
The user thread initiates an IO operation through the system call read, which is converted from user space to kernel space.
The kernel waits for the data packet to arrive, and then copies the received data to user space to complete the read operation
Fake code:{
read(socket,buffer);
process(buffer)
}
The user needs to wait for read to read the data in the socket to the buffer before continuing to process the received data.
During the entire IO request process, the user thread is blocked by Su Ze, so that when the user initiates an IO request, the
Anything, not enough CPU utilization.
2.5 Synchronous non-blocking IO
Set the Socket to NONBLOCK on the basis of synchronous blocking IO. In this way, the user thread can return immediately after initiating an IO request.
The user thread needs to continuously initiate IO requests until the data is reached, and then it can actually read the data and continue to execute
Fake code:{
while(read(socket,buffer)!=SUCCESS){
process(buffer);
}
}
The user thread can return immediately after initiating an IO request. However, in order to obtain data, it is still necessary to continuously poll and repeat the request.
consumes a lot of CPU resources. This model is rarely used directly
2.6 Multiplexing IO
IO multiplexing is based on the demultiplexing function select provided by the kernel, using select
The function can avoid the polling wait problem in the synchronous non-blocking IO model.
The user first adds the socket for the IO operation to be performed to the select, and then blocks and waits for the return of the select system call.
When the data arrives, the socket is activated and the select function returns. The user thread officially initiates a read request, reads the data and
Continuing seems to be less efficient than the synchronous blocking model. However, the biggest advantage of using select is that users can
To process io requests of multiple sockets at the same time in one thread, users can register the same socket, and then call select continuously
Read the activated socket. To process multiple IO requests at the same time in the same thread
Fake code{
select(socket);
while(1){
sockets = select();
for(Socket socket : sockets){
if(can_read(socket)){
read(socket,buffer);
process(buffer);
}
}
}
}
The IO multiplexing model uses the Reactor design pattern to implement this mechanism
2.7 Asynchronous IO
"True" asynchronous IO requires stronger support from the operating system.
In the asynchronous IO model, when the user thread receives the notification, the data has been read by the kernel and placed in the user thread
In the specified buffer area, the kernel can notify the user thread to use it directly after the IO is completed.
Operating system support is not particularly perfect, and more uses IO multiplexing to simulate asynchronous IO mode
3. Thread model