There are a number of ways for your applications to communicate with other applications through a network like the Internet. This chapter introduces you to the concepts involved with these programming techniques.
Before the Windows operating system even existed, the Internet existed. As it grew, it became the largest TCP/IP network in the world. The early sites were UNIX machines, and a set of conventions called Berkeley sockets became the standard for TCP/IP communication between UNIX machines on the Internet. Other operating systems implemented TCP/IP communications, too, which contributed immensely to the growth of the Internet. On those operating systems, things were starting to get messy, with a wide variety of proprietary implementations of TCP/IP, when a group of over 20 vendors banded together to create the Winsock specification.
The specification defines the interface to a DLL, typically called WINSOCK.DLL or WSOCK32.DLL. Vendors write the code for the functions themselves. Applications can call the functions, confident that the name, parameter meaning, and final behavior of the function is the same no matter which DLL is installed on the machine. For example, the DLLs included with Windows 95 and Windows NT are not the same at all, but a 32-bit Winsock application can run unchanged on a Windows 95 or Windows NT machine, calling the Winsock functions in the appropriate DLL.
| NOTE |
Winsock is not confined to TCP/IP communication. IPX/SPX support is the second protocol supported, and there will be others. For more information, check the Winsock specification itself. The Stardust Labs Winsock Resource Page at http://www.stardust.com/wsresource/ is a great starting point. |
An important concept in sockets programming is a socket's port. Every site on the Internet has a numeric address called an IP address, typically written as four numbers separated by dots: 198.53.145.3, for example. Programs running on that machine are all willing to talk, using sockets, to other machines. If a request arrives at 198.53.145.3, which program should handle it?
Requests arrive at the machine carrying a port number, a number from 1,024 up that indicates for which program the request is intended. Some port numbers are reserved for standard use; for example, port 80 is traditionally used by Web servers to listen for Web document requests from client programs like Hotjava or Netscape Navigator.
Most socket work is connection-based: the two programs form a connection with a socket at each end and then send and receive data along the connection. Some applications prefer to send the data without a connection, but there is no guarantee that this data arrives. The classic example is a time server that sends out the current time to every machine near it, constantly, without waiting until it is asked. The delay in establishing a connection might make the time sent through the connection outdated, so it makes sense in this case to use a connectionless approach.
At first, sockets programming in Visual C++ meant making API calls into the DLL. Many developers built socket classes to encapsulate these calls. Visual C++ 2.1 introduced two new classes: CAsyncSocket and CSocket, which inherits from CAsyncSocket. These classes handle the API calls for you, including the startup and cleanup calls that would otherwise be easy to forget.
Windows programming is asynchronous: there are lots of different things going on at the same time. In older versions of Windows, if one part of an application got stuck in a loop or otherwise hung up, the entire application-and sometimes the entire operating system-would stick or hang with it. This was obviously something to be avoided at all costs. Yet a socket call, perhaps a call to read some information through a TCP/IP connection to another site on the Internet, might take a long time to complete. (A function that is waiting to send or receive information on a socket is said to be blocking.) There are three ways around this problem:
Option 1 was not available until recently, and Option 2 is inefficient
under Windows. So most Winsock programming adopts Option 3. The
class CAsyncSocket implements this approach. For example,
to send a string across a connected socket to another site on
the Internet, you call that socket's Send() function.
Send() doesn't necessarily send any data at all; it tries
to, but if the socket isn't ready and waiting, Send()
just returns. When the socket is ready, a message is sent to the
socket window, which catches it and sends the data across. This
is called asynchronous Winsock programming.
| NOTE |
Winsock programming is not a simple topic; entire books have been written on it. One you might like to look at is Que's Developing Internet Applications in Visual C++. If you decide that this low-level sockets programming is the way to go, building standard programs is a good way to learn the process. n |
CAsyncSocket The CAsynchSocket class is a wrapper class for the asynchronous Winsock calls. It has a number of useful functions, which facilitate using the Winsock API. Table 13.1 lists the CASynchSocket member funtions and responsibility.
| Method Name | Description |
| Create | Create is the function you call to complete the initialization when the constructor constructs a blank socket. |
| Accept | Accept is how a listening socket handles an incoming connection, filling a new socket with the address information. |
| AsyncSelect | ASyncSelect requests that a Windows message be sent when a socket is ready. |
| Attach | Attach attaches a socket handle to a CAsyncSocket instance, so that it can form a connection to another machine. |
| Bind | Bind associates an address with a socket. |
| Close | Closes the socket. |
| Connect | Connects the socket to a remote address and port. |
| Create | Create completes the initialization process begun by the constructor. |
| Detach | Detaches a previously attached socket handle. |
| FromHandle | FromHandle is a static function that returns a pointer to whatever CAsyncSocket is attached to the handle it is passed. |
| GetLastError | GetlastError returns an error code and should be called after an operation fails, to find out why. |
| GetPeerName | GetPeerName is used to find the IP address and port number of the remote socket that the calling object socket is connected to, or to fill a socket address structure with that information. |
| GetSockName | GetSockName returns the IP address and port number of this socket, or fills a socket address structure with that information. |
| GetSockOpt | GetSockOpt returns the socket options that are currently set. |
| IOCtl | IOCtl sets the mode of the socket; most commonly, to blocking or nonblocking. |
| Listen | Listen instructs a socket to watch for incoming connections. |
| OnAccept | OnAccept, a virtual function often overridden by derived classes, handles the Windows message generated when a socket has a incoming connection to accept. |
| OnClose | OnClose, a virtual function often overridden by derived classes, handles the Windows message generated when a socket closes. |
| OnConnect | OnConnect, a virtual function often overridden by derived classes, handles the Windows message generated when a socket becomes connected or has a connection attempt end in failure. |
| OnOutOfBandData | OnOutOfBandData, a virtual function often overridden by derived classes, handles the Windows message generated when a socket has urgent, out-of-band data ready to read. |
| OnReceive | onReceive, a virtual function often overridden by derived classes, handles the Windows message generated when a socket has data that could be read with Receive(). |
| OnSend | OnSend, a virtual function often overridden by derived classes, handles the Windows message generated when a socket is ready to accept data that could be sent with Send(). |
| Receive | Receive reads data from the remote socket to which this socket is connected. |
| ReceiveFrom | ReceiveFrom reads a datagram from a connectionless remote socket. ( A datagram is one of two types of sockets, which supports a bidirectional flow of data but is potentially unsequenced and duplicated.) |
| Send | Send sends data to the remote socket to which this socket is connected. |
| SendTo | SendTo sends a datagram without a connection. |
| SetSockOpt | SetSocketOpt sets socket options. |
| ShutDown | ShutDown keeps the socket open but prevents any further send or receive calls. |
If you use the CASynchSocket class, you will have to fill the socket address structures yourself, and many developers would rather delegate a lot of this work. In that case, CSocket is a better socket class.
CSocket CSocket inherits from CAsyncSocket and so has all the functions listed for CAsyncSocket. Table 13.2 describes the new methods added in the derived Csocket class.
| Method Name | Description |
| Create | Create is the function you call to complete the initialization when the constructor constructs a blank socket. |
| IsBlocking | IsBlocking returns TRUE if the socket is blocking at the moment, waiting for something to happen. |
| CancelBlockingCall | CancelBlockingCall cancels whatever request had left the socket blocking. |
| OnMessagePending | OnMessagePending, a virtual function often overridden by derived classes, handles the Windows messages generated for other parts of your application while the socket is blocking. |
CSocket is derived from CASynchSocket and adds the methods listed in the table.
CSocket overrides the virtual methods Attach() and FromHandle().
In the \MSDev\Samples\SDK\Win32\WSock directory, the demo program wsock.exe can be compiled and used to experiment with WINSOCK.DLL APIs directly. (You will have to open a workspace using the Makefile and build WSock.exe.) More than likely you will be interested in using the CSocket classes. There are two fun demo programs that you can use and modify to experiment with CSocket, they are Chatter and ChatSrvr. Chatter.exe can be built from the project in the \MSDev\samples\MFC\Advanced\Chatter directory and ChatSrvr.exe is located in the \MSDev\samples\MFC\Advanced\ChatSrvr directory.
Each session of Chatter emulates a user server. The ChatSrvr program is the client traffic manager. To experiment with each, run ChatSrvr using the default Channel value of 0 in the sign-on. For each session of Chatter you will need a user name, like your first name, a server name, "localhost" works fine, and the same Channel number you used for the ChatSrvr value. Each Chatter can send messages to the ChatSrvr-by typing in some text-and the ChatSrvr sends the message to everyone logged into the session. Refer to the source code in \MSDev\ samples\MFC\Advanced\Chatter\ChatDoc.Cpp to see examples of CSocket member functions in action.There are existing connectivity protocols like Microsoft mail, the World Wide Web, or FTP you will not have to implement socket connectivity from scratch.
The most popular networking feature in most offices is electronic mail. You could add code to your application to generate the right commands over a socket to transmit a mail message, but it's simpler to build on the work of others.
MAPI is a way of pulling together applications that need to send and receive messages (messaging applications) with applications that know how to send and receive messages (messaging services and service providers,) in order to lower the work load of all the developers involved. Figure 13.1 shows the scope of MAPI. Note that the word messaging actually covers far more than just electronic mail: a MAPI service could send a fax or voice-mail message rather than an electronic-mail message. If your application uses MAPI, the messaging services such as e-mail clients that the user has installed will carry out the work of sending the messages that your application generates.
Figure 13.1 : The Messaging API covers applications that need messaging and those that provide it.
The extent to which an application uses messaging varies through a wide range:
The number-one reason for a developer to make an application messaging aware is to meet the requirements of the Windows 95 Logo program. To qualify for the logo, an application must have a Send item on the File menu that uses MAPI to send the document. (Exceptions are granted to applications without documents.)
To add this feature to your applications, it's best to think of it before you create the empty shell with AppWizard. If you are planning ahead, here is a list of all the work you have to do to meet this part of the logo requirement:
In Step 4 of AppWizard, select the MAPI (Messaging API) check box.
That's it! The menu item is added, and message maps and functions are generated to catch the menu item and call functions that use your Serialize() function to send the document through MAPI. Figure 13.2 shows an application called MAPIDemo, included on the book's CD-ROM, that is just an AppWizard empty shell.
No additional code was added, beyond the code generated by the AppWizard, to this application, and the Send item is on the File menu, as you can see. If you choose this menu item, your MAPI mail client is launched to send the message. Figures 13.2 and 13.3 were captured on a machine with Microsoft Exchange installed as an Internet mail client, and so it is Microsoft Exchange that is launched, as shown in Figure 13.3.
| TIP |
If the Send item does not appear on your menu, make sure that you have a MAPI client installed. Microsoft Exchange is an easy-to-get MAPI client. The OnUpdateFileSendMail() function removes the menu item Send from the menu if no MAPI client is registered on your computer. |
If you didn't enter Microsoft Exchange (for example) prior to executing the AppWizard, here are the steps to follow which will manually add the Send item:
ON_COMMAND(ID_FILE_SEND_MAIL, OnFileSendMail) ON_UPDATE_COMMAND_UI(ID_FILE_SEND_MAIL, OnUpdateFileSendMail)
Adding the mail support to your application manually is not much harder than being prepared-having a mail server configured-ahead of time so the AppWizard does it.
If you want more from MAPI than just meeting the logo requirements, things do get harder. There are actually four kinds of MAPI client interfaces:
Common Messaging Calls There are only ten functions in the CMC API. That makes it easy to learn, yet packs enough punch to get the job done. They are the following:
The header file XCMC.H declares a number of structures used to hold the information that is passed to these functions. For example, recipient information is kept in this structure:
/*RECIPIENT*/
typedef struct {
CMC_string name;
CMC_enum name_type;
CMC_string address;
CMC_enum role;
CMC_flags recip_flags;
CMC_extension FAR *recip_extensions;
} CMC_recipient;
You could fill this structure with the name and address of the recipient of a mail message by using a standard dialog box or by hard-coding the entries, like this:
CMC_recipient recipient = {
"Kate Gregory",
CMC_TYPE_INDIVIDUAL,
"SMTP:kate@gregcons.com",
CMC_ROLE_TO,
CMC_RECIP_LAST_ELEMENT,
NULL };
The type, role, and flags use one of these predefined values:
Listing 13.1 (Excerpt from \MSDev\Include\XCMC.H) Command Definitions /* NAME TYPES */
#define CMC_TYPE_UNKNOWN ((CMC_enum) 0) #define CMC_TYPE_INDIVIDUAL ((CMC_enum) 1) #define CMC_TYPE_GROUP ((CMC_enum) 2) /* ROLES */ #define CMC_ROLE_TO ((CMC_enum) 0) #define CMC_ROLE_CC ((CMC_enum) 1) #define CMC_ROLE_BCC ((CMC_enum) 2) #define CMC_ROLE_ORIGINATOR ((CMC_enum) 3) #define CMC_ROLE_AUTHORIZING_USER ((CMC_enum) 4) /* RECIPIENT FLAGS */ #define CMC_RECIP_IGNORE ((CMC_flags) 1) #define CMC_RECIP_LIST_TRUNCATED ((CMC_flags) 2) #define CMC_RECIP_LAST_ELEMENT ((CMC_flags) 0x80000000)
There is a message structure you could fill in the same way, or by presenting the user with a dialog to enter the message details. This structure includes a pointer to the recipient structure you have already filled. Your program then calls cmc_logon( ), cmc_send( ), and cmc_logoff( to complete the process.
Extended MAPI Extended MAPI is based on COM, the OLE Component Object Model. Messages, recipients, and many other entities are defined as objects rather than as C structures. There are far more object types in Extended MAPI than there are structure types in CMC. Access to these objects is through OLE interfaces. The objects expose properties, methods, and events. These concepts are discussed in Part IV, Chapter 25, "ActiveX Automation" and Chapter 26, "Building an ActiveX Control."
OLE Messaging If you understand OLE Automation (described in Chapter 24, "Building an ActiveX Server Application"), then you will easily understand OLE Messaging. Your application must be an OLE Automation client, however, and building such a client is beyond the scope of this chapter. Some ways to use ActiveX Messaging are in Visual Basic programming and VBA scripts for programs like Excel. Your program would set up objects and then set their exposed properties (for example, the subject line of a message object) and invoke their exposed methods (for example, the Send() method of a message object.)
The objects used in OLE Messaging include the following:
A detailed reference of these objects, as well as their properties and methods, can be found in Visual C++ Books Online (the help files) from within Developer Studio. Follow the Books Online hierarchy: SDKs, Win32 SDK, Win32 Messaging (MAPI), OLE Messaging Library.
MFC 4.2 adds a number of new classes that eliminate the need to learn socket programming when your applications need to access standard Internet client services. Figure 13.4 shows the way these classes relate to each other. Collectively known as the WinInet classes, they are the following:
Figure 13.4 : The WinInet classes make writing Internet client programs easier.
| TIP |
These classes help you write Internet client applications, with which users interact directly. If you want to write server applications, which interact with client applications, you'll be interested in ISAPI, discussed in the next section. |
First, your program establishes a session by creating a CInternetSession. Then, if you have a Uniform Resource Locator (URL) to a Gopher, FTP, or Web (HTTP) resource, you can call that session's OpenURL() function to retrieve the resource as a read-only CInternetFile. Your application can read the file using CStdioFile functions and manipulate that data in whatever way you need.
If you do not have a URL or do not want to retrieve a read-only file, you proceed differently after establishing the session. You make a connection with a specific protocol by calling the session's GetFtpConnection(), GetGopherConnection(), or GetHttpConnection() functions, which return the appropriate connection object. You then call the connection's OpenFile() function. CFtpConnection::OpenFile() returns a CInternetFile; CGopherConnection:: OpenFile() returns a CGopherFile; and CHttpConnection::OpenFile() returns a CHttpFile. The CFileFind class and its derived classes help you find the file you wish to open.
Chapter 27, "Internet Programming with the WinInet Classes," works through an example client program using WinInet classes to establish an Internet session and retrieve information.
| NOTE |
Though e-mail is a standard Internet application, you'll notice that the WinInet classes do not have any e-mail functionality. That's because e-mail is handled by MAPI. There is no support for USENET news either, in the WinInet classes or elsewhere. |
ISAPI is used to enhance and extend the capabilities of your HTTP (World Wide Web) server. ISAPI developers produce extensions and filters. Extensions are DLLs that are invoked by a user from a Web page in much the same way as CGI applications are invoked from a Web page. Filters are DLLs that run with the server and look at or change the data going to and from the server. For example, a filter might redirect requests for one file to a new location.
| NOTE |
In order for the ISAPI extensions and filters that you write to be useful, your Web pages must be kept on a server that is running as ISAPI-compliant server like the Microsoft IIS Server. You must have permission to install DLLs onto the server, and for an ISAPI filter, you must be able to change the Registry on the server. If your Web pages are kept on a machine administered by your Internet Service Provider (ISP), you will probably not be able to use ISAPI to bring more power to your web pages. You may choose to move your pages to a dedicated server (a powerful Intel machine running Windows NT Server 4.0 and Microsoft IIS is a good combination) so that you can use ISAPI, but this will involve considerable expense. Make sure that you understand the constraints of your current Web server before embarking on a project with ISAPI. One of the major advantages of ActiveX controls for the Internet (discussed in Chapter 28, "Building an Internet ActiveX Control") is that you do not need access to the server in order to implement them. |
The five MFC ISAPI classes form a wrapper for the API to make it easier to use. Here they are:
You application will have a server or a filter class (or both) that inherit from CHttpServer or CHttpFilter. These are rather like the classes in a normal application that inherit from CWinApp. There is only one instance of the class in each DLL, and each interaction of the server with a client is done through its own instance of the appropriate context class. (A DLL may contain both a server and a filter, but at most, one of each.) CHtmlStream is a helper class that describes a stream of HTML to be sent by a server to a client.
The ISAPI Extension Wizard is an AppWizard that simplifies creating extensions and filters. To use this wizard, choose File, New, as always, and then Project Workspace. Scroll down the list on the left and select ISAPI Extension Wizard (as shown in Figure 13.5) and then fill in the project name and folder.
Figure 13.5 : The ISAPI Extension Wizard is another kind of AppWizard.
Creating a server extension is a one-step process. That step, which is also the first step for a filter, is shown in Figure 13.6. The names and descriptions for the filter and extension are based on the project name that you chose. If you use the Back button to change the project name, these names are not changed automatically. You can edit the names as you wish.
| Caution |
Selecting the Back button in ISAPI Extension Wizard will not change the names and descriptions; you will have to do this manually. |
If you choose to create a filter, the Next button is enabled and you can move to the second step for filters, shown in Figure 13.7. This list of parameters gives you an idea of the power of an ISAPI filter. You can monitor all incoming and outgoing requests and raw data, authenticate users, log traffic, and more.
Figure 13.7 : The second step in the ISAPI Extension Wizard process is to set filter parameters.
AppWizard shows you a final confirmation screen like the one in Figure 13.8 before creating the files. When you create a server and a filter at the same time, 11 files are created for you, including source and headers for the class that inherits from CHttpServer and the class that inherits from CHttpFilter.
Figure 13.8 : The ISAPI Extension Wizard process summarizes the files that will be created.
Writing a filter from this shell is quite simple. You have been provided with a stub function to react to each event for which notification was requested. For example, the filter class has a function called OnEndOfNetSession(), which is called when a client's session with this server is ending. You add code to this function to log, monitor, or otherwise react to this event. When the filter is complete, you edit the Registry by hand so that the server will run your DLL.
To write an extension, add one or more functions to your DLL. Each function will be passed a CHttpContext pointer, which can be used to gather information such as the user's IP address. If the function is invoked from an HTML form, additional parameters such as values of other fields on the form will also be passed to the function.
The details of what the function does depend on your application. If you are implementing an online ordering system, the functions involved will be lengthy and complex. Other extensions will be simpler.
When the function is complete, you place the DLL in the executable folder for the server-usually the folder where CGI programs are kept-and adjust your Web pages so that they include links to your DLL, like this:
Now you can <A HREF=http://www.company.com/exec/orders.dll> place an order</A> online!
For more information on ISAPI programming, look for Que's new book, SE: Using ISAPI, due in January 1997.
Adding the Internet to your applications is an exciting trend. It's going to make lots of work for programmers and create some powerful products that simplify the working life of anyone with an Internet connection. Just a year ago, writing Internet applications meant getting your fingernails dirty with sockets programming, memorizing TCP/IP ports, and reading RFCs. The new WinInet and ISAPI classes, as well as improvements to the old MAPI support, mean that today you can add amazing power to your application with just a few lines of code or by selecting a box on an AppWizard dialog box.
To learn more about using the APIs introduced in this chapter and building other specific kinds of applications refer to: