The Internet Encyclopedia (Volume 3)

P1: 50

Mayfield WL040/Bidgoli-Vol III-Ch-52 June 23, 2003 16:35 Char Count= 0

638 VISUALC++ (MICROSOFT)

Application

Frame Window

View

Document

Figure 3: Document/view architecture relationships.

Theapplication instancecontrols the application and

the interaction of the other components. The frame

windowis the main window, which includes the title bar,

borders, menu bar, tool bars, status bars, and the client

area. Thus, the frame window is the visual interface to

the user. Theview instancegenerally equates to the client

area of the frame; theclient areais the “white” area of

a window below the menu and tool bars. Thedocument

instanceis responsible for managing the data files and

other data stores of the application. One of the main re-

sponsibilities of the view is to act as a communication

conduit between the frame window and the document;

i.e. the view takes data from the document and displays it

in the frame window, and it takes user input from frame

components such as edit boxes and menu items and uses

the input to instruct the document on data manipulation.

Single-Document and Multiple-Document

Interfaces

Applications that follow the document/view architecture

can be categorized by the number of documents (and,

therefore, document instances) they can manipulate si-

multaneously. SDI (single-document interface) applica-

tions can have only one document open at a time. An ex-

ample SDI application is Microsoft Paint; it can have only

one image open at a time. Microsoft Word is an example of

an MDI (multiple-document interface) application; con-

ceptually, MS Word can have any number of documents

open at one time. The developer chooses whether an ap-

plication is SDI or MDI when running the AppWizard. In

both SDI and MDI applications, a document instance can

have one or more view instances associated with it so that

the document data can be viewed in different ways.

WINSOCK PROGRAMMING

A Little History

The WinSock API (Windows Sockets Application Pro-

gramming Interface) specification has at its core struc-

tures and functionality founded on the sockets network

programming model developed at the University of

California at Berkeley, plus extensions that make sockets

work with the Microsoft Windows messaging system. The

first widely accepted version of the specifications was

WinSock 1.1 (Hall, Towfiq, Arnold, Treadwell, & Sanders,

1993), which was released in 1993 to work with Microsoft

Windows 3.xand later versions of Windows. Windows

3.xwas a 16-bit operating system with no support for

multithreading, so certain limitations had to be observed

in WinSock 1.1. In 1996 the specifications for WinSock

2 were released, and they have since been refined into

the current WinSock 2.2.2 specifications (WinSock Group,

1997). Beginning with WinSock 2, support for the 16-bit

versions of Windows was discontinued. The specifications

were developed by the WinSock Group, made up of people

from many companies and educational institutions.

WinSock supports several types of sockets including

stream sockets(for use with TCP),datagram sockets(for

use with UDP), andraw sockets(for accessing low-level

communication protocols). There are two DLLs (dynam-

ically linked libraries) that contain the library code defin-

ing WinSock:WINSOCK.DLL(16-bit) andWSOCK32.DLL

(32-bit). Discussion here focuses on stream sockets using

the 32-bit WinSock 2.

WinSock Without MFC

The constructs and functionality found inWSOCK32.DLL

are not based on MFC, but rather on the Windows SDK

API (Quinn & Shute, 1995). The main data type provided

by this API isSOCKET, which is used to represent a socket

handle. Briefly, in a typical client–server application that

uses the WinSock 2 SDK API, the server program will con-

tain this basic sequence of events:

1. Initialize the WinSock DLL by calling the function
   WSAStartup;


2. Declare aSOCKETvariable;


3. Call the functionsocket, which creates a socket and
   returns its handle;


4. Assign the handle to theSOCKETvariable created ear-
   lier;


5. Bind the socket to an IP address and port number by
   calling thebindfunction;


6. Enable the socket to take connections by calling the
   listenfunction;


7. Wait for an incoming connection to the socket by call-
   ing theacceptfunction;


8. Send and receive data to and from the client program
   using the send andrecvfunctions, respectively;


9. Close the socket by calling theclosesocketfunction
   when data exchange has been completed; and


10. Terminate the WinSockDLLby calling the function
    WSACleanup.

It is important to note that the sequence given above

describes synchronous operation. Theacceptfunction

used in step 7 is a blocking call, meaning that further pro-

gram execution is blocked while the program waits for

a connection; this can lead to undesirable side effects.

As will be discussed and demonstrated later, the solu-

tion to the blocking problem is to make the program