【发布时间】:2014-06-07 12:04:59
【问题描述】:
我需要一个命名管道来读写。
在一个程序中,我使用 kernel32.dll 创建了管道服务器:
string PipeName = "\\\\.\\pipe\\myMT4";
int PipeMode = PIPE_TYPE_MESSAGE|PIPE_READMODE_MESSAGE|PIPE_WAIT; # tried too: PIPE_NOWAIT
int hPipe = CreateNamedPipeW(
PipeName,
PIPE_ACCESS_DUPLEX,
PipeMode,
PIPE_UNLIMITED_INSTANCES,1024,1024,
NMPWAIT_USE_DEFAULT_WAIT,NULL);
句柄 hPipe 是有效的 - 这里的一切似乎都正常!
但在 PowerShell 脚本中,我想打开一个客户端,连接并打开编写器 -
并且无法连接 => 超时
function connect{
Param ([PSObject] $h)
...
$h.Pipe = New-Object -TypeName System.IO.Pipes.NamedPipeClientStream "\\.\pipe\PipeTest"
$h.Pipe.Connect( 5000 )
$h.Writer = New-Object -TypeName System.IO.StreamWriter $h.Pipe, $h.Encode
我真的希望这种方式在读写时具有类似的访问权限n
来自/到管道和套接字,例如:
function write{
Param ([PSObject] $h, [string] $line )
try {
$h.Writer.Write($line)
}
怎么了? 提前致谢, 太好了。
PS: 似乎该程序无法处理管道服务器 - 我必须打开一个管道客户端,这可行,但会导致其他问题:
我为 PowerShell-pipe-server 定义:
$pipeName = "testpipe"
$pipeDir = [System.IO.Pipes.PipeDirection]::InOut
$pipeMsg = [System.IO.Pipes.PipeTransmissionMode]::Message
$pipeOpti = [System.IO.Pipes.PipeOptions]::Asynchronous
$pipe = New-Object system.IO.Pipes.NamedPipeServerStream(
$pipeName, $pipeDir, 1, $pipeMsg, $pipeOpti )
$pipe.WaitForConnection() #
$sw = new-object System.IO.StreamWriter $pipe
$sw.AutoFlush = $true
$sw.WriteLine("Server pid is $pid")
$sw.Dispose()
$pipe.Dispose()
1) 我的第一个问题现在是 powerShell-pipe-server 被
阻止了 $pipe.WaitForConnection()
直到客户端连接但它必须同时独立处理2个不同的套接字并且
2) 如果客户端关闭连接,我无法告诉客户端再次打开相同的管道并且客户端收到 Windows 错误:ERROR_PIPE_BUSY 231
形成我用 kernel32.dll-function 连接到服务器的程序:
int CallNamedPipeW(string PipeName,
string outBuffer, int outBufferSz,
uint& inBuffer[], int inBufferSz,
int& bytesRead[], int timeOut
);
有什么想法吗?
【问题讨论】:
-
该程序似乎无法处理已启动的管道服务器。我找到了一个简单的独立管道服务器可以做到这一点。
-
您是否有充分的理由需要异步支持?你也许可以让它在 PowerShell 中工作,但你会受到一些伤害。
-
it must handle 2 different sockets independently是什么意思?你的意思是它必须处理多个客户?您是否正在为其他任务设置套接字?处理 WaitForConnection 阻塞特性的一种方法是在后台作业中运行此脚本,例如$serverJob = Start-Job -Name NamedPipeServer {$pipe = ... }。这将在后台启动另一个 PowerShell 进程来为您的脚本提供服务,并且当前的 PowerShell 会话将继续处理其他脚本。 -
非常感谢,我正在考虑这个(多线程),但由于额外需要管理所有线程之间的通信而决定反对它。我也会用socket。