多个客户端程序的最佳方式是什么？ 与单个服务器程序通信，全部运行 在一台Windows计算机上？全部用VB6编写。 我很感激您可以解决的建议 这个问题。
注意：我们正在努力过渡到.NET，但必须这样做 在.NET之前为V6B版本添加功能 做好准备。
可能性包括TPC连接，命名管道， 共享内存，消息，文件等。
客户端将服务器作为输入和服务器传递给服务器 将其与仅为服务器知道的数据相结合，以生成 另一个返回给客户端的字符串。两个字符串 只有大约100个字符。联系服务器 只有当需要打开一个新文件时，它才是一个非常好的文件 通讯量低......可能是10次通话 在15秒内，然后是一小时的空闲时间。
但是有两个客户可能会选择 同时要求提供信息。当然阻止/锁定 可以接受，因为服务器将在每个请求中完成 不到一秒，几秒钟的延迟是不重要的 任何节目。
服务器的算法很复杂，并且有几个重要原因 不应该在每个帮助程序中复制应用程序。 这就是需要服务器的原因。
背景：
我正在为现有的大型遗留程序添加功能。
这个单一的程序还有其他几个遗留程序
充当助手，并在用户确定时运行
选择。这些程序是用shell命令启动的，
并不只是单独的线程。例如，一个帮手
将新数据从DVD驱动器加载到硬盘驱动器上。另一个
帮助者只显示当前位置的图表
行星。
这是一个大型的商业遗产计划 用VB6编写。我们正在努力转换它和所有 .NET的帮助程序，但必须首先发布新版本 在vb6下具有这种附加功能。 （请不要告诉我 不要使用VB6，因为我们已经转移到其他地方了。） 我们需要一个临时的VB6解决方案。
答案 0 :(得分：4)
VB6通过Pro和Enterprise Editions中包含的标准Winsock Control组件可以很好地完成TCP和UDP。很多遮阳编程人员似乎确实在努力解决这个问题。这可能是最明显的路线，因为VB6中唯一的其他原生IPC将是COM / DCOM和DDE，但MSMQ也为VB6提供了出色的支持。
基于IP的协议的缺点是它们的名称空间有限，并且导致高冲突概率（64K端口号，许多用于标准应用程序，临时端口范围等）。他们也有点“重量级”，但考虑到即使是最老的PC仍在使用中的大量资源以及您的轻量级流量要求，您可以在决定时忽略它。
您考虑的另一个选项是命名管道。
这为您的情况提供了许多优势。一方面，命名空间要大得多，只需要一个唯一的名称，在后Win9x时代，最长可达256个字符，使得唯一性很容易实现。另一方面，只要您的防火墙允许“文件和打印共享”，您就可以在这方面设置。
此外，对于您的应用程序，您似乎只需要RPC样式的机制，而不是任意的双向流或消息。您客户的TransactNamedPipe()电话可能是理想的。命名管道在局域网上工作，但在一台PC中，它们非常快速且重量轻。
虽然VB6没有命名管道组件，但只要不需要极高的性能，这样就很容易创建。您可以在服务器中使用基于计时器的轮询，而不是尝试实现重叠的I / O以获得异步性。几年前我把它放在一起，并且运气好。
我在PipeRPC - RPC Over Named Pipes发表了一段相当稳定的演绎。有一个较旧的和更新的版本，其中包含使用和文档的示例。按照设计，客户端通过Byte数组的请求参数进行“调用”，并接收Byte响应结果数组。您也可以在不更改的情况下推送Unicode字符串，让编译器强制执行类型。
只为客户端和服务器提供一个“插入”UserControl。
回顾这个问题：
服务器的算法很复杂，并且有几个重要原因 不应该在每个帮助程序中复制应用程序。 这就是需要服务器的原因。
如果这真的是关注为什么不只是创建一个所有程序都使用的共享DLL？
答案 1 :(得分：2)
对于移动到较新平台的现有VB6应用程序的一次性升级版本，我强调保持修改尽可能简单明了。因此，我不会涉及任何涉及共享内存或任何相对不寻常的路径。
一些选项，没有一个简单，但至少有一些想法：
在执行转换的服务器代码中公开COM对象，客户端应用程序可以使用它。客户端将服务器中的对象实例化为进程外对象，让COM处理所有编组等。
服务器是否有网络感知？ VB6本身并不能很好地执行socket / tcp，但是如果你有理由将其添加进去，你可能可以利用它来执行基于套接字的连接和数据交换。
服务器和客户端都可以轮询公共资源文件夹，查看是否存在构成您描述的翻译服务的入站/出站请求的特定文件。不是很优雅，但它可能是最简单的。
只有一些想法可以给你一些思考的东西。希望这在某种程度上有所帮助。祝你好运！