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:
To use CAsyncSocket
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:
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.
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.
-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.
See the Windows Sockets specification and class CAsyncSocket in the Class Library Reference.
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.
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:
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.