Accept connection request
One of the most common things to do in the server is to accept connection requests from the client. The only API that uses overlapping I / O accepted connections on the socket is the acceptex () function. Interestingly, the usual synchronous acceptance function accept () return value is a new socket, and the acceptex () function requires another socket as one of its parameters. This is because acceptex () is a overlapping operation, so you need to create a socket in advance (but don't bind or connect it), and pass this socket to Acceptex (). The following is a typical pseudo code using Acceptex ():
Do {- Wait a new AcceptEx to complete - Create a new socket and associate with the completion port - Set the background structure, etc. - Send an AcceptEx request} while (true);
As a server-responsive server, it must issue enough AccePtex calls, waiting, and respond immediately once the client connection request appears. As for how many ACCEPTEXs are enough, depending on the type of communication traffic expected by your server program. For example, if the enters the connection rate (because the connection duration is short, the traffic peak appears), then the ACCEPTEX that needs to be waiting is to be more than those that occasionally enter the client. Smart approach is to analyze traffic conditions by apps and adjust the number of AcceptEx waiting, rather than fixed on a certain quantity.
For Windows2000, Winsock provides some mechanisms to help you determine if the number of acceptex is sufficient. This is, create an event when creating a listener socket, and register the socket with this event with this event by wsaeventselect () API and register the FD_ACCEPT event notification. Once the system receives a connection request, if there is no acceptex () in the system waiting to be accepted, then the above event will receive a signal. With this incident, you can judge that you have enough AccePtex (), or detect an abnormal customer request (under the document). This mechanism does not apply to Windows NT 4.0.
One of the advantages of using Acceptex () is that you can complete two things to accept client connection requests and accept data (by transferring LPOUTPUTBUFFER parameters) through a call. That is, if the client transmits data while the connection is sent, your AcceptEx () call can return immediately after the connection creates and receives the client data. This may be useful, but it may also cause problems because all client data must be returned. Specifically, if you pass the LPOUTPUTBuffer parameters while sending an acceptex () call, AcceptEx () is no longer a atomic operation, but is divided into two steps: accept the customer connection, waiting to receive data. When a mechanism is missing to inform Your application: "Connection has been established, waiting for client data", which means that there is a possibility that the client only issues only a connection request, but does not send data. If your server receives too many of this type of connection, it refuses to connect more legal client requests. This is a common method of hackers to "denial service" attack.
To prevent such attacks, the thread that is accepted should check the AcceptEx () socket from time to time by calling the getSockopt () function (option parameter to SO_CONNECT_TIME). The entry value of the getSockopt () function will be set to the time of the socket being connected, or set to -1 (representing the socket has not been established). At this time, the characteristics of WSAEventSelect () can be used very well to do this. If the connection has been established, the data is not received for a long time, then the connection should be terminated, the method is to close the socket provided to AccePtex () as a parameter. Note that if the socket has been passed to AccePtex () and starting, then your application should not turn off their applications. This is because even if these sockets are closed, the data structure of the corresponding core mode is not cleaned before the system performance is improved, or before the connection enters itself, or the listening socket itself is turned off. The thread that is called by acceptex () seems to perform the port association operation, processing other I / O completion notifications, but don't forget that the thread should try to avoid the execution of the obstruction type. A side effect of Winsock2 hierarchical structure is to call the upper structure of the Socket () or WSASocket () API may be important (the translator does not understand the original meaning, sorry). Each acceptex () call requires a new socket, so it is best to have an independent thread to call acceptex () without participating in other I / O processing. You can also use this thread to perform other tasks, such as event records.
The last consideration for Acceptex (): To implement these APIs, do not require the Winsock2 implementation provided by other providers. This is equally applicable to Microsoft's unique API, such as transmitfile () and getacceptexsockaddrs (), and other APIs that may be added to the new version of Windows. On Windows NT and 2000, these APIs are in Microsoft's underlying provider DLL (Mswsock.dll) can be called by compiling connectivity to the MSWSock.lib, or dynamically obtain a pointer to function through WSAIOCTL () (option parameter is SiO_GET_EXTENSION_FUNCTION_POINTER).
If the function is called directly without the function pointer in advance (that is, the compile time is static connection Mswsock.lib, the function is directly called directly), the performance will be affected. Because AccePtex () is placed outside the Winsock2 architecture, it is forced to obtain function pointers through WSAIOCTL () each time. To avoid this performance loss, applications that need to use these APIs should be used to obtain a function of the function from the underlying provider by calling WSAIOCTL ().
See the Figure 3 socket architecture:
(Translator) Liu Xi SICKID10001@21cn.com
