进程通信

本文处处： http://blog.csdn.net/lauo1188/article/details/4438223

 

进程通信

2007-10-05 10:55

 

概述 管道（Pipe）实际是用于进程间通信的一段共享内存，创建管道的进程称为管道服务器，连接到一个管道的进程为管道客户机。命名管道（Named Pipes）是在管道服务器和一台或多台管道客户机之间进行单向或双向通信的一种命名的管道。一个命名管道的所有实例共享同一个管道名，但是每一个实例均拥有独立的缓存与句柄，并且为客户——服务通信提供有一个分离的管道。实例的使用保证了多个管道客户能够在同一时间使用同一个命名管道。 Microsoft Windows NT、Windows 2000、Windows 95以及Windows 98均提供对命名管道的支持（不包括Windows CE），但只有Windows NT和Windows 2000才支持服务器端的命名管道技术。命名管道可以在同一台计算机的不同进程之间，或在跨越一个网络的不同计算机的不同进程之间进行有连接的可靠数据通信，如果连接中断，连接双方都能立即收到连接断开的信息。命令管道是围绕Windows文件系统而设计的一种机制，采用的是命名管道文件系统（Named Pipe File System, NPFS）接口。对数据的收发也采用文件读写函数ReadFile（）和WriteFile（）来完成。在设计上，由于命名管道也利用了微软网络提供者（MSNP）重定向器，因此无需涉及底层的通信协议细节。命名管道还充分利用了Windows NT及Windows 2000内建的安全特性，通信的安全性相对较好。 命名规范及通信模式 每一个命名管道都有一个唯一的名字以区分于存在于系统的命名对象列表中的其他命名管道。管道服务器在调用CreateNamedPipe（）函数创建命名管道的一个或多个实例时为其指定了名称。对于管道客户机，则是在调用CreateFile（）或CallNamedPipe（）函数以连接一个命名管道实例时对管道名进行指定。命名管道的命名规范与邮槽有些类似，对其标识也是采用的UNC格式： //Server/Pipe/[Path]Name 其中，第一部分//Server指定了服务器的名字，命名管道服务即在此服务器创建，其字串部分可表示为一个小数点（表示本机）、星号（当前网络字段）、域名或是一个真正的服务；第二部分/Pipe与邮槽的/Mailslot一样是一个不可变化的硬编码字串，以指出该文件是从属于NPFS；第三部分/[Path]Name则使应用程序可以唯一定义及标识一个命名管道的名字，而且可以设置多级目录。 命名管道提供了两种基本的通信模式：字节模式和消息模式。可在CreateNamePipe（）创建命名管道时分别用PIPE_TYPE_BYTE和PIPE_TYPE_MESSAGE标志进行设定。在字节模式中，信息以连续字节流的形式在客户与服务器之间流动。这也就意味着，对于客户机应用和服务器应用，在任何一个特定的时间段内，都无法准确知道有多少字节从管道中读出或写入。在这种通信模式中，一方在向管道写入某个数量的字节后，并不能保证管道另一方能读出等量的字节。对于消息模式，客户机和服务器则是通过一系列不连续的数据包进行数据的收发。从管道发出的每一条消息都必须作为一条完整的消息读入。 概述 作者: 中国电波传播研究所青岛分所郎锐 时间: 2004-09-27 出处: 天极网 管道（Pipe）实际是用于进程间通信的一段共享内存，创建管道的进程称为管道服务器，连接到一个管道的进程为管道客户机。命名管道（Named Pipes）是在管道服务器和一台或多台管道客户机之间进行单向或双向通信的一种命名的管道。一个命名管道的所有实例共享同一个管道名，但是每一个实例均拥有独立的缓存与句柄，并且为客户——服务通信提供有一个分离的管道。实例的使用保证了多个管道客户能够在同一时间使用同一个命名管道。 Microsoft Windows NT、Windows 2000、Windows 95以及Windows 98均提供对命名管道的支持（不包括Windows CE），但只有Windows NT和Windows 2000才支持服务器端的命名管道技术。命名管道可以在同一台计算机的不同进程之间，或在跨越一个网络的不同计算机的不同进程之间进行有连接的可靠数据通信，如果连接中断，连接双方都能立即收到连接断开的信息。命令管道是围绕Windows文件系统而设计的一种机制，采用的是命名管道文件系统（Named Pipe File System, NPFS）接口。对数据的收发也采用文件读写函数ReadFile（）和WriteFile（）来完成。在设计上，由于命名管道也利用了微软网络提供者（MSNP）重定向器，因此无需涉及底层的通信协议细节。命名管道还充分利用了Windows NT及Windows 2000内建的安全特性，通信的安全性相对较好。 命名规范及通信模式 每一个命名管道都有一个唯一的名字以区分于存在于系统的命名对象列表中的其他命名管道。管道服务器在调用CreateNamedPipe（）函数创建命名管道的一个或多个实例时为其指定了名称。对于管道客户机，则是在调用CreateFile（）或CallNamedPipe（）函数以连接一个命名管道实例时对管道名进行指定。命名管道的命名规范与邮槽有些类似，对其标识也是采用的UNC格式： //Server/Pipe/[Path]Name 其中，第一部分//Server指定了服务器的名字，命名管道服务即在此服务器创建，其字串部分可表示为一个小数点（表示本机）、星号（当前网络字段）、域名或是一个真正的服务；第二部分/Pipe与邮槽的/Mailslot一样是一个不可变化的硬编码字串，以指出该文件是从属于NPFS；第三部分/[Path]Name则使应用程序可以唯一定义及标识一个命名管道的名字，而且可以设置多级目录。 命名管道提供了两种基本的通信模式：字节模式和消息模式。可在CreateNamePipe（）创建命名管道时分别用PIPE_TYPE_BYTE和PIPE_TYPE_MESSAGE标志进行设定。在字节模式中，信息以连续字节流的形式在客户与服务器之间流动。这也就意味着，对于客户机应用和服务器应用，在任何一个特定的时间段内，都无法准确知道有多少字节从管道中读出或写入。在这种通信模式中，一方在向管道写入某个数量的字节后，并不能保证管道另一方能读出等量的字节。对于消息模式，客户机和服务器则是通过一系列不连续的数据包进行数据的收发。从管道发出的每一条消息都必须作为一条完整的消息读入。 使用命名管道 管道服务器首次调用CreateNamedPipe（）函数时，使用nMaxInstance参数指定了能同时存在的管道实例的最大数目。服务器可以重复调用CreateNamedPipe（）函数去创建管道新的实例，直至达到设定的最大实例数。下面给出CreateNamedPipe（）的函数原型： HANDLE CreateNamedPipe( LPCTSTR lpName, // 指向管道名称的指针 DWORD dwOpenMode, // 管道打开模式 DWORD dwPipeMode, // 管道模式 DWORD nMaxInstances, // 最大实例数 DWORD nOutBufferSize, // 输出缓存大小 DWORD nInBufferSize, // 输入缓存大小 DWORD nDefaultTimeOut, // 超时设置 LPSECURITY_ATTRIBUTES lpSecurityAttributes // 安全属性指针 ); 如果在已定义超时值变为零以前，有一个实例管道可以使用，则创建成功并返回管道句柄，以此侦听来自客户机的连接请求。另一方面，客户机通过函数WaitNamedPipe（）使服务器进程等待来自客户的实例连接。如果在超时值变为零以前，有一个管道可供连接使用，则函数将成功返回，并通过调用CreateFile（）或CallNamedPipe（）来呼叫对服务器的连接。此时服务器将接受客户的连接请求，成功建立连接，服务器调用的等待客户机建立连接的ConnectNamedPipe（）函数也将成功返回。  从调用时序上看，首先是客户机通过WaitNamedPipe（）使服务器的CreateFile（）在限时时间内创建实例成功，然后双方通过ConnectNamedPipe（）和CreateFile（）成功连接，在返回用以通信的文件句柄后，客户、服务双方即可进行通信。  在建立了连接后，客户机与服务器即可通过ReadFile（）和WriteFile（）并利用得到的管道句柄，以文件读写的形式彼此间进行信息交换。 当客户与服务器的通信结束，或是由于某种原因一方需要断开时，由客户机调用CloseFile（）函数关闭打开的管道句柄，服务器随即调用DisconnectNamedPipe（）函数。当然，服务器也可以通过单方面调用DisconnectNamedPipe（）来终止连接。在终止连接后调用函数CloseHandle（）来关闭此管道。下面给出的程序清单即是按照上述方法实现的命名管道服务器和客户机进行通信的简单程序实现代码： 服务器端： m_hPipe = CreateNamedPipe("////.//Pipe//Test", PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE | PIPE_READMODE_BYTE, 1, 0, 0, 1000, NULL); // 创建命名管道 if (m_hPipe == INVALID_HANDLE_VALUE) m_sMessage = "创建命名管道失败!"; else{ m_sMessage = "成功创建命名管道!"; AfxBeginThread(ReadProc, this); // 开启线程 } 由于ConnectNamedPipe（）函数在没有客户机连接到服务器时会无限等待下去，因此为避免由此引起主线程的阻塞，为其开辟了一个子线程ReadProc： UINT ReadProc(LPVOID lpVoid) { char buffer[1024]; // 数据缓存 DWORD ReadNum; CServerView* pView = (CServerView*)lpVoid; // 获取视句柄 if (ConnectNamedPipe(pView->m_hPipe, NULL) == FALSE) // 等待客户机的连接 { CloseHandle(pView->m_hPipe); // 关闭管道句柄 pView->m_sMessage = "与客户机建立连接失败!"; // 显示信息 pView->Invalidate(); return 0; }else{ pView->m_sMessage = "与客户机建立连接!"; // 显示信息 pView->Invalidate(); } // 从管道读取数据 if (ReadFile(pView->m_hPipe, buffer, sizeof(buffer), &ReadNum, NULL) == FALSE) { CloseHandle(pView->m_hPipe); // 关闭管道句柄 pView->m_sMessage = "从管道读取数据失败!"; // 显示信息 pView->Invalidate(); } else { buffer[ReadNum] = '/0'; // 显示接收到的信息 pView->m_sMessage = CString(buffer); pView->Invalidate(); } return 1; } 在客户同服务器建立连接后，ConnectNamedPipe（）才会返回，其下语句才得以执行。随后的ReadFile（）将负责把客户写入管道的数据读取出来。在全部操作完成后，服务器可以通过调用函数DisconnectNamedPipe（）而终止连接： if (DisconnectNamedPipe(m_hPipe) == FALSE) // 终止连接 m_sMessage = "终止连接失败!"; else { CloseHandle(m_hPipe); // 关闭管道句柄 m_sMessage = "成功终止连接!"; } 客户机端： CString Message = "[测试数据,由客户机发出]"; // 要发送的数据 DWORD WriteNum; // 发送的是数据长度 // 等待与服务器的连接 if (WaitNamedPipe("////.//Pipe//Test", NMPWAIT_WAIT_FOREVER) == FALSE) { m_sMessage = "等待连接失败!"; // 显示信息 Invalidate(); return; } // 打开已创建的管道句柄 HANDLE hPipe = CreateFile("////.//Pipe//Test", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); if (hPipe == INVALID_HANDLE_VALUE) { m_sMessage = "管道打开失败!"; // 显示信息 Invalidate(); return; } else { m_sMessage = "成功打开管道!"; // 显示信息 Invalidate(); } // 向管道写入数据 if (WriteFile(hPipe, Message, Message.GetLength(), &WriteNum, NULL) == FALSE) { m_sMessage = "数据写入管道失败!"; // 显示信息 Invalidate(); } else { m_sMessage = "数据成功写入管道!"; // 显示信息 Invalidate(); } CloseHandle(hPipe); // 关闭管道句柄   你可以通过这个链接引用该篇文章:http://boldeagle.bokee.com/tb.b?diaryId=177037262 2007.9.21 09:52 作者：boldeagle  收藏 | 评论：0 | 阅读：14   windows下进程间通信的手段有哪些 分类:编程点滴   http://hi.baidu.com/wanhongnan/blog/item/d72d9e440f12674c500ffe6e.html 摘 要 随着人们对应用程序的要求越来越高，单进程应用在许多场合已不能满足人们的要求。编写多进程/多线程程序成为现代程序设计的一个重要特点，在多进程程序设计中，进程间的通信是不可避免的。Microsoft Win32 API提供了多种进程间通信的方法，全面地阐述了这些方法的特点，并加以比较和分析，希望能给读者选择通信方法提供参考。 关键词 进程 进程通信 IPC Win32 API 1 进程与进程通信 进程是装入内存并准备执行的程序，每个进程都有私有的虚拟地址空间，由代码、数据以及它可利用的系统资源(如文件、管道等)组成。多进程/多线程是Windows操作系统的一个基本特征。Microsoft Win32应用编程接口(Application Programming Interface, API)提供了大量支持应用程序间数据共享和交换的机制，这些机制行使的活动称为进程间通信(InterProcess Communication, IPC)，进程通信就是指不同进程间进行数据共享和数据交换。 正因为使用Win32 API进行进程通信方式有多种，如何选择恰当的通信方式就成为应用开发中的一个重要问题，下面本文将对Win32中进程通信的几种方法加以分析和比较。 2 进程通信方法 2.1 文件映射 文件映射(Memory-Mapped Files)能使进程把文件内容当作进程地址区间一块内存那样来对待。因此，进程不必使用文件I/O操作，只需简单的指针操作就可读取和修改文件的内容。 Win32 API允许多个进程访问同一文件映射对象，各个进程在它自己的地址空间里接收内存的指针。通过使用这些指针，不同进程就可以读或修改文件的内容，实现了对文件中数据的共享。 应用程序有三种方法来使多个进程共享一个文件映射对象。 (1)继承：第一个进程建立文件映射对象，它的子进程继承该对象的句柄。 (2)命名文件映射：第一个进程在建立文件映射对象时可以给该对象指定一个名字(可与文件名不同)。第二个进程可通过这个名字打开此文件映射对象。另外，第一个进程也可以通过一些其它IPC机制(有名管道、邮件槽等)把名字传给第二个进程。 (3)句柄复制：第一个进程建立文件映射对象，然后通过其它IPC机制(有名管道、邮件槽等)把对象句柄传递给第二个进程。第二个进程复制该句柄就取得对该文件映射对象的访问权限。 文件映射是在多个进程间共享数据的非常有效方法，有较好的安全性。但文件映射只能用于本地机器的进程之间，不能用于网络中，而开发者还必须控制进程间的同步。 2.2 共享内存 Win32 API中共享内存(Shared Memory)实际就是文件映射的一种特殊情况。进程在创建文件映射对象时用0xFFFFFFFF来代替文件句柄(HANDLE)，就表示了对应的文件映射对象是从操作系统页面文件访问内存，其它进程打开该文件映射对象就可以访问该内存块。由于共享内存是用文件映射实现的，所以它也有较好的安全性，也只能运行于同一计算机上的进程之间。 2.3 匿名管道 管道(Pipe)是一种具有两个端点的通信通道：有一端句柄的进程可以和有另一端句柄的进程通信。管道可以是单向－一端是只读的，另一端点是只写的；也可以是双向的一管道的两端点既可读也可写。 匿名管道(Anonymous Pipe)是 在父进程和子进程之间，或同一父进程的两个子进程之间传输数据的无名字的单向管道。通常由父进程创建管道，然后由要通信的子进程继承通道的读端点句柄或写 端点句柄，然后实现通信。父进程还可以建立两个或更多个继承匿名管道读和写句柄的子进程。这些子进程可以使用管道直接通信，不需要通过父进程。 匿名管道是单机上实现子进程标准I/O重定向的有效方法，它不能在网上使用，也不能用于两个不相关的进程之间。 2.4 命名管道 命名管道(Named Pipe)是服务器进程和一个或多个客户进程之间通信的单向或双向管道。不同于匿名管道的是命名管道可以在不相关的进程之间和不同计算机之间使用，服务器建立命名管道时给它指定一个名字，任何进程都可以通过该名字打开管道的另一端，根据给定的权限和服务器进程通信。 命名管道提供了相对简单的编程接口，使通过网络传输数据并不比同一计算机上两进程之间通信更困难，不过如果要同时和多个进程通信它就力不从心了。 2.5 邮件槽 邮件槽(Mailslots)提 供进程间单向通信能力，任何进程都能建立邮件槽成为邮件槽服务器。其它进程，称为邮件槽客户，可以通过邮件槽的名字给邮件槽服务器进程发送消息。进来的消 息一直放在邮件槽中，直到服务器进程读取它为止。一个进程既可以是邮件槽服务器也可以是邮件槽客户，因此可建立多个邮件槽实现进程间的双向通信。 通过邮件槽可以给本地计算机上的邮件槽、其它计算机上的邮件槽或指定网络区域中所有计算机上有同样名字的邮件槽发送消息。广播通信的消息长度不能超过400字节，非广播消息的长度则受邮件槽服务器指定的最大消息长度的限制。 邮件槽与命名管道相似，不过它传输数据是通过不可靠的数据报(如TCP/IP协议中的UDP包)完成的，一旦网络发生错误则无法保证消息正确地接收，而命名管道传输数据则是建立在可靠连接基础上的。不过邮件槽有简化的编程接口和给指定网络区域内的所有计算机广播消息的能力，所以邮件槽不失为应用程序发送和接收消息的另一种选择。 2.6 剪贴板 剪贴板(Clipped Board)实质是Win32 API中一组用来传输数据的函数和消息，为Windows应用程序之间进行数据共享提供了一个中介，Windows已建立的剪切(复制)－粘贴的机制为不同应用程序之间共享不同格式数据提供了一条捷径。当用户在应用程序中执行剪切或复制操作时，应用程序把选取的数据用一种或多种格式放在剪贴板上。然后任何其它应用程序都可以从剪贴板上拾取数据，从给定格式中选择适合自己的格式。 剪贴板是一个非常松散的交换媒介，可以支持任何数据格式，每一格式由一无符号整数标识，对标准(预定义)剪贴板格式，该值是Win32 API定义的常量；对非标准格式可以使用Register Clipboard Format函数注册为新的剪贴板格式。利用剪贴板进行交换的数据只需在数据格式上一致或都可以转化为某种格式就行。但剪贴板只能在基于Windows的程序中使用，不能在网络上使用。 2.7 动态数据交换 动态数据交换(DDE)是使用共享内存在应用程序之间进行数据交换的一种进程间通信形式。应用程序可以使用DDE进行一次性数据传输，也可以当出现新数据时，通过发送更新值在应用程序间动态交换数据。 DDE和剪贴板一样既支持标准数据格式(如文本、位图等)，又可以支持自己定义的数据格式。但它们的数据传输机制却不同，一个明显区别是剪贴板操作几乎总是用作对用户指定操作的一次性应答－如从菜单中选择Paste命令。尽管DDE也可以由用户启动，但它继续发挥作用一般不必用户进一步干预。DDE有三种数据交换方式： (1) 冷链：数据交换是一次性数据传输，与剪贴板相同。 (2) 温链：当数据交换时服务器通知客户，然后客户必须请求新的数据。 (3) 热链：当数据交换时服务器自动给客户发送数据。 DDE交换可以发生在单机或网络中不同计算机的应用程序之间。开发者还可以定义定制的DDE数据格式进行应用程序之间特别目的IPC，它们有更紧密耦合的通信要求。大多数基于Windows的应用程序都支持DDE。 2.8 对象连接与嵌入 应用程序利用对象连接与嵌入(OLE)技术管理复合文档(由多种数据格式组成的文档)，OLE提供使某应用程序更容易调用其它应用程序进行数据编辑的服务。例如，OLE支持的字处理器可以嵌套电子表格，当用户要编辑电子表格时OLE库可自动启动电子表格编辑器。当用户退出电子表格编辑器时，该表格已在原始字处理器文档中得到更新。在这里电子表格编辑器变成了字处理器的扩展，而如果使用DDE，用户要显式地启动电子表格编辑器。 同DDE技术相同，大多数基于Windows的应用程序都支持OLE技术。 2.9 动态连接库 Win32动态连接库(DLL)中的全局数据可以被调用DLL的所有进程共享，这就又给进程间通信开辟了一条新的途径，当然访问时要注意同步问题。 虽然可以通过DLL进行进程间数据共享，但从数据安全的角度考虑，我们并不提倡这种方法，使用带有访问权限控制的共享内存的方法更好一些。 2.10 远程过程调用 Win32 API提供的远程过程调用(RPC)使应用程序可以使用远程调用函数，这使在网络上用RPC进行进程通信就像函数调用那样简单。RPC既可以在单机不同进程间使用也可以在网络中使用。 由于Win32 API提供的RPC服从OSF-DCE(Open Software Foundation Distributed Computing Environment)标准。所以通过Win32 API编写的RPC应用程序能与其它操作系统上支持DEC的RPC应用程序通信。使用RPC开发者可以建立高性能、紧密耦合的分布式应用程序。 2.11 NetBios函数 Win32 API提供NetBios函数用于处理低级网络控制，这主要是为IBM NetBios系统编写与Windows的接口。除非那些有特殊低级网络功能要求的应用程序，其它应用程序最好不要使用NetBios函数来进行进程间通信。 2.12 Sockets Windows Sockets规范是以U.C.Berkeley大学BSD UNIX中流行的Socket接口为范例定义的一套Windows下的网络编程接口。除了Berkeley Socket原有的库函数以外，还扩展了一组针对Windows的函数，使程序员可以充分利用Windows的消息机制进行编程。 现在通过Sockets实现进程通信的网络应用越来越多，这主要的原因是Sockets的跨平台性要比其它IPC机制好得多，另外WinSock 2.0不仅支持TCP/IP协议，而且还支持其它协议(如IPX)。Sockets的唯一缺点是它支持的是底层通信操作，这使得在单机的进程间进行简单数据传递不太方便，这时使用下面将介绍的WM_COPYDATA消息将更合适些。 2.13 WM_COPYDATA消息 WM_COPYDATA是一种非常强大却鲜为人知的消息。当一个应用向另一个应用传送数据时，发送方只需使用调用SendMessage函数，参数是目的窗口的句柄、传递数据的起始地址、WM_COPYDATA消息。接收方只需像处理其它消息那样处理WM_COPY DATA消息，这样收发双方就实现了数据共享。 WM_COPYDATA是一种非常简单的方法，它在底层实际上是通过文件映射来实现的。它的缺点是灵活性不高，并且它只能用于Windows平台的单机环境下。 3 结束语 Win32 API为应用程序实现进程间通信提供了如此多种选择方案，那么开发者如何进行选择呢？通常在决定使用哪种IPC方法之前应考虑以下一些问题： (1)应用程序是在网络环境下还是在单机环境下工作