一、管道实现进程间通讯
主要的理论知识
1．什么是管道以及分类
管道是两个头的东西，每一个头各连接一个进程或者同一个进程的不同代码，依照管道的类别分有两种管道，匿名的和命名的；依照管道的传输方向分也能够分成两种，单向的双向的。依据管道的特点，命名管道通经常使用在网络环境下不同计算机上执行的进程之间的通信（当然也能够用在同一台机的不同进程中）它能够是单向或双向的；而匿名管道仅仅能用在同一台计算机中，它仅仅能是单向的。匿名管道事实上是通过用给了一个指定名字的有名管道来实现的。
使用管道的优点在于：读写它使用的是对文件操作的
api，结果操作管道就和操作文件一样。即使你在不同的计算机之间用命名管道来通信，你也不必了解和自己去实现网络间通信的详细细节。
2．管道的使用
A．命名管道
命名管道是由server端的进程建立的，管道的命名必须遵循特定的命名方法，就是"//./pipe/管道名"，当作为client的进程要使用时，使用"//计算机名//pipe/管道名"来打开使用，详细过程例如以下：
服务端通过函数CreateNamedPipe创建一个命名管道的实例并返回用于今后操作的句柄，或为已存在的管道创建新的实例。服务端侦听来自client的连接请求，该功能通过ConnectNamedPipe函数实现。
client通过函数WaitNamedPipe来等待管道的出现，假设在超时值变为零曾经，有一个管道能够使用，则WaitNamedPipe将返回 True，并通过调用CreateFile或CallNamedPipe来呼叫对服务端的连接。
此时服务端将接受client的连接请求，成功建立连接，服务端ConnectNamedPipe返回 True 建立连接之后，client与server端就可以通过ReadFile和WriteFile，利用得到的管道文件句柄，彼此间进行信息交换。当client与服务端的通信结束，client调用CloseFile，服务端接着调用DisconnectNamedPipe。最后调用函数CloseHandle来关闭该管道。
B．匿名管道
因为命名管道使用时作为client的程序必须知道管道的名称，所以很多其它的用在同一“作者”编写的server/工作站程序中，你不可能随便找出一个程序来要求它和你写的程序来通过命名管道通信。而匿名管道的使用则全然不同，它同意你和全然不相干的进程通信，条件是这个进程通过控制台“console”来输入输出，典型的样例是老的 Dos 应用程序，它们在执行时 Windows为它们开了个 Dos窗体，它们的输入输出就是 console方式的。另一些标准的 Win32程序也使用控制台输入输出，假设在 Win32编程中不想使用图形界面，你照样能够使用AllocConsole得到一个控制台，然后通过GetStdHandle得到输入或输出句柄，再通过WriteConsole或WriteFile把结果输出到控制台（一般是一个象 Dos窗体）的屏幕上。尽管这些程序看起来象 Dos程序，但它们是不折不扣的 Win32程序，假设你在纯 Dos下使用，就会显示“The program must run under Windows!”。
一个控制台有三个句柄：标准输入、标准输出和和标准错误句柄，标准输入、标准输出句柄是能够又一次定向的，你能够用匿名管道来取代它，这样一来，你能够在管道的还有一端用别的进程来接收或输入，而控制台一方并没有感到什么不同，就象 Dos下的 >或者 <能够又一次定向输出或输入一样。通常控制台程序的输入输出例如以下：
(控制台进程output) write ----> 标准输出设备（通常是屏幕）
(控制台进程input) read <---- 标准输入设备（通常是键盘）
而用管道取代后：
(作为子进程的控制台进程output) write ----> 管道1 ----> read (父进程)
(作为子进程的控制台进程input) read <----> 管道2 <---- write (父进程)
使用匿名管道的过程例如以下：
使用CreatePipe建立两个管道，得到管道句柄，一个用来输入，一个用来输出
准备运行控制台子进程，首先使用GetStartupInfo得到StartupInfo
使用第一个管道句柄取代 StartupInfo中的 hStdInput，第二个取代 hStdOutput、hStdError，即标准输入、输出、错误句柄
使用CreateProcess运行子进程，这样建立的子进程输入和输出就被定向到管道中
父进程通过 ReadFile读第二个管道来获得子进程的输出，通过 WriteFile写第一个管道来将输入写到子进程
父进程能够通过PeekNamedPipe来查询子进程有没有输出
子进程结束后，要通过CloseHandle来关闭两个管道。
管道使用的API函数集
| |||||||
| |||||||
| |||||||
| |||||||
| |||||||
| |||||||
| |||||||
| |||||||
| |||||||
| |||||||
|
二、
BOOL WaitNamedPipe( LPCTSTR lpNamedPipeName, DWORD nTimeOut );
lpNamedPipeName 要打开的管道名，格式\\servername\pipe\pipename，假设是本地管道则servername能够使用点“.”。
nTimeOut 等待命名管道的一个实例有效的超时时间，单位毫秒，也能够使用以下两个值中的一个：
NMPWAIT_USE_DEFAULT_WAIT 0x00000000,使用服务端CreateNamedPipe 创建管道时设置的超时时间。
NMPWAIT_WAIT_FOREVER 0xffffffff，一直等到一个命名管道的实例有效才返回。
返回值：
假设在超时时间前管道的一个实例有效，返回非0。
假设超时时间内没有一个有效的实例，返回0。
注意：
假设指定的命名管道没有实例存在，即没有服务端创建该命名管道（所以在确定server端创建了该命名管道时能够不调用此API），函数无视超时等待时间直接返回0。
假设函数运行成功返回TRUE，表示至少有一个命名管道的实例有效，接下来应该使用CreateFile函数打开命名管道的一个句柄，可是CreateFile可能会打开管道失败，由于该实例有可能被服务端关闭或被已经被其它client打开。
三、管道使用的伤痛所在
平时都使用得好好的管道突然出发问题了
static inline BOOL
CTPipe_WriteNBytes(HANDLE hPipe, BYTE *buf, DWORD size, DWORD timeout, HANDLE stopEvent)
{
BOOL ret = FALSE;
BOOL writeRet;
OVERLAPPED ol;
BYTE *pos;
DWORD cbBytesWrite;
HANDLE hWriteEvent;
memset( &ol, 0, sizeof(ol) );
ol.hEvent = hWriteEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
if ( ol.hEvent == NULL )
{
return FALSE;
}
pos = buf;
while ( size > 0 )
{
writeRet = WriteFile(hPipe,
pos,
size,
&cbBytesWrite,
&ol);
if ( writeRet )
{
pos += cbBytesWrite;
size -= cbBytesWrite;
ResetEvent(hWriteEvent);
}
else
{
if ( GetLastError() == ERROR_IO_PENDING )
{
DWORD waitRet;
HANDLE handles[2];
int numOfHandles = 1;
handles[0] = hWriteEvent;
if ( stopEvent )
{
handles[1] = stopEvent;
numOfHandles++;
}
waitRet = WaitForMultipleObjects(numOfHandles, handles, FALSE, timeout);
if ( waitRet == WAIT_OBJECT_0 )
{
writeRet = GetOverlappedResult(hPipe, &ol, &cbBytesWrite, TRUE );
if ( writeRet == FALSE )
{
goto EXIT;
}
pos += cbBytesWrite;
size -= cbBytesWrite;
ResetEvent(hWriteEvent);
}
else /* timeout, notify event or other */
{
/*
* Cancel request
*/
if ( CancelIo(hPipe) == FALSE )
{
L_ERROR(_T("IoCancel fail 0x%x, force close pipe\n"), GetLastError());
CloseHandle(hPipe);
}
else
{
/*
* Wait cannel finish
*/
GetOverlappedResult(hPipe, &ol, &cbBytesWrite, TRUE);
}
goto EXIT;
}
}
else
{
goto EXIT;
}
}
}
ret = TRUE;
EXIT:
if ( hWriteEvent )
{
CloseHandle(hWriteEvent);
}
return ret;
}
waitRet = WaitForMultipleObjects(numOfHandles, handles, FALSE, timeout);
在client是起一个线程不断地读管道的数据，可是读到数据后是有一个处理数据的过程。
而在曾经的版本号呻这个过程仅仅是PostMessage一个消息，就继续去ReadFile了；而在新的版本号中读到数据却是花了非常多时间去处理数据，然后才去ReadFile。
导致服务端管道写堵塞的原因：
我们设置的模式是PIPE_WAIT，依据MSDN的要求是：当一端在写时，还有一要发生读的动作，才干写成功；否则堵塞。
hPipe = CreateNamedPipe("Name",
PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED,
PIPE_TYPE_BYTE | PIPE_READMODE_BYTE | PIPE_WAIT,
PIPE_UNLIMITED_INSTANCES,
0,
0,
0, /*XENHANCE_PIPE_TIMEOUT*/
&sa);
解决方法 ：
法一、在服务端的管道写时设置超时时间，这尽管能使用服务端管道的线程不卡死，但也可能该写的数据没有写进去。
法一、在服务端的管道写时设置超时时间，这尽管能使用服务端管道的线程不卡死，但也可能该写的数据没有写进去。
法二、依据上图所看到的，去掉“管道Client端“中的”等待RetEvent事件。
缺点：“管道Client端“不知道自己要求”管道Service端“运行的动作的结果。
1、
2、
3、
4、
5、
6、
7、
200
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
