General high-performance Windows Socket component HP-socket v2.2.1 (Added support for the PULL model)

HP-socket is a set of universal high-performance Windows Socket component packages, including the server component (iocp model) and the client component (event select model). It is widely used in Windows TCP communication systems. HP-socket fully encapsulates the communication layer, and upper-layer applications do not need to pay attention to any details of the communication layer. HP-socket provides an API Interface Based on The Event Notification model, can be easily and efficiently integrated into various applicationsProgramIn addition, in order to make it easier for everyone to learn HP-socket, we have carefully created a function test example (test echo) and a performance test example (test echo-PFM)AndTest echo-pull)You can use these two test examples to quickly learn the design ideas and usage of components.

----------------------------------------------------------------

Versatility

• The only responsibility of a communication component is to accept and send byte streams. It cannot participate in upper-layer protocol parsing;
• Decoupled from upper-layer users and independent from each other, components interact with users through the operation interface and listener interface, and the component implementation operation interface provides the upper-layer operation method; the user registers himself as the listener of the component through the listener interface to receive notifications from the component. Therefore, any user can use components as long as the listener interface is implemented. On the other hand, you can even re-write a component implementation method that is completely different for the user to call, as long as the component complies with the operation interface of the component, this is also the embodiment of the dip design principles.

Availability

Availability is crucial to all common components. If it is too difficult to use, it is easier to rewrite it. Therefore, the Operation interfaces and listener interfaces of components 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. In addition, the component completely encapsulates all the underlying socket communication, and the upper-layer applications do not see any communication details and do not have to intervene in any communication operations. The socket connection is abstracted as the connection ID, this parameter is used as a connection identifier for upper-layer applications to identify different connections.

High 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, different Socket models are used according to the performance requirements of client components and server components. 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:

• Client: Implement socket communication interaction in a separate thread. This avoids interference with the main thread or other threads. Select the event select Communication Model for the I/O model.
• Server: The iocp communication model with the highest efficiency on the Windows platform is adopted. The cache pool technology usually requires frequent application and release of the memory buffer during communication and a dynamic cache pool is established, A new object is created only when there are no available objects in the cache pool, and when there are too many cached objects, the cache pool is compressed. In addition, the dynamic memory of the component is allocated through the private heap mechanism, avoid competition with new/malloc and reduce memory holes.

Scalability

You can set the performance parameters of the component according to the actual usage environment requirements (for example: the number of working threads, the size of various cache pools, the size of the sending and receiving buffer, the size of the socket listening queue, the number of Accep distributions, and the interval of Heartbeat checks ).

(Project homepage: Click Here, click here)

 Introduction to the push/PULL model:

The communication component submits data to an upstream application in the following two modes:

1. Push model: when the communication component receives data, it calls the onreceive (dwconnid, const byte * pdata, int ilength) method of the application interface to push data to the application, the application implements this method and obtains pdata within the method for processing.
2. Pull model: when the communication component receives the data, it calls the onreceive (dwconnid, int itotallength) method of the application interface (note that the pdata parameter is not included) to notify the application that the application has the length of ilength, if the application considers that the data of this length can constitute a complete data packet, it calls the fetch (byte * pdata, int idatalength) of the communication component) method to capture idatalength (idatalength <= itotallength ).

The push model is relatively efficient, but the application itself is responsible for handling issues such as unpacking and sticking packets, which brings a certain degree of complexity. The PULL model is relatively simple, as long as the upper-layer protocol is strictly defined (packets in the PULL model are usually divided into header and body data packets), data packet processing can be greatly simplified. However, because an indirect layer is added in the middle of the component, the efficiency is often lower than that of the push model.

 Update record:

 * ** V2.2.1 update ***

> PULL model support:

-----------------

1. Added the PULL model data receiving and notification method onreceive (dwconnid, INT) to the isocketlistener)
2. Added the pull socket interface ipullsocket. The fetch (dwconnid, pbuffer, ilength) method of this interface is used to capture communication data.

> Server:

-----------------

1. The server socket interface isocketserver is renamed iserversocket
2. Added the pull server socket listener abstract class cpullserversocketlistener.
3. Added the pull server socket interface ipullserversocket
4. Added the pull server socket implementation class ciocppullserver

> Client:

-----------------

1. The client socket interface isocketclient is renamed iclientsocket
2. The client socket implementation class csocketclient is renamed cclientsocket
3. Added the pull client socket listener abstract class cpullclientsocketlistener.
4. Added the pull client socket interface ipullclientsocket.
5. Added the pull client socket implementation class cpullclientsocket

> Other updates:
-----------------

1. Added the pull socket test program testecho-pull.
2. Add some help struct in sockethelper. H (. cpp)

> Upgrade description:
-----------------

1. Applications using HP-socket v2.1.1 can be securely upgraded to v2.2.1
2. Because the names of isocketserver, isocketclient, and csocketclient have been modified, the application needs to modify the referenced names and header file names accordingly.

 Related blog posts:

High-performance windows socket server and client components (download of source code and Test Cases)"

Design and Implementation of iocp-based universal asynchronous Windows Socket TCP high-performance server component"

Design and Implementation of Common asynchronous Windows Socket tcp client components"

Codeproject