P1: 50
Mayfield WL040/Bidgoli-Vol III-Ch-52 June 23, 2003 16:35 Char Count= 0
WINSOCKPROGRAMMING 639multithreaded and to place theacceptcall in a sec-
ondary thread (i.e., some thread other than the main
thread).
The client program that goes along with the server
program described above shares most of its same steps;
specifically, to transform the sequence into a client pro-
gram one simply replaces steps 5–7 with a single new step:
call the functionconnectfor the socket, indicating the IP
address and port number to which the connection is to be
made.WinSock-Related MFC Classes
To make WinSock 2 integrate better with MFC, Microsoft
has provided two MFC WinSock classes:CSocketand
its base classASyncSocket. The latter class mostly is
an MFC wrapper around aSOCKET, but it also provides
callback capabilities.CSocketis at a higher level of ab-
straction thanASyncSocket, and it is a blocking class. A
CSocketobject generally is used along with objects of two
other MFC Classes——CSocketFileandCArchive——
to simplify socket-based communication. The use of these
classes will be demonstrated in an example client–server
application later.Multithreaded Programming Issues
As mentioned earlier, a synchronous WinSock 2 program
contains a function call that blocks further execution in
the program until a connection has been made. In MFC
GUI programs, this is particularly problematic; while ex-
ecution is blocked, the user cannot communicate with
the user interface. For example, if a WinSock program
is blocked, the user can click on the “x” in the upper-right
corner of the main program window to close it, but the
program cannot and does not respond to the user inter-
action. For this reason, MFC WinSock programs almost
always are multithreaded. By placing the blocking call in
a separate thread from the GUI, the GUI can continue to
interact with the user (Beveridge & Wiener, 1997).Another pleasant benefit provided through multi-
threaded programming is that server applications can be
made to serve multiple client applications simultaneously.
This is demonstrated in the example applications that are
discussed in later sections.
Unfortunately, the use of multithreading and WinSock
together is itself problematic. Because of the way that
the Windows infrastructure is set up, complex MFC ob-
jects, such as views, documents, and sockets, cannot be
shared among threads. This usually means that these ob-
jects must be translated into handles, the thread proce-
dure must be started, and then in the thread the handles
must be transformed back into their respective objects—a
messy, but usable solution!An Example WinSock Server
The best way to learn to use WinSock with MFC (and,
for that matter, the best way to learn any programming
technique) is by doing. In this section and the follow-
ing section, an example client–server application is pre-
sented, step by step, to illustrate how one can use the
CSocketMFC class. In this case, the client contacts the
server, which then sends to the client, once every second,
a string that indicates the current date and time on the
server computer.Create the Server Project
Click on “New” from the IDE menu bar, and then select the
“Project” tab in the dialog box. Choose “MFC AppWizard
(exe)” as the type of project, and choose a project direc-
tory for the project name, as shown in Figure 4. (For the
duration of this description, it will be assumed that the
project is namedMFCServer.) Click on the “OK” button
to begin the AppWizard.
In the AppWizard, choose the single-document inter-
face (in AppWizard step 1), uncheck the “Printing and
print preview” checkbox (in step 4), check the “Windows
sockets” checkbox (in step 4), and chooseCEditViewFigure 4: Creating a project.