Complete in-depth understanding of the port and abnormal usage

Author: sodimethyl
Source: http://blog.csdn.net/sodme
Disclaimer: This article may be reproduced, referenced, or reproduced without the consent of the author. However, any reference to this article must indicate the author, source, and statement information of the bank. Thank you.

As the most efficient network model for managing thousands of connections at the same time on the win platform, more and more people are familiar with port completion. Generally, a classic mode of port completion is as follows:
(1) create a port and start listening on the specified port;
(2) create a connection receiving thread and use accept or acceptex to accept the client connection;
(3) create a worker thread to process the data sent and received by the client.
　　
As we all know, the createiocompletionport function has two functions: "CREATE", "complete port", and "bind" a socket with the created port handle. After binding, events such as receiving, sending, and disconnecting Based on the socket can be perceived by the port. Generally, in a normal state of thinking, createiocompletionport is bound to the socket after the accept function is executed or when the acceptex function is completed. However, this does not mean that the createiocompletionport function cannot be bound in other forms.

In fact, createiocompletionport only cares about a socket. It does not care whether the socket comes through accept or connect. That is to say, it does not care whether the current socket is used to accept client connections or to connect to other servers. That is to say, the createiocompletionport function can also be used to bind a client socket to other servers.

This problem was raised when I was designing a gateway server.

The gateway server is responsible for the distribution of client data packets in two ways: Inbound and Outbound. Outbound, it is responsible for sending all the returned data packets of the internal server through the gateway. On the gateway server, I created two iocps, one for accepting data exchanges between players and the gateway, and the other for data forwarding with internal servers. Because I am too lazy, I want to use the iocp model on the internal server.

The iocp responsible for data forwarding to internal servers on the gateway must be able to correctly identify which internal server is using which socket. In this way, there are two ways to confirm the socket between the internal server and the gateway server. One way is to connect the internal server to the gateway server, and then send a registration package to the gateway server to tell the gateway server which internal server the current socket is. The other way is, the gateway server first creates several specified sockets and then uses these sockets to connect to the specified type of internal server. As mentioned above, the socket that iocp can bind is not only a socket that can be accessed by accept, but also a socket that can connect other servers. So I chose the latter method. In this way, the logic processing of the iocp on the gateway server reduces one criterion and the logic parsing of one package. When the gateway traffic is huge, the efficiency and resources will be used more effectively for every decision or branch saved. Where does the High Performance come from? It is from this 1.1 improvement. So far, the maximum traffic of the gateway server I can test is 10 MB to 12 Mb per second. It is said that some hubs in the LAN only allocate 10 MB of outbound bandwidth to each sub-server, therefore, I am not sure if I change the LAN switch to a carrier-level switch, will there be a larger increase in the data exchange volume? Soon, the company will enter such a carrier-level switch, further tests can be performed.

After a while, I will publish my iocp underlying communication model architecture design and a general high-performance server model architecture on my blog (http://blog.csdn.net/sodme, I hope to work with my colleagues on high-performance server R & D issues.