通信管道类

• 下载演示项目 - 607 KB

1. 目的

在 Windows NT 中，在单个或多个计算机上，所有类型的 MFC 应用程序之间简单快速的通信。

2. 主要特点

• 从客户端到服务器的数据传输，以及它们的处理和结果返回（如果需要）。
• 从服务器到客户端的数据传输，告知它们任何事件。
• 不同的缓冲区分配方案。
• 服务器自动加载。
• 服务器自动终止（如果需要），无需客户端连接。
• 用于注册、自动加载、跟踪和向导的实用程序。

3. 引言

几年前，我编写了使用 Mailslots 在客户端和服务器之间进行通信的类。根据项目要求，这些类必须在 Windows 95 中工作。尽管 Mailslots 存在许多问题和限制，但这些类在 Windows 95 和 Windows NT 中都能正常工作。

问题是 Windows 95 中 Mailslots 名称限制为 8 个字节，并且如果它们安装了多个相同的通信协议，则在计算机之间通过 Mailslots 进行大量的数据传输。微软认为这是“设计使然”。换句话说，这不是一个错误，但我不同意。

在这些类中，服务器有一个接收线程，客户端使用客户端的标识（计算机名和客户端名）将数据发送到该线程。它增加了客户端通过 Mailslots 传输的汇总数据，这是该方法的缺点。

我参加了 COM 和 ATL 的课程。在那之后，很明显，这项技术中有很多未记录的东西。
ATL 是一个方便的工具，但我发现了几个限制，例如，不可能从现有的 MFC 应用程序创建 ATL 服务器。

DCOM 的实现也需要很大的努力。例如，我用将近 2 周的时间编写了我的第一个 DCOM 程序，并且不得不向微软咨询许多次。这就是为什么尽管我希望在新项目中使用 COM/DCOM，但我不得不放弃这个想法。

我开始着手的新项目对数据处理速度有很高的要求。在设计新的通信工具时，必须考虑到这一因素。幸运的是，与 COM 不同的是，对通用工具的设计没有要求，这使得开发更容易。

对于新项目，我选择了仅在 Windows NT 中运行的命名管道协议。在文献中，该协议定义如下：

一种进程间通信机制，允许一个进程与另一个本地或远程进程进行通信。

我尝试了在我的第一个 Mailslots 项目中以及 COM 的想法。在下一节中，您将了解基于命名管道协议的客户端-服务器架构。

4. 客户端-服务器架构

以下是客户端和服务器连接的几种变体。

• 客户端和服务器在同一台计算机上。
• 客户端和服务器在多台计算机上。

加载服务器时，客户端尝试与服务器建立连接。

如果未加载服务器，并且客户端和服务器在同一台计算机上，则客户端从该计算机的注册表中获取有关服务器的信息（参见计算机 4）。

如果未加载服务器，并且客户端和服务器在多台计算机上，则客户端通过实用程序 AgentCP 从远程服务器计算机的注册表中获取有关服务器的信息（参见计算机 1 和 2）。该程序在服务器计算机的注册表中搜索服务器信息并加载它。

从图 1 中可以看出，为了成功运行上述过程，需要

• 将有关服务器的信息写入服务器计算机的注册表。
• 先前在远程计算机上运行 AgentCP 实用程序。

因此，服务器自动加载已执行。如果客户端未连接，则进程服务器可能会自动终止。

DemoConnectionPipe.zip 中有用户指南

在这里，您可以看到向导应用程序