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