问题标签 [named-pipes]

在 *nix 中，许多接受文件名作为参数的命令行应用程序也接受管道。例子：

也适用于

并且“anotherApplication”的结果被重定向到“anApplication”，因为它是一个文件

我了解到与此等效的 Windows 是“命名管道”。我想知道命令行应用程序是否必须知道命名管道才能理解它，或者是否任何接受文件作为参数的命令行应用程序都可以使用命名管道。

我有一个通过命名管道设置的服务器。它适用于域的管理员，但是当我在普通用户上测试客户端时，它给出了异常“访问路径被拒绝”。所以这就是我试图设置权限以授予域中所有经过身份验证的用户的访问权限。我在这里做错了什么？

服务器：

客户：

服务器名称和域显然不同，但是在服务器上，当它到达 pipeServer.SetAccessControl 函数时，它给了我异常“UnauthorizedAccessException”。

任何帮助是极大的赞赏

是否有一些 WinAPI 调用可以告诉我谁（哪个进程）创建了命名管道？

注意：问这个问题时，我感觉它以某种方式“闻起来”，正确的设计是使用其他方式传达进程 ID/句柄，但是从管道本身获取这些信息会更简单，因此如果有这样的 API，我可能仍然会使用它。

您能告诉我在 .net 3.5 中通过 NamedPipes 发送对象的最佳方式是什么吗？

我使用命名管道，并且我想在服务器上重用相同的管道，以便在原始客户端断开连接后允许连接另一个客户端。我要做的是：

• 服务器使用创建管道CreateNamedPipe
• 服务器使用 写入数据WriteFile，并在返回错误时重试ERROR_PIPE_LISTENING（在任何客户端连接之前）
• 客户端连接使用CreateFile
• 客户端读取数据
• 客户端关闭管道句柄使用CloseHandle
• 此时服务器ERROR_NO_DATA尝试写入更多数据时出错
• 服务器使用 断开管道DisconnectNamedPipe，我希望它可以再次释放
• 服务器尝试写入数据，得到错误ERROR_PIPE_NOT_CONNECTED，它重试这样做，直到没有错误
• 但是，当新客户端连接并尝试CreateFile在管道上时，它会ERROR_PIPE_BUSY

因此，我的问题是：我需要执行哪些其他步骤才能正确断开客户端与管道的连接，以便新客户端可以连接？

我需要在一个使用命名管道与其他进程通信的小型 Linux 程序中实现握手类型协议。我在使用命名管道时搜索了握手类型协议的通用实现模式，但我无法打开任何东西......

我简直不敢相信没有模式可以做到这一点。有人可以指出我可能的资源吗？

完全公开，这是家庭作业，但实施这种模式不是家庭作业。我们需要在作业代码中解决一个问题，我相信这是一个可能的解决方案。作业是用 C++ 实现的——但语言对我来说并不重要。我只是不想重新发明轮子......

更新：我觉得这可以用信号来实现。

我所说的握手是指一个子进程向它的父进程报告它已准备好工作但在父进程发出 go 信号之前不会继续（即使管道中有东西）。在我的工作理论中，我将有许多子进程需要报告就绪并等待来自父进程的 go 信号。

每个人似乎都说命名管道比套接字 IPC 更快。它们的速度有多快？我更喜欢使用套接字，因为它们可以进行双向通信并且非常灵活，但是如果数量很大，则会选择速度而不是灵活性。

由于某种原因，桅杆和奴隶都失败了，但是我可以找到任何关于它们如何工作的好例子，所以我不确定我哪里出错了。

主机在 ConnectNamedPipe 之后永远不会退出 WaitForSingleObject，从机在第一个 boost::asio::read 调用中抛出异常，“等待进程打开管道的另一端”，我认为 WaitNamedPipe 是为了与 Master 中的 ConnectNamedPipe 一起等待？

大师.cpp

从属.cpp

显然我得到了一些完全错误的东西，但是我在网上找不到任何东西来比较我的代码。

我在 Windows Server 2003 机器上的单个 Windows 服务中托管了两个 WCF 服务。如果 Windows 服务需要访问任一 WCF 服务（例如发生定时事件时），它会使用公开的五个命名管道端点之一（不同的服务协定）。该服务还为这两个服务中的每一个公开了 HTTP MetadataExchange 端点，并为服务器外部的消费者公开了 net.tcp 端点。

通常情况很好，但每隔一段时间我就会收到一条看起来像这样的错误消息：

System.ServiceModel.EndpointNotFoundException：在 net.pipe://localhost/IPDailyProcessing 上没有可以接受消息的端点侦听。这通常是由不正确的地址或 SOAP 操作引起的。有关更多详细信息，请参阅 InnerException（如果存在）。---> System.IO.PipeException：在您的本地计算机上找不到管道端点“net.pipe://localhost/IPDailyProcessing”。--- 内部异常堆栈跟踪结束 --- 服务器堆栈跟踪：在 System.ServiceModel.Channels.PipeConnectionInitiator.GetPipeName(Uri uri) 在 System.ServiceModel.Channels.NamedPipeConnectionPoolRegistry.NamedPipeConnectionPool.GetPoolKey(EndpointAddress address, Uri via) 在System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection（TimeSpan 超时）在 System.ServiceModel.Channels.ClientFramingDuplexSessionChannel。

它不会可靠地发生，这很让人抓狂，因为我无法在我想重复的时候重复它。在我的 Windows 服务中，我也有一些定时事件和一些文件侦听器，但这些是相当罕见的事件。有谁知道为什么我可能会遇到问题？任何帮助将不胜感激。

我们使用命名管道在 C# .Net 服务和本机 C++ 应用程序之间进行通信。该服务创建一个消息模式管道，然后启动一个计时器。

在计时器滴答例程中是主服务循环，如下所示：

读写完成例程如下所示：

客户端代码是已知的好代码，可重复使用。所以这就是问题所在。客户端可以正常连接。然后我们关闭了客户端，一切都很好。我们启动它并再次连接。一切都好，然后我们关闭它并重新启动它。Boom - 错误 231，管道忙。服务器现在将在任何连接尝试上生成管道繁忙错误，直到地狱冻结，或者我们重新启动服务。然后我们再次回到两个连接。

我已经连续三天盯着这段代码了，我不知道为什么会这样。我似乎看不到树木只见树木，我可以用一三双新鲜的眼睛。问题是团队中没有其他人对任何 C# 了解很多。

更新

第三次连接尝试失败的原因似乎是在第一次断开连接时 PipeReadComplete 返回并且我读取了零字节，所以我分离了管道并且一切都很好。但是...在第二次断开连接时，不会调用 PipeReadComplete，因此我不会强制断开连接。诡异的。