High-performance Windows Socket server and client components (HP-Socket v1.0.1 source code and test case download)

Since I published two articles on the implementation of the Windows Socket communication component, I have received comments from many readers, hoping to share the complete source code. At this time, this seat does not harm you. The complete code of the server component and client component is provided here. In addition, it took a little time to carefully prepare two test cases for readers to learn and understand, one for functional testing (TestEcho) and the other for performance testing (TestEcho-PFM ). Readers can use these two test cases to quickly learn how to use components. Thank you for your help ~ Pai_^ ~

 

(Click here, You know ^ _*)

 

 

Original article: Design and Implementation of IOCP-based general asynchronous Windows Socket TCP high-performance server component"

 

Design Overview

The Design of server-side communication components is a very rigorous task. Performance, scalability, and stability are hard and hard quality indicators that must be considered, to design a component as a general component for a variety of known or unknown upper-layer applications, the design becomes more difficult and the versatility, availability, and flexibility must be taken into account.

Taking a general asynchronous Windows Socket TCP Server Component Based on IOCP as an example, this article describes its design and implementation problems, hoping to stimulate everyone's thinking, it will be helpful for you to carry out similar work in the future. The topic about universality, availability, Socket model selection, and interface model design has been published in 《Design and Implementation of Common asynchronous Windows Socket TCP client componentsAs described in, we will not repeat it here. At present, the design and implementation problems of the communication components on the server are described.

 

　　I. Thread Structure

There are three types of threads related to components: User thread, Accept thread, and worker thread. The latter two are implemented by components.

1. 1. User thread:Call the Start, Stop, Send, and other component methods to operate on one or more threads of the component, usually the main thread of the program or other business logic threads.
   2. Accept thread:Use AcceptEx () to receive Client connection requests and create a Client Socket thread. Separate the thread into a separate thread to make the module division of the component clearer, it is more important to avoid interaction with business logic and communication processing.
   3. Worker thread:Use GetQueuedCompletionStatus () to listen to network events and process multiple threads for network interaction. After the worker thread finishes processing network events, it will send OnAccept, OnSend, OnReceive, and other component notifications to the application at the upper layer. The Number of worker threads can be set based on the actual situation (generally recommended: CPU Core Number * 2 + 2 ).

　　Note:If the upper-layer application directly processes the business logic and operates the components when receiving notifications from the OnAccept/OnSend/OnReceive components, the working thread becomes the user thread. In addition, if the business logic to be processed is time-consuming, the upper-layer application should submit it to other threads for processing after receiving the component notification.

 

　　Ii. Performance

Components use the IOCP Socket communication model with the highest efficiency on the Windows platform. Therefore, the performance of the communication interfaces is guaranteed. I will not talk about it here. Performance optimization is explained from the perspective of component design and implementation. Components have been optimized a lot at the code level, and some seemingly redundant or tedious code is actually for performance services; components mainly adopt the 2 optimization strategy in design: cache pool and private heap.

1. Cache pool:In the communication process, it is usually necessary to frequently apply for and release the memory buffer (TBufferObj) and Socket-related struct (TSocketObj), which will greatly affect the component performance. Therefore, the components are TBufferObj and TSocketObj. A dynamic cache pool is created only when there are no available objects in the cache pool. When there are too many cached objects, the cache pool is compressed.
2. Private Heap ):In the operating system, new/malloc and other operations are serialized, although general applications do not need to care too much about this problem, however, a high-concurrency Server is a problem that cannot be ignored. In addition, both TBufferObj and TSocketObj are fixed-size structs. Therefore, it is very suitable for allocating memory in a private heap, avoid competition with new/malloc and reduce memory holes. (For details about how to use a private stack, refer to pai_^)

　　Iii. versatility and availability

And 《Design and Implementation of Common asynchronous Windows Socket TCP client componentsSimilar to the client interface described in, the server component also provides two sets of interfaces: The ISocketServer interface provides component operation methods, which are directly called by upper-layer applications; the IServerSocketListener interface provides component notification methods, implemented by upper-layer applications, these two interfaces are designed very simple, with no more than five main methods. Because the components are fully functional (no additional libraries or code is required) and have a single responsibility (only communication is required and not involved in the business logic ), therefore, it is very convenient to integrate into any type of applications.

 

　　Iv. scalability

You can set the number of working threads, the size of the TBufferObj and TSocketObj cache pools, the size of the TBufferObj buffer, the size of the Socket listening queue, the number of AccepEx distributions, and the heartbeat check according to actual environment requirements. interval.

 

　　5. Connection ID

The component completely encapsulates all the underlying Socket communication, and the upper-layer applications do not see any communication details and cannot intervene in any communication operations. In addition, the component has a Connection ID parameter in all methods of the IServerSocketListener notification interface. This parameter is used as the Connection identifier for upper-layer applications to identify different connections.

 

 

Original article: design and implementation of common asynchronous Windows Socket TCP client components"

 

Design Overview

Writing a Windows Socket TCP client is not difficult. Windows provides six I/O communication models. However, I have seen many client programs mix the Socket communication and business logic, and the logic is still messy. Every program can Copy/Parse similar code and then modify it. Therefore, this book uses some leisure time to writeIOCP-based general asynchronous Windows Socket TCP high-performance server componentAnd oneGeneral asynchronous Windows Socket TCP client componentWe hope that you will be inspired by our reference. This article describes the client components. Let's talk less about it. Now we are on the right corner.

• The most important first question: how can we achieve general purpose?

A: It's easy.

1. Restrict the functions of the component. To put it bluntly, the only responsibility of the communication component is to accept and send byte streams. It is absolutely unable to participate in upper-layer protocol parsing and other work. This is what it means.

2. decoupled from upper-layer users and independent from each other. components interact with users through interface methods, and components implement the ISocketClient interface to provide upper-layer operation methods; the user registers himself as the Listener of the component through the IClientSocketListener interface and receives the component notification. Therefore, any user can use components as long as the IClientSocketListener interface is implemented. On the other hand, you can even re-write a component implementation method that is completely different to the user to call, as long as the component complies with the ISocketClient interface. This is also the embodiment of DIP design principles (if you want to learn more about the design principles, please slam here ^_^ ).

 

• The second most important question: how is availability, that is, is it convenient to use?

A: This is a good question. availability is crucial to all common components. If it is too difficult to use, it is better to write it again. Therefore, the interfaces of ISocketClient and IClientSocketListener are designed to be as simple as possible (in general, they are "dumbfounded"). There are no more than five main methods for these two interfaces.

 

• The third most important question: how is the component performance?

As a general component at the underlying layer, performance issues must be considered and cannot be a bottleneck of the system. On the other hand, starting from the reality, after all, it is only a client component, and its concurrency requirements are far less high than that of the server. Therefore, the components fully consider factors such as performance, actual use cases, availability, and implementation complexity to ensure that the performance requirements are not too complex. Make the following two design decisions:

1. Implement Socket communication interaction in a separate thread. This avoids interference with the main thread or other threads.
2. Select WSAEventSelect for the I/O model. The reason for choosing this I/O model: (for the performance comparison of various I/O models, refer to Windows Network Programming (Chinese version 2), pp. 154th)

• Blocking model: (do not parse, you know ^_^)
• Non-blocking model: (performance is too low)
• WSAAsyncSelect: (two reasons: a. The performance is too low; B. It is really difficult to bear HWND for pure Console programs !)
• Overlapping I/O: (a bit complicated)
• Port completed: (Why ?)

 

CodeProject