Parameters
sListenSocket
A descriptor identifying a socket that has already been called with the listen function. A server application waits for attempts to connect on this socket.

sAcceptSocket
A descriptor identifying a socket on which to accept an incoming connection. This socket must not be bound or connected.

lpOutputBuffer
A pointer to a buffer that receives the first block of data sent on a new connection, the local address of the server, and the remote address of the client. The receive data is written to the first part of the buffer starting at offset zero, while the addresses are written to the latter part of the buffer. This parameter must be specified.

dwReceiveDataLength
The number of bytes in lpOutputBuffer that will be used for actual receive data at the beginning of the buffer. This size should not include the size of the local address of the server, nor the remote address of the client; they are appended to the output buffer. If dwReceiveDataLength is zero, accepting the connection will not result in a receive operation. Instead, AcceptEx completes as soon as a connection arrives, without waiting for any data.

dwLocalAddressLength
The number of bytes reserved for the local address information. This value must be at least 16 bytes more than the maximum address length for the transport protocol in use.

dwRemoteAddressLength
The number of bytes reserved for the remote address information. This value must be at least 16 bytes more than the maximum address length for the transport protocol in use. Cannot be zero.

lpdwBytesReceived
A pointer to a DWORD that receives the count of bytes received. This parameter is set only if the operation completes synchronously. If it returns ERROR_IO_PENDING and is completed later, then this DWORD is never set and you must obtain the number of bytes read from the completion notification mechanism.

lpOverlapped
An OVERLAPPED structure that is used to process the request. This parameter must be specified; it cannot be NULL.

Return Value
If no error occurs, the AcceptEx function completed successfully and a value of TRUE is returned.

If the function fails, AcceptEx returns FALSE. The WSAGetLastError function can then be called to return extended error information. If WSAGetLastError returns ERROR_IO_PENDING, then the operation was successfully initiated and is still in progress. If the error is WSAECONNRESET, an incoming connection was indicated, but was subsequently terminated by the remote peer prior to accepting the call.

Remarks


The AcceptEx function combines several socket functions into a single API/kernel transition. The AcceptEx function, when successful, performs three tasks:

A new connection is accepted.
Both the local and remote addresses for the connection are returned.
The first block of data sent by the remote is received.

Note  The function pointer for the AcceptEx function must be obtained at run time by making a call to the WSAIoctl function with the SIO_GET_EXTENSION_FUNCTION_POINTER opcode specified. The input buffer passed to the WSAIoctl function must contain WSAID_ACCEPTEX, a globally unique identifier (GUID) whose value identifies the AcceptEx extension function. On success, the output returned by the WSAIoctl function contains a pointer to the AcceptEx function. The WSAID_ACCEPTEX GUID is defined in the Mswsock.h header file.

A program can make a connection to a socket more quickly using AcceptEx instead of the accept function.

A single output buffer receives the data, the local socket address (the server), and the remote socket address (the client).

Using a single buffer improves performance. When using AcceptEx, the GetAcceptExSockaddrs function must be called to parse the buffer into its three distinct parts (data, local socket address, and remote socket address). On Windows XP and later, once the AcceptEx function completes and the SO_UPDATE_ACCEPT_CONTEXT option is set on the accepted socket, the local address associated with the accepted socket can also be retrieved using the getsockname function. Likewise, the remote address associated with the accepted socket can be retrieved using the getpeername function.

The buffer size for the local and remote address must be 16 bytes more than the size of the sockaddr structure for the transport protocol in use because the addresses are written in an internal format. For example, the size of a sockaddr_in (the address structure for TCP/IP) is 16 bytes. Therefore, a buffer size of at least 32 bytes must be specified for the local and remote addresses.

The AcceptEx function uses overlapped I/O, unlike the accept function. If your application uses AcceptEx, it can service a large number of clients with a relatively small number of threads. As with all overlapped Windows functions, either Windows events or completion ports can be used as a completion notification mechanism.



Another key difference between the AcceptEx function and the accept function is that AcceptEx requires the caller to already have two sockets:

One that specifies the socket on which to listen.
One that specifies the socket on which to accept the connection.
The sAcceptSocket parameter must be an open socket that is neither bound nor connected.

The lpNumberOfBytesTransferred parameter of the GetQueuedCompletionStatus function or the GetOverlappedResult function indicates the number of bytes received in the request.



When this operation is successfully completed, sAcceptSocket can be passed, but to the following functions only:

ReadFile
WriteFile
send
WSASend
recv
WSARecv
TransmitFile
closesocket
setsockopt (only for SO_UPDATE_ACCEPT_CONTEXT) Note  If the TransmitFile function is called with both the TF_DISCONNECT and TF_REUSE_SOCKET flags, the specified socket has been returned to a state in which it is neither bound nor connected. The socket handle can then be passed to the AcceptEx function in the sAcceptSocket parameter, but the socket cannot be passed to the ConnectEx function.

When the AcceptEx function returns, the socket sAcceptSocket is in the default state for a connected socket. The socket sAcceptSocket does not inherit the properties of the socket associated with sListenSocket parameter until SO_UPDATE_ACCEPT_CONTEXT is set on the socket. Use the setsockopt function to set the SO_UPDATE_ACCEPT_CONTEXT option, specifying sAcceptSocket as the socket handle and sListenSocket as the option value.


For example:
err = setsockopt( sAcceptSocket,     SOL_SOCKET,     SO_UPDATE_ACCEPT_CONTEXT,     (char *)&sListenSocket,     sizeof(sListenSocket) );
If a receive buffer is provided, the overlapped operation will not complete until a connection is accepted and data is read. Use the getsockopt function with the SO_CONNECT_TIME option to check whether a connection has been accepted. If it has been accepted, you can determine how long the connection has been established. The return value is the number of seconds that the socket has been connected. If the socket is not connected, the getsockopt returns 0xFFFFFFFF. Applications that check whether the overlapped operation has completed, in combination with the SO_CONNECT_TIME option, can determine that a connection has been accepted but no data has been received. Scrutinizing a connection in this manner enables an application to determine whether connections that have been established for a while have received no data. It is recommended such connections be terminated by closing the accepted socket, which forces the AcceptEx function call to complete with an error.


For example:

INT seconds; INT bytes = sizeof(seconds); err = getsockopt( sAcceptSocket, SOL_SOCKET, SO_CONNECT_TIME,                       (char *)&seconds, (PINT)&bytes ); if ( err != NO_ERROR ) {     printf( "getsockopt(SO_CONNECT_TIME) failed: %ld\n", WSAGetLastError( ) );     exit(1); }
Note   All I/O initiated by a given thread is canceled when that thread exits. For overlapped sockets, pending asynchronous operations can fail if the thread is closed before the operations complete. See ExitThread for more information.

Example Code

The following example uses the AcceptEx function using overlapped I/O and completion ports.

#include <stdio.h> #include "winsock2.h" #include "mswsock.h" void main() {   //----------------------------------------   // Declare and initialize variables   WSADATA wsaData;   HANDLE hCompPort;   LPFN_ACCEPTEX lpfnAcceptEx = NULL;   GUID GuidAcceptEx = WSAID_ACCEPTEX;   WSAOVERLAPPED olOverlap;      SOCKET ListenSocket, AcceptSocket;   sockaddr_in service;   char lpOutputBuf[1024];   int outBufLen = 1024;   DWORD dwBytes;   //----------------------------------------   // Initialize Winsock   int iResult = WSAStartup( MAKEWORD(2,2), &wsaData );   if( iResult != NO_ERROR )     printf("Error at WSAStartup\n");   //----------------------------------------   // Create a handle for the completion port   hCompPort = CreateIoCompletionPort( INVALID_HANDLE_VALUE, NULL, (u_long)0, 0 );   //----------------------------------------   // Create a listening socket   ListenSocket = socket( AF_INET, SOCK_STREAM, IPPROTO_TCP );   if (ListenSocket == INVALID_SOCKET) {     printf("Error at socket(): ListenSocket\n");     WSACleanup();     return;   }   //----------------------------------------   // Associate the listening socket with the completion port   CreateIoCompletionPort((HANDLE)ListenSocket, hCompPort, (u_long)0, 0);   //----------------------------------------   // Bind the listening socket to the local IP address   // and port 27015   hostent* thisHost;   char* ip;   u_short port;   port = 27015;   thisHost = gethostbyname("");   ip = inet_ntoa (*(struct in_addr *)*thisHost->h_addr_list);   service.sin_family = AF_INET;   service.sin_addr.s_addr = inet_addr(ip);  service.sin_port = htons(port);   if ( bind( ListenSocket,(SOCKADDR*) &service, sizeof(service) )  == SOCKET_ERROR ) {     printf("bind failed\n");     closesocket(ListenSocket);     return;   }   //----------------------------------------   // Start listening on the listening socket   if (listen( ListenSocket, 100 ) == SOCKET_ERROR) {     printf("error listening\n");   }   printf("Listening on address: %s:%d\n", ip, port);   //----------------------------------------   // Load the AcceptEx function into memory using WSAIoctl.   // The WSAIoctl function is an extension of the ioctlsocket()   // function that can use overlapped I/O. The function's 3rd   // through 6th parameters are input and output buffers where   // we pass the pointer to our AcceptEx function. This is used   // so that we can call the AcceptEx function directly, rather   // than refer to the Mswsock.lib library.   WSAIoctl(ListenSocket,     SIO_GET_EXTENSION_FUNCTION_POINTER,     &GuidAcceptEx,     sizeof(GuidAcceptEx),     &lpfnAcceptEx,     sizeof(lpfnAcceptEx),     &dwBytes,     NULL,     NULL);   //----------------------------------------   // Create an accepting socket   AcceptSocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);   if (AcceptSocket == INVALID_SOCKET) {     printf("Error creating accept socket.\n");     WSACleanup();     return;   }   //----------------------------------------   // Empty our overlapped structure and accept connections.   memset(&olOverlap, 0, sizeof(olOverlap));   lpfnAcceptEx(ListenSocket,     AcceptSocket,     lpOutputBuf,     outBufLen - ((sizeof(sockaddr_in) + 16) * 2),     sizeof(sockaddr_in) + 16,     sizeof(sockaddr_in) + 16,     &dwBytes,     &olOverlap);   //----------------------------------------   // Associate the accept socket with the completion port   CreateIoCompletionPort((HANDLE)AcceptSocket, hCompPort, (u_long)0, 0);   //----------------------------------------   // Continue on to use send, recv, TransmitFile(), etc.,.   ... }
Notes for QOS
The TransmitFile function allows the setting of two flags, TF_DISCONNECT or TF_REUSE_SOCKET, that return the socket to a "disconnected, reusable" state after the file has been transmitted. These flags should not be used on a socket where quality of service has been requested, since the service provider may immediately delete any quality of service associated with the socket before the file transfer has completed. The best approach for a QOS-enabled socket is to simply call the closesocket function when the file transfer has completed, rather than relying on these flags.

Notes for ATM
There are important issues associated with connection setup when using Asynchronous Transfer Mode (ATM) with Windows Sockets 2. Please see the Remarks section in the accept function documentation for important ATM connection setup information.

Requirements
Client Requires Windows Vista, Windows XP, Windows 2000 Professional, or Windows NT Workstation 3.51 and later.
Server Requires Windows Server 2008, Windows Server 2003, Windows 2000 Server, or Windows NT Server 3.51 and later.
Header Declared in Mswsock.h.

Library Use Mswsock.lib.

DLL Requires Mswsock.dll.


如果你想它連接上就立即提示連接完成，則只須將dwReceiveDataLength賦0就OK.

使用AcceptEx()的一大好處是，
你可以通過一次調(diào)用就完成接受客戶端連接請(qǐng)求和接受數(shù)據(jù)(通過傳送lpOutputBuffer參數(shù))兩件事情。
也就是說，如果客戶端在發(fā)出連接的同時(shí)傳輸數(shù)據(jù)，
你的AcceptEx()調(diào)用在連接創(chuàng)建并接收了客戶端數(shù)據(jù)后就可以立刻返回。
這樣可能是很有用的，但是也可能會(huì)引發(fā)問題，因?yàn)锳cceptEx()必須等全部客戶端數(shù)據(jù)都收到了才返回。
具體來說，如果你在發(fā)出AcceptEx()調(diào)用的同時(shí)傳遞了 lpOutputBuffer參數(shù)，那么AcceptEx()不再是一項(xiàng)原子型的操作，
而是分成了兩步：接受客戶連接，等待接收數(shù)據(jù)。當(dāng)缺少一種機(jī)制來通知你的應(yīng)用程序所發(fā)生的這種情況：“連接已經(jīng)建立了，正在等待客戶端數(shù)據(jù)”，這將意味著有可能出現(xiàn)客戶端只發(fā)出連接請(qǐng)求，但是不發(fā)送數(shù)據(jù)。