1. Purpose
Simple and fast communication between all types of MFC Applications on a single or multiple computers in
Windows NT.
2. Main features
- Data transmission from Clients to Server, their processing and results return, if needed.
- Data transmission from Server to Clients informing them about any event.
- Different schemes of buffer allocations.
- Automatic Server loading.
- Automatic Server termination without Clients, if needed.
- Utilities for registration, automatic loading, tracing and Wizard.
3. Introduction
Several years ago I wrote classes using Mailslots for communication between Clients and Server.
According to the project requirements these classes had to work in Windows 95.
In spite of numerous problems and limitations of Mailslots these classes work properly
in Windows 95 and Windows NT.
The problems were that there is an 8-byte limitation for Mailslots names in Windows95 and
numerous data transmissions across Mailslots between Computers if they have several identical installed
communication protocols.
Microsoft considers this "by design". In other words, it is not an error, but I don't agree with it.
In these classes the Server has the receiving thread and Clients send data with identification
of the Client (Computer name and Client name) to this thread. It increases the summary data that Clients transmit across Mailslots and
it is the disadvantage of this method.
I took a course in COM and ATL. After that it was evident that
there were very many undocumented things in that technology.
ATL is a convenient tool, but I have discovered several limitations, e.g. it is impossible to make ATL-Server from
an existing MFC application.
DCOM implementation needs great effort too. For example, I wrote my first program with DCOM
in almost 2 weeks and had to ask Microsoft for numerous consultations. That's why in spite of my wish to use COM/DCOM in my new project I had to give up this idea.
The new project that I have begun to work at had high requirements for the speed
of data processing. This factor had to be taken into account in the design of the new communication tool. Fortunately, unlike COM, there were no requirements
to the design of the universal tool and this made the development easier.
For the new project I have chosen the protocol Named Pipes working only in
Windows NT. In literature this protocol is defined as following:
An inter-process communication mechanism that allows one process to communicate
with another local or remote process.
I have tried to implement the ideas that I used in my first project with Mailslots
as well as the ideas of COM. In the next section you'll learn the Client-Server architecture,
based on the Named Pipes protocol.
4. Client-Server Architecture
These are following variants of connections Client and Server.
- Client and Server are on a single computer.
- Client and Server are on multiple computers.
When a Server is loaded, the Client tries to get into a connection with Server.
If Server is not loaded and Client and Server are on a single computer, Client gets information about Server from Registry of this
computer (see Computer 4).
If Server is not loaded and Client and Server are on multiple computers, Client gets information about Server from Registry of the remote Server
computer across utility AgentCP (see Computers 1 and 2). This program searches Server information in Registry of Server Computer and loads it.
As seen from Figure 1, for successful functioning of the above-mentioned process
it is necessary:
- To write information about Server in Registry of Server Computer.
- To run the AgentCP utility on the remote computer previously.
Thus the Server automatic loading is carried out. Process-Server may be terminated automatically, if Clients are not connected.
There is a User's guide in DemoConnectionPipe.zip
Here you may see Wizard Application:
