Asynchronous I/O models of wsaasyncselect and Windows clients

Why use wsaasynselect?
The I/O model of the server is usually the select, poll, epoll, or iocp, and AIO asynchronous I/O model. This is undoubtedly a reasonable choice on the server side. What about the client? Is it reasonable or necessary to use select or AIO? Considering that the client always needs a UI thread, if you need to use the above solution, it is troublesome to introduce another thread to do this work, communicate between threads, and synchronize resources. The multi-threaded design makesProgramIt becomes complicated and difficult to debug. Isn't it possible to use a single thread to implement the entire client? In fact, wsaasynselect provided in Windows can easily implement UI and asynchronous Io processing in a thread. Wsaasyncselect is a method that best suits windows operating models. It can map the socket messages to the message loop of the thread. This complies with the Windows philosophy of "Don't call me, I will call you.

 

How to Use wsaasynselect?
Specific usage refer to msdn: http://msdn.microsoft.com/en-us/library/ms741540
To put it simply, you specify a target window through this API and register the socket and IO events that you need to care about, system (ws2_32.dll) A message will be sent to your window after this event occurs. wsagetselectevent (lparam) can be used to obtain the network event itself, while wparam is used to pass the socket handle. Then, you can actively call the socket function to handle these events. However, the main body of a Windows application always needs a simple loop to process and distribute messages.

 

about casyncsocketex
This is an encapsulation class for the wsaasynselect method and can be easily added to SSL and Proxy Support. The base class of most Communication classes of eMule is it. It uses a Help window to easily integrate existing projects. For more information, see http://www.codeproject.com/kb/ip/casyncsocketex.aspx.