WINSOCK applications (3) with a large response size with completion port

zhaozj2021-02-16  53

Restriction condition

It is the main target when designing any server application. That is to say,

Your application should be able to deal with any burst, such as the concurrent customer request reaches the peak, and the available memory temporarily has insufficient, and other short time phenomena. This requires the designer of the program to pay attention to the problem of resource restrictions under the Windows NT and 2000 systems, and handle burst events.

You can directly control, the most basic resource is network bandwidth. Typically, applications that use User Datasters Protocol (UDP) may pay more attention to the limits of bandwidth to minimize the loss of packets. However, when using the TCP connection, the server must be very careful to control, preventing the network bandwidth overload exceeds a certain time, otherwise it will need to retransmit large amounts of packets or cause a large number of connection interruptions. The method of bandwidth management should be determined according to different applications, which is beyond the scope discussed herein.

The use of virtual memory must also be managed carefully. Re-use the allocated memory by cauting to apply and release memory, or to apply the LOOKASIDE LISTS (a cache) technology, will help control the memory overhead of the server application (original "to let the server application left by the server application Small a little "), avoiding the operating system frequently swaping the physical memory of the application application to virtual memory (original as" to allow the operating system to always keep more application address space more in memory ")."). You can also make your operating system more physical memory by setting SetWorkingSize () this Win32 API.

You may also encounter the shortcomings of the other two non-direct resources when using WINSOCK. One is the limit of the locked memory page. If you shut up AFD.sys buffer, all pages of the application buffer will be locked to physical memory when the application transmits and receives data. This is because the kernel driver needs to access these memory, during which these pages cannot be exchanged. If the operating system needs to assign some other applications to some-page physical memory, there is no problem when there is not enough memory. Our goal is to prevent the procedure from writing a pathological, locking all physical memory, letting system crash. That is to say, when your program locks memory, do not exceed the memory paging limit of the system specified.

On Windows NT and 2000 systems, the memory that can be locked in all applications is approximately 1/8 of physical memory (but this is just a probably estimate, not the basis for your calculation). If your app doesn't pay attention to this, when you make too many overlap transceivers call, and I / O doesn't work and complete, you may occasionally Error_INSUFFICIENT_RESOURCES error. In this case you want to avoid over-locking memory. At the same time, it should be noted that the system will lock the entire memory page in which your buffer is located, so the buffer is approached to the page boundary (the translator understands, the buffer is exactly more than the page boundary, even one byte, The page where the excerpt is located is also locked).

Another limit is that your program may encounter the shortcomings of the system unsubstructed pool resources. The so-called unpized pool is a memory area that never swaps out. This memory is used to store some data for various core components, where the kernel components are not accessible to the page space being exchanged. The Windows NT and 2000 drivers can allocate memory from this particular unpized pool.

When the application creates a socket (or similar to open a file), the core will allocate a certain amount of memory from the unpized pool, and when the binding, the connection socket, the kernel will never paginize Some memory is allocated in the pool. When you pay attention to observing this behavior, you will find that if you send some I / O requests (such as sending and receiving data), you will reassign more memory from an unbeatable page (for example, to track a pending I / O operation, you may need to add a custom structure to this operation, as mentioned above). Finally, this may cause a certain issue, and the operating system limits the amount of not paging memory.

On the two operating systems of Windows NT and 2000, the specific quantity of unsimposed memory assigned to each connection is different, and future versions of Windows are likely to be different. In order to make the application's life period, you should not calculate the specific demand for the memory of the unpredictable pool. Your program must prevent the limit that consumes an unbeatable page. When the remaining space remaining in the system is too small, some kernel drivers that have nothing to do with your application will be crazy, even cause system crash, especially when there is a third-party device or driver in the system, it is easier to occur. Such a tragedy (and cannot predict). At the same time, you have to remember that other applications that can also be run on the same computer, so that the exemption of the resource is particularly conservative and cautious when designing your application.

The problem of insufficient resource is very complicated, because you will not receive special error codes when you have mentioned situations, usually you can only receive general WSAenobufs or error_INSUFFICIENT_RESOURES errors. To deal with these errors, first, adjust your application work configuration to a reasonable maximum (translator Note: The so-called work configuration means the amount of memory required to run in each of the applications, please refer to http: // msdn .microsoft.com / MSDNMAG / ISSUES / 1000 / BUGSLAYER / BUGSLAYER1000.ASP, about memory optimization, the translator's other translation), if the error continues, then pay attention to the problem of insufficient network bandwidth. After that, please confirm that you don't have too much transceiver call. Finally, if it is still a mistake of insufficient resources, it is likely to have problems with insufficient memory pool in paging. To release the unpaged memory pool space, turn off a considerable part of the application, wait for the system to spend and correct this instantaneous error.

(Translator) Liu Xi SICKID10001@21cn.com

转载请注明原文地址:https://www.9cbs.com/read-24552.html

New Post(0)