Learning Linux Server Programming in the process with a multi-year Linux server programming experience of the predecessors consulted, some of the understanding may not be so thorough,
Here to record, the latter part of the cultivation of the almost back to see if there is a new understanding.Mainstream server ModeDo a lot of server projects, see a lot of source code, now mainstream servers are reactor mode, the following is a simple epoll implementation of the reactor model example http://blog.csdn.net/rankun1/article/details/69938640
Separate IO events with Select or poll, Epoll and then process IO events (send or read network data) and finally unpack the received data
And then do the appropriate processing, the more complex will be the solution of the packets into a task queue to
blocking and non-blockingBlocking and Non-blocking emphasize whether the idea of waiting for a program to handle time-consuming operations is generally for IO or other potentially time-consuming operations, here we analyze IO operations: Whether the network IO or file Io,io descriptor can be set to block or non-blocking, take recv for example, The IO operation can be divided into two steps: The first step is to determine whether there is data when recv, the second step to receive data blocking IO and non-blocking io is the difference between the first step when there is no data (if the data is determined, you go to recv, blocking and non-blocking effect is the same) For blocked IO: If there is data in the recv, then take the second step immediately to receive the data return; If no data is found, the RECV function blocks the wait until the data arrives, and the receiving data recv function returns for non-blocking IO: If there is data in the recv, Immediately take the second step to receive the data return, found that no data recv directly return-1 error, and return a wrong code wsaewouldblock, indicating that it is not a real error, but the current operation can not be completed, that is, no data. Summary: When we perform recv this operation may be time-consuming (this time mainly refers to from no data to the arrival of the data, the time to receive data is not taken into account), during this time you want the program to wait in the process. There is no data blocking here waiting, do not perform other operations, this is blocking (for connect, I do not want to block waiting until connect completes, for accept is I do not want to block waiting until accept finish). I do not want the program to wait here, I continue to handle other operations, I will come back later to see if there is data coming, this is non-blocking.Select PollIn the case of blocking and non-blocking: If you determine the data, you go to the recv, blocking and non-blocking effect is the same (obviously, I have to have the data, certainly not to spend time on the arrival of data), then how to determine the data. Select Poll is doing this, listening to your IO descriptor on whether there is data, there is data to return, there is also a benefit is that they can listen to multiple IO descriptors (internal polling view), this is the concept of IO multiplexing. Note that the time it takes to select is whether the timeout you set is not related to the blocking of your IO descriptor, and don't confuse it. This is the Select poll detailed explanation http://blog.csdn.net/rankun1/article/details/69691950Select to determine how much time is appropriate once the data has been received. It doesn't have to be a while, which means it doesn't have to be recycled because there's already data in the Select
So call recv must be able to receive data, as a one-time collection of how much according to your personal favorite
If the server sent 100 bytes, you have to charge 200, okay, this time it will receive 100, recv return value is 100
On the other hand, if you choose to charge 50 bytes for 100 of the bytes, the next time you call select because there is still data on the socket, you will still see the socket readable
You will continue to charge.
Select to notify you once, if you want to cycle recv, or multiple recv you have to pay attention to, blocking socket and non-blocking socket is a difference, because the select notice once you have the data, you repeatedly recv process, do not know which time to collect the data, It is not certain that the next time there is no data can be recv, for no data, of course, blocking and non-blocking are different, the above has been said.How much data is collected and how much dataTo continue the above topic, I can know in advance how much the current socket recv, and then I went to recv how much. The answer is yes.
int ioctlsocket (
_in_ SOCKET s,
_in_ long cmd,
_inout_ u_long *argp
);
You can use this function to know in advance how many bytes to collect. But not often.
Synchronous and asynchronousMy first understanding of synchronization and Asynchrony is this: in IO operations, there is a callback notification is asynchronous, there is no callback notification need to wait for the synchronization, so the understanding is too narrow, where synchronous and asynchronous is a broad concept, set callback is the mainstream way of asynchronous. (Synchronization with multithreaded programming is not a concept, don't confuse it). (The following synchronous asynchrony is not understood here, Mark here, look back and then rearrange) synchronization is the code may be blocked on a process
Example:
Data Reception Examples:
Set up the Collect data and the actual receipt data is sequential in the process, this is the synchronization
Setting up the collection data and the actual collection data is two different places, this is asynchronous
Connect Example:
Connect is usually blocked, waiting for it to return the result, is synchronized
Set socket non-blocking mode then connect will return immediately, without a care,
Later, select to detect if the socket is writable if writable is connected, this is asynchronous
No blocking equals asynchronous,
The Std::async and std::future inside the c++11 are all good ways to set up asynchrony.
In short, the use of synchronous or asynchronous according to their own needs, synchronization in the process of consistency, easy to debug; Asynchronous code has a crossover, the process may be difficult to understand, inconvenient debugging
20171209 Update: The concepts of synchronous and asynchronous in the I/O model are different from the concepts in the concurrency pattern: synchronization and Asynchrony in the I/O model are performed by WHO (application layer or kernel), or whether the IO event occurs as a notification readiness event or a completion event:
Synchronous Io:io Read and write events trigger, you need the application layer to call the Recv/send to send and receive data, that is, IO event occurs, is to explain the data is ready, can read and write the asynchronous Io:io read and write events triggered, indicating that the data transceiver has been completed, by the kernel to complete, You can handle data directly. Synchronization and asynchrony in the concurrency pattern are reflected in the order in which the program is executed: synchronization refers to the fact that the program executes exactly as the sequence of code, and that the program execution needs to be driven by system events, and common system events include interrupts, signals, and so on.
horizontal trigger and Edge triggerLevel trigger and Edge trigger, this is the concept introduced by the Linux 2.6 kernel, because it comes with epoll, Windows does not have this concept first look at the difference between select and Epoll http://blog.csdn.net/ rankun1/article/details/70227010 Repeat Select and Epoll differences: 1. Select has a handle number limit, Windows platform is 64, and is to traverse these sockets, the algorithm is O (n), set the greater the efficiency is lower, the number of Epoll is the system's largest number of handles, this as long as the system has enough memory, basically think a lot of
2. Select is active polling, and Epoll is the operating system to notify you, if not, epoll hanging there, one equivalent to thread idling, one equivalent to thread hibernation
Besides, LT and et mode.
For example, if a socket is readable, lt mode triggers
For et mode, a socket from no data to have data will trigger once, if confiscated clean, the next time will not trigger
Explain:
The LT mode is triggered when there is a signal on the FD, ET is the signal change that triggers
This is the concept of electrotechnics, high level has signal, low level no signal
Lt is triggered as soon as there is a signal, et is triggered once from the low level to the high level
Therefore, the ET mode must be the socket data collection clean, or the back will not trigger the data can be read (similarly, if you this socket is a service-side listening socket, then the ET mode you want in the loop accept processing all connections, or the following will not trigger the client connection), That means putting it in a loop, which is the essential difference.
Network IO processing and Data Logic processing (solution protocol, etc.) to be placed in different threads ?The thread that handles network IO is called network thread, it is usually loop block on epoll_wait, wait for epoll_wait to receive data or receive client connection after triggering, receive data can put in separate thread to unpack, also can let idle network thread to do. Because sometimes, most network threads are idle. This, of course, depends on your server scenario to determine which way you want to unpack the package. It is possible that your data is very small, but a lot of clients, it is possible that your client is not much, but the data interaction is very frequent and so on. Look at what kind of business logic you are focusing on. Here is a way to let the idle network IO thread to do the work of the solution, the core is to let the network IO thread epoll_wait when specifying a local socket, we use this socket to wake the network thread epoll_wait pseudocode: detailed description http:// blog.csdn.net/analogous_love/article/details/53426777
Application of Timer in server programmingThere are two main scenarios, one is timed to send a heartbeat packet. The other is flow control, detailed talk about flow control: For example, you go to a restaurant to eat, a lot of people have ordered dishes, restaurants generally, to each table to order everyone to eat first, instead of first to a table good other people wait
Similarly, when a server handles a lot of connections, for example, there are now three connections a B C, a worker thread that might have been working with a request and answer
Then B C is not always waiting, how to do this time, each processing a data request is to write down a byte number, such as a recv note A1 the second time A2
A1 + A2 + ... +an >= LIMIT
When A's data has surpassed limit, this time even if a has the new data I also not to collect, the time frees up for B and C,b and C also
To A,b,c set a timer TA,TB,TC, such as 1 seconds after the TA will be a limit limit to cancel, that is, a flow of clear 0, so that can continue to deal with a.
This is a way of flow control, the advantage is to avoid some people starve to death, and restaurant serving a reason
So the timer is also an important aspect of network programming
Flow control can make a server priority policy
All timers are sorted in priority order.
Judge the time of the first timer is not, if the flow to clear the corresponding connection, did not have to judge, and then judge the second, and so on
The save timer can be sorted by the priority of the STL queue,
This will be sorted automatically, small in front, big in the back
Some of the ticketing software server has a priority to deal with the strategy, full of money, VIP server priority to deal with your request
