3. Introduction

The above-mentioned problems are the following:
8-bytes limitation for Mailslots names in Windows95 and
numerous data transmission across Mailslots between Computers,
if they have several identical installed communiciation protocols.
Microsoft considers this as "by design". In other words, it is not an error,
but I don't agree with it.

In these classes Server has the receiving thread and Clients send data
with identificator of Client (Computer name and Client name) to this thread.
It increases summary data that Clients transmit across Mailslots and
it is the disadvantage of this method.

I took a course of COMs 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 the existing MFC application.

DCOM implementation needs great efforts too. For example, I wrote my
first program with DCOM 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 WindowsNT.
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 chapter you'll learn the Client-Server architecture,
based on the Named Pipes protocol.

4. Client-Server Architecture

When Server is loaded, Client tries to get into 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 utility AgentCP on the remote computer previously.

Thus the Server automatic loading is carried out. Process-Server may be
terminated automatically, if Clients are not connected.

Here you may see WizardCP Application:

About Author

Ion Tichy.