远程连接点

引言

我描述了构成CNF组的三个程序的集合。它关于客户端机器(cm)中的一个客户端，通过一个连接点从服务器机器(sm)中的一个服务器获取
信息。我可以把它叫做远程连接点。
这三个程序是
1) NFCli, 一个没有ATL支持的MFC7 Visual Studio .Net SDI应用;
2) SvrNear, 一个ATL7 Visual Studio .Net Exe模块;
3) SvrFar, 一个ATL7 Visual Studio .Net Exe模块.

      描述  
NFCli和SvrNear留在cm中，而SvrFar留在sm中。Sm和cm组成一个由2台PC组成的局域网。SvrNear在两台
机器中都已注册。SvrFar也在两台机器中都已注册。在sm中, dcomcnfg, SvrFar 属性, 安全性: 为 使用
自定义访问权限和 使用自定义启动权限 添加 Everyone 账户。在cm中, dcomcnfg, SvrNear 属性, 安全性: 为 使用
自定义访问权限和 使用自定义启动权限 添加 Everyone 账户。两台机器中服务器的所有其他属性
都可以保持默认。这个应用使用 dcomcnfg 或声明式方法来实现COM安全性：没有用于安全性的代码，
也就是，没有编程式方法来实现COM安全性。
通信的端点是cm中的NFCli和sm中的SvrFar，而cm中的SvrNear就像NFCli
和SvrFar之间的中间人。这里解决的问题是，SvrFar的连接点需要一个在允许
访问SvrFar的应用中实现的接收器: 这个应用是SvrNear.
所以事情是这样安排的
NFCli只知道SvrNear的接口并激活SvrNear. SvrNear只知道SvrFar的接口并激活SvrFar.
更重要的是, SvrNear实现了对应于SvrFar的连接点的接收器。SvrFar不知道SvrNear的接口。
所有操作都通过接口方法完成
NFCli激活SvrNear。然后NFCli传递给SvrNear两个字符串: 第一个字符串是sm的名称; 第二个字符串是SvrFar的coclass.
有了这两个字符串，cm中的SvrNear就可以激活sm中的SvrFar。然后SvrNear创建对应于SvrFar的
连接点的接收器。由于双向通信现在已经实现，NFCli要求SvrNear测试SvrFar的连接点。
SvrNear调用一个SvrFar的coclass方法，该方法将一个通知发回给SvrNear接收器: 发回由
SvrFar的coclass实现的连接点接口执行。通知是一个报告SvrFar的主机机器名称的字符串，
到达SvrNear的接收器，并在被NFCli调用之前，作为SvrNear的方法的输出变量复制回来。所以现在
NFCli通过一个连接点从SvrFar获得了信息。然后NFCli通过释放SvrNear的
接口指针来切断通信，反过来，SvrNear通过释放SvrFar的接口指针来切断通信。此时SvrNear和
SvrFar被取消。

      安装
在cm中放置一个CNF副本。在sm中放置第二个CNF副本。路径的字符串中不能有空格。从cm的命令行
启动 SvrNear /regserver 和 SvrFar /regserver. 从sm的命令行启动 SvrNear /regserver 和 SvrFar /regserver. 使用
dcomcnfg用于cm中的SvrNear和sm中的SvrFar，如以上描述中所述。转到cm并启动NFCli, 工具, 远程服务器,
在远程机器名称中写入sm的名称，连接。几秒钟后，通过本地/远程SCM，“获取消息”和
“断开连接”按钮被启用。按下“获取消息”并获取远程机器名称。按下“断开连接”。

      评论
当然，这并不是使用COM/ATL在客户端和远程服务器之间进行通信的唯一方式，但这个应用关注
连接点。应该有更好的方式来使用远程连接点，而不需要中间人，也许
通过使用编程式方法来实现安全性。我对它了解不够。我不使用 #import 指令和 tlb 文件，而是 #include
_i.c 和 .h 文件: 我更喜欢基本方法。它至少在像这样的小程序套件中实用。
对于我的硬件/软件，建立远程连接需要三秒钟: 我认为时间会更短。我的sm是一台带有
标准网卡的AMD，我的cm是一台带有标准网卡的Intel，用交叉线连接到cm。Sm有 Microsoft Server
2000，cm有 Microsoft Professional 2000。

Mr. Trevisan Andrea