当前位置：文江博客话题详情

打破 ReadFile() 阻塞 - 命名管道 (Windows API)

发布于 2024-07-13 20:52:16 字数 1057 浏览 3 评论 0原文

为了简化，这是一种 NamedPipe SERVER 正在等待 NamedPipe CLIENT 写入管道（使用 WriteFile()）的情况。

阻塞的 Windows API 是 ReadFile()

服务器已创建同步管道（没有重叠的 I/ O) 启用阻塞

客户端已连接，现在服务器正在等待一些数据。

在正常的流程中，客户端发送一些数据，服务器处理它，然后返回 ReadFile() 等待下一个数据块。

同时发生一个事件（例如用户输入），NamedPipe SERVER 现在必须执行一些其他代码，而在 ReadFile() 阻塞时它无法执行此操作。

此时我需要提及的是，NamedPipe 客户端不是我的应用程序，因此我无法控制它。我无法让它发送几个字节来解锁服务器。它只是坐在那里不发送任何数据。由于我无法控制客户端实现，因此我无法更改任何内容。

一种解决方案是创建一个单独的线程，在其中执行所有 ReadFile() 操作。这样当事件发生时，我就可以处理代码。问题是该事件还需要一个单独的线程，所以现在我为此服务器的每个实例都有两个额外的线程。由于这需要可扩展，因此这是不可取的。

我尝试从另一个线程调用

 DisconnectNamedPipe()

，但

 CloseHandle()

它们都不会返回（直到客户端写入管道。）

我无法连接到同一个管道并写入几个字节，因为：

“命名管道的所有实例共享相同的管道名称，但每个实例都有它自己的缓冲区和句柄，并为客户端/服务器提供单独的管道通信。”

http://msdn.microsoft.com/en-us/library/ aa365590.aspx

我需要一种方法来伪造它，所以 64k 美元的问题是：

如何打破 ReadFile() 的阻塞？

原文

To simplify, this is a situation where a NamedPipe SERVER is waiting for a NamedPipe CLIENT to write to the pipe (using WriteFile())

The Windows API that is blocking is ReadFile()

The Server has created the synchronous pipe (no overlapped I/O) with blocking enabled

The client has connected, and now the server is waiting for some data.

In the normal flow of things, the client sends some data and the server processes it and then returns to ReadFile() to wait for the next chunk of data.

Meanwhile an event occurs (user input for example) and the NamedPipe SERVER must now execute some other code, which it cannot do while the ReadFile() is blocking.

At this point I need to mention that the NamedPipe Client is not my application, so I have no control over it. I cannot make it send a few bytes to unblock the server. It is just going to sit there and send no data. Since I do not have control of the Client implementation I cannot change anything on that end.

One solution would be to create a separate thread in which all ReadFile() operations are performed. That way when the event occurs, I can just process the code. The problem with that, is that the event also requires a separate thread, so now I have two additional threads for each instance of this server. Since this needs to be scalable, this is undesirable.

From another thread I have tried calling

 DisconnectNamedPipe()

and

 CloseHandle()

they both will not return (until the client writes to the pipe.)

I cannot connect to the same pipe and write a few bytes because:

"All instances of a named pipe share the same pipe name, but each instance has
its own buffers and handles, and provides a separate conduit for client/server
communication."

http://msdn.microsoft.com/en-us/library/aa365590.aspx

I need a way to fake it out, So the $64k dollar question is:

How can I break the blocking of ReadFile()?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

我的奇迹 2024-07-20 20:52:16

在 ReadFile 之前尝试一下：

BOOL WINAPI PeekNamedPipe(
  __in       HANDLE hNamedPipe,
  __out_opt  LPVOID lpBuffer,
  __in       DWORD nBufferSize,
  __out_opt  LPDWORD lpBytesRead,
  __out_opt  LPDWORD lpTotalBytesAvail,
  __out_opt  LPDWORD lpBytesLeftThisMessage
);

if(TotalBytesAvail > 0)
  ReadFile(....);

-AV-

Try this before ReadFile :

BOOL WINAPI PeekNamedPipe(
  __in       HANDLE hNamedPipe,
  __out_opt  LPVOID lpBuffer,
  __in       DWORD nBufferSize,
  __out_opt  LPDWORD lpBytesRead,
  __out_opt  LPDWORD lpTotalBytesAvail,
  __out_opt  LPDWORD lpBytesLeftThisMessage
);

if(TotalBytesAvail > 0)
  ReadFile(....);

-AV-

回复收藏 0 原文