Windows Sockets: Using Class CAsyncSocket

Home |  Overview |  How Do I |  Sample

This article explains how to use class CAsyncSocket. Be aware that this class encapsulates the Windows Sockets API at a very low level. CAsyncSocket is for use by programmers who know network communications in detail but want the convenience of callbacks for notification of network events. Based on this assumption, this article provides only basic instruction. You should probably consider using CAsyncSocket if you want Windows Sockets’ ease of dealing with multiple network protocols in an MFC application but don’t want to sacrifice flexibility. You might also feel that you can get better efficiency by programming the communications more directly yourself than you could using the more general alternative model of class CSocket.

CAsyncSocket is documented in the Class Library Reference. Visual C++ also supplies the Windows Sockets specification, located in the Win32 SDK. The details are left to you. Visual C++ does not supply a sample application for CAsyncSocket.

If you aren’t highly knowledgeable about network communications and want a simple solution that shields you from most of the details, use class CSocket with a CArchive object. See the article Windows Sockets: Using Sockets with Archives.

This article covers:

• Creating and using a CAsyncSocket object.
• Your responsibilities with CAsyncSocket.

Creating and Using a CAsyncSocket Object

To use CAsyncSocket

1. Construct a CAsyncSocket object and use the object to create the underlying SOCKET handle.

   Creation of a socket follows the MFC pattern of two-stage construction.

   For example:

   CAsyncSocket sock;
   sock.Create( );    // Use the default parameters
   

   -or-

   CAsyncSocket* pSocket = new CAsyncSocket;
   int nPort = 27;
   pSocket->Create( nPort, SOCK_DGRAM );
   

   The first constructor above creates a CAsyncSocket object on the stack. The second constructor creates a CAsyncSocket on the heap. The first Create call above uses the default parameters to create a stream socket. The second Create call creates a datagram socket with a specified port and address. (You can use either Create version with either construction method.)

   The parameters to Create are:

   • A “port”: a short integer.

     For a server socket, you must specify a port. For a client socket, you’ll typically accept the default value for this parameter, which lets Windows Sockets select a port.

   • A socket type: SOCK_STREAM (the default) or SOCK_DGRAM.
   • A socket “address,” such as “ftp.microsoft.com” or “128.56.22.8”.

     This is your Internet Protocol (IP) address on the network. You’ll probably always rely on the default value for this parameter.

   The terms “port” and “socket address” are explained in the article Windows Sockets: Ports and Socket Addresses.

2. If the socket is a client, connect the socket object to a server socket, using CAsyncSocket::Connect.

   -or-

   If the socket is a server, set the socket to begin listening (with CAsyncSocket::Listen) for connect attempts from a client. Upon receiving a connection request, accept it with CAsyncSocket::Accept.

   After accepting a connection, you can perform such tasks as validating passwords.

   Note   The Accept member function takes a reference to a new, empty CSocket object as its parameter. You must construct this object before you call Accept. Keep in mind that if this socket object goes out of scope, the connection closes. Do not call Create for this new socket object. For an example, see the article Windows Sockets: Sequence of Operations.

3. Carry out communications with other sockets by calling the CAsyncSocket object’s member functions that encapsulate the Windows Sockets API functions.

   See the Windows Sockets specification and class CAsyncSocket in the Class Library Reference.

4. Destroy the CAsyncSocket object.

   If you created the socket object on the stack, its destructor is called when the containing function goes out of scope. If you created the socket object on the heap, using the new operator, you are responsible for using the delete operator to destroy the object.

   The destructor calls the object’s Close member function before destroying the object.

For an example of this sequence in code (actually for a CSocket object), see the article Windows Sockets: Sequence of Operations.

Your Responsibilities with CAsyncSocket

When you create an object of class CAsyncSocket, the object encapsulates a Windows SOCKET handle and supplies operations on that handle. When you use CAsyncSocket, you must deal with all of the issues you might face if using the API directly. For example:

• “Blocking” scenarios
• Byte order differences between the sending and receiving machines
• Converting between Unicode and multibyte character set (MBCS) strings

For definitions of these terms and additional information, see the articles Windows Sockets: Blocking, Windows Sockets: Byte Ordering, Windows Sockets: Converting Strings.

Despite these issues, class CAsycnSocket may be the right choice for you if your application requires all the flexibility and control you can get. If not, you should consider using class CSocket instead. CSocket hides a lot of detail from you: it pumps Windows messages during blocking calls and gives you access to CArchive, which manages byte order differences and string conversion for you.

What do you want to know more about?

• Windows Sockets: Background
• Windows Sockets: Stream Sockets
• Windows Sockets: Datagram Sockets