Single Server, Multiple Clients - Win32/MFC classes for client/server communication with Unicode support

• Download demo project - 130 Kb

Introduction

This article presents a set of classes that are useful for client/server communication. These classes can be used in Win32 or MFC apps, and include Unicode support.

This article is based on Liyang Yu's excellent classes, which can be found here.

Porting to MFC and Unicode

Yu's original classes already supported Win32, but not Unicode. To be able to use these classes in both MFC and Win32 apps - either Unicode or ANSI - meant that all char variables and parameters had to be examined, and where necessary, converted to either TCHAR variables or LPCTSTR parameters. Of course, corresponding changes were required for string functions - e.g., converting strlen to _tcslen, etc.

Not all char variables were converted. Some functions still require use of char, because Winsock API is based on ANSI. Example: setsockopt.

Class Overview

There are five main classes:

• ssmcException - captures and reports errors.
• ssmcHostInfo - if you pass a host name to constructor, this class will tell you IP address, and if you pass in an IP address, it will tell you host name.
• ssmcSocket - this class encapsulates socket-related API calls into a generic socket class. The derived class ssmcTcpSocket wraps TCP-specific functionality.
• ssmcThread - this is a generic class that includes APIs to create and execute a thread.
• ssmcThreadData - main purpose of this class is to encapsulate data that thread needs. The derived classes ssmcClientThreadData and ssmcServerThreadData wrap data needed by server's client and server threads.

Concepts and Facilities

Yu has already described classes in his article, so I will focus here on how to use these classes in sample apps.

The data and control flow of socket-based systems is shown in following figure:

In client and server demo apps, messages are null-terminated strings. However, any type of data, including binary data, may be sent by these classes; of course, both client and server must understand data format.

In demo apps, client prepends each message with its thread ID. The server app expects this thread ID to be present, and removes it before echoing message back to client.

Server App

In Startup() function, following steps are performed:

1. Initialize Winsock library:

   ssmcTcpSocket::initialize();
   

2. Create server socket on local host:

   m_pServer = new ssmcTcpSocket(PORTNUM);
   

3. Create a server thread to implement server processing: listen to socket, accept client calls and communicate with clients. This will free the main thread to do other processing.

   m_pServerData = new ssmcServerThreadData(m_pServer, serverName);
   ssmcThread* pServerThread = new ssmcThread(ServerThread, (void*)m_pServerData);
   m_pServerData->setThreadHandle(pServerThread);
   pServerThread->execute();
   

   ServerThread() processing is diagrammed in following figure:

   

   In server thread, a new client thread is created each time server accepts a new client. The client thread processing is diagrammed in following figure:

   

4. The final thing Startup() function does is start a timer that will check for active clients and display count on server dialog.

The above steps are diagrammed in following figure:

Now that server thread has started, server is ready to accept new client connections.

The server app initially looks like this:

Client App

When user clicks Connect button, client app's StartClient() function is called:

The Send button is now enabled. When it's clicked, message is sent to server, which will echo it back to client:

After user connects and sends a message, client app looks like this:

and server app looks like:

Detecting Client Disconnect

A client might disconnect from server programmatically or because a program fault causes client app to exit. For either case, server's ClientThread() function will detect disconnect, set bClientIsFinished flag to true, and exit thread.

When it detects a client disconnect, server app looks like:

Detecting Server Disconnect

Unlike server app, client app is usually not doing a recv, and so detecting when server disconnects involves some extra work. In client app, this involves implementing a "ping" facility, where the client periodically sends a "ping" message to server.

When it detects a server disconnect, client app looks like:

Notice that ping checkbox is checked.

Sending Multiple Messages

The client app has been set up to allow more than one message to be sent. Each message includes a message number, so echoed message can be verified.

ANSI Clients and Unicode Clients

The demo project has both ANSI and Unicode build configurations. Regardless of whether server is ANSI or Unicode, it will correctly read and send messages. This works because a Unicode client prepends a Unicode header (Byte Order Mark, or BOM) to each message it sends. The server sees this BOM, and 1) interprets the message text as Unicode; and 2) sends back a Unicode message, with BOM. Obviously, this works fine for demo, because messages are always text strings.

Using BOM technique, a Unicode server can handle both ANSI and Unicode clients; and so can an ANSI server (try it and see).

How To Use

To integrate ssmc classes into your server app, you need to add following files to your project:

• ssmcException.cpp
• ssmcException.h
• ssmcHostInfo.cpp
• ssmcHostInfo.h
• ssmcSocket.cpp
• ssmcSocket.h
• ssmcThread.cpp
• ssmcThread.h
• ssmcThreadData.cpp
• ssmcThreadData.h
• XWSAError.h

To integrate ssmc classes into your client app, you need to add following files to your project:

• ssmcException.cpp
• ssmcException.h
• ssmcHostInfo.cpp
• ssmcHostInfo.h
• ssmcSocket.cpp
• ssmcSocket.h
• XWSAError.h

Both client and server need to be linked to XWSAError.lib, and XWSAError.dll needs to be in exe's directory when app is run.

For details on how to use ssmc classes, refer to code in mfc clientDlg.cpp and mfc serverDlg.cpp.

Acknowledgments

• Thanks to Liyang Yu for giving permission to port his code to MFC and Unicode: Single Server With Multiple Clients : a Simple C++ Implementation
• The XTrace code is based on an article by Paul Mclachlan, Getting around the need for a vararg #define just to automatically use __FILE__ and __LINE__ in a TRACE macro.
• Winsock error handling is taken from my article, XWSAError - a DLL for Winsock error lookup.
• The CXIPAddressCtrl class is taken from my article, XIPAddressCtrl - an enhanced IP address control based on CIPAddressCtrl.
• The CXListBox class is taken from my article, XListBox - Owner-draw CListBox with selectable text and background colors.
• The CXHyperLink class is taken from my article, XHyperLink - yet another hyperlink control.

Revision History

Version 1.0 - 2005 January 26

• Initial public release

Usage

This software is released into the public domain. You are free to use it in any way you like, except that you may not sell this source code. If you modify it or extend it, please to consider posting new code here for everyone to share. This software is provided "as is" with no expressed or implied warranty. I accept no liability for any damage or loss of business that this software may cause.