Home | Overview | How Do I | Sample
This article illustrates, side by side, the sequence of operations for a server socket and a client socket. Because the sockets use CArchive objects, they are necessarily stream sockets.
Up to the point of constructing a CSocketFile object, the following sequence is accurate (with a few parameter differences) for both CAsyncSocket and CSocket. From that point on, the sequence is strictly for CSocket. The following table illustrates the sequence of operations for setting up communication between a client and a server.
Setting Up Communication Between a Server and a Client
| Server | Client |
// construct a socket
|
// construct a socket
|
// create the SOCKET
|
// create the SOCKET
|
// start listening
|
|
// seek a connection
|
|
// construct a new, empty socket
|
|
// construct file object
|
// construct file object
|
// construct an archive
-or-
– or Both – |
// construct an archive
-or-
– or Both – |
// use the archive to pass data:
-or-
|
// use the archive to pass data:
-or-
|
1. Where nPort is a port number. See Windows Sockets: Ports and Socket Addresses for details about ports.
2. The server must always specify a port so clients can connect. The Create call sometimes also specifies an address. On the client side, use the default parameters, which ask MFC to use any available port.
3. Where nPort is a port number and strAddr is a machine address or an Internet Protocol (IP) address.
4. Machine addresses can take several forms: “ftp.microsoft.com”, “ucsd.edu”. IP addresses use the “dotted number” form “127.54.67.32”. The Connect function checks to see if the address is a dotted number (although it doesn’t check to ensure the number is a valid machine on the network). If not, Connect assumes a machine name of one of the other forms.
5. When you call Accept on the server side, you pass a reference to a new socket object. You must construct this object first, but do not call Create for it. Keep in mind that if this socket object goes out of scope, the connection closes. MFC connects the new object to a SOCKET handle. You can construct the socket on the stack, as shown, or on the heap.
6. The archive and the socket file are closed when they go out of scope. The socket object’s destructor also calls the Close member function for the socket object when the object goes out of scope or is deleted.
The sequence of calls shown in the preceding table is for a stream socket. Datagram sockets, which are connectionless, don’t require the CAsyncSocket::Connect, Listen, and Accept calls (although you can optionally use Connect). Instead, if you’re using class CAsyncSocket, datagram sockets use the CAsyncSocket::SendTo and ReceiveFrom member functions. (If you use Connect with a datagram socket, you use Send and Receive.) Because CArchive doesn’t work with datagrams, don’t use CSocket with an archive if the socket is a datagram.
CSocketFile doesn’t support all of CFile’s functionality; CFile members such as Seek, which make no sense for a socket communication, are unavailable. Because of this, some default MFC Serialize functions aren’t compatible with CSocketFile. This is particularly true of the CEditView class. You should not try to serialize CEditView data through a CArchive object attached to a CSocketFile object using CEditView::SerializeRaw; use CEditView::Serialize instead (not documented). The SerializeRaw function expects the file object to have functions, such as Seek, that CSocketFile does not support.
See Also CSocket, CAsyncSocket::Create, CAsyncSocket::Close