命名管道双重责任 [英] Named Pipe Double Duty

查看:70
本文介绍了命名管道双重责任的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在工作中继承了一个项目,该项目由一个窗口服务(用Perl编写-不要问)组成,该窗口服务在一个到八个已编译的C ++ EXE应用程序之间启动.每个EXE都在独立于Perl代码和其他EXE进行其自身的工作,但是与每个EXE进行通信并维护它们所产生的数据是Perl的工作.通过命名管道来管理IPC,在该命名管道中,Perl代码发布状态"消息.命令,并且EXE将响应(发送,接收或等待).根据响应,Perl代码可以适当地执行某些操作.

我正在构建一个诊断应用程序,希望能够捕获与Perl代码相同的状态.我想知道是否可以让其他两个进程与EXE进行通信(即Perl和我的新.NET诊断应用程序),而又不会互相干扰,或者命名管道应该/必须严格一对一通信渠道.

I inherited a project at work which consists of a window service (written in Perl - don't ask) which starts up anywhere between one and eight compiled C++ EXE applications. Each exe is doing its own thing independent of the Perl code and the other EXE's, however it is the Perl's job to communicate with each EXE and maintain the data produced by them. The IPC is managed via named pipes where the Perl code issues a "status" command, and the EXE will respond either (SENDING, RECEIVING, or WAITING). Based on the response, the Perl code does something appropriately.

I'm building a diagnostics app which I would like to be able to capture the same status as the Perl code. I'd like to know if I can have two other processes communication the EXE (i.e. the Perl and my new .NET diagnostics app) without causing interference for each other or if named pipes should be/must be strictly one-to-one communication channels. Ideas?

推荐答案

命名管道是双工的,但是如果您希望您的应用程序与其他许多应用程序进行通信,那么您可以做的是设置一台服务器并在其中分配客户端.这样,您的主应用程序将能够发送命令,接收信息并对其进行处理.但是,与TCP/IP服务器不同,您的服务器将无法执行多任务处理.所有其他应用程序都必须等到其中一个完成.如果这不是您所拥有的,那么我不知道.在一个应用程序中设置多个服务器听起来有些奇怪.


这篇关于命名管道双重责任的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆