1846人阅读
在向管道写数据和读数据时我们经常会用到WinUsb_ReadPipe和WinUsb_WritePipe。
现在我对这两个函数还是不太理解，所以打算自己看英文文档说明，在此记录下。
WinUsb_ReadPipe（这个函数一般处理的是IN包后，USB从机向主机发送过来的数据）
BOOL __stdcall WinUsb_ReadPipe(
_In_&&&&&&&WINUSB_INTERFACE_HANDLE InterfaceHandle,
_In_&&&&&&&UCHAR PipeID,
_Out_&&&&&&PUCHAR Buffer,
_In_&&&&&&&ULONG BufferLength,
_Out_opt_&&PULONG LengthTransferred,
_In_opt_&&&LPOVERLAPPED Overlapped
功能：从指定的管道读数据
第一个参数：InterfaceHandle：和那个端点的那个管道联接。
第二个参数：PipeID,就是管道的地址，第7位表示端点数据方向：0表示OUT（主-从），1表示IN（从-主）。
第三个参数：Buffer,接收读取的数据的缓冲区。
第四个参数：BufferLength,读取数据的最大个数，这个值必须小于或等于Buffer缓冲区中的字节个数。
第五个参数：LengthTransferred&，一个无符号长整型指针，接收实际复制到Buffer缓冲区中的个数。
第六个参数：Overlapped，一般定为一个空指针，NULL。
返回值：操作成功返回TRUE，失败返回FALSE。（GetLastError获取错误返回值）
如果设备返回数据（我理解是INpacket）大于最大的传输长度，WinUSB将分离这个数据成一较小段的，并且连续提交。如果这个传输数据的长度不是最大传输长度的整数倍，WINUSB就会把他增加到最大传输个数的倍数。
USB包的大小不考虑传输请求，如果设备响应了一个对现在的缓冲区来说较大的包，并且读请求符合管道上指针的类型，如果管道指针允许部分读取（ALLOW_PARTIAL_READS,），WINUSB将把剩下的数据放在下次传输的开头，
如果第六个参数为非空，第五个参数设置的值是无意义的。
如果PIPE为空，WinUsb_ReadPipe我们函数不返回直到PIPE中有数据，如果出现错误状况或者超时，函数就返回FALSE,（GetLastError获取错误返回值）.
&&相关文章推荐
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：22782次
排名：千里之外
原创：29篇
(2)(1)(1)(2)(1)(2)(4)(1)(1)(1)(1)(2)(7)(4)Linux + IPC_Linux系统_ThinkSAAS
Linux + IPC
Linux + IPC
内容来源：
reference:
RPC Remote Procedure Call Protocol 远程调用协议
IPC信息技术有限公司，总部设于新加坡，信息技术公司
进程间通讯
Internet Process Connection
计算机专业
Industrial
Control,工业过程控制
Information
Processing
信息[情报]处理中心
Information
Processing
信息处理代码
Correction,
初始相位校正
Integrated
Peripheral
集成外围通道
对Unix发展做出重大贡献的两大主力AT&T的贝尔实验室及BSD（加州大学伯克利分校的伯克利软件发布中心）在进程间通信方面的侧重点有所不同
前者对Unix早期的进程间通信手段进行了系统的改进和扩充，形成了“system V IPC”，通信进程局限在单个计算机内；
后者则跳过了该限制，形成了基于套接口（socket）的进程间通信机制,（socket本身就可以用于单机内的进程间通信）
最初Unix IPC包括：管道、FIFO、信号
System V IPC包括：System V消息队列、System V信号灯、System V共享内存区；
Posix IPC包括： Posix消息队列、Posix信号灯、Posix共享内存区。
共享内存来说，有Posix共享内存区以及System V共享内存区两个实现版本
Windows系统中进程之间的通信方式 RPC
Remote Procedure Call
windows里VB和VC的两个程序通讯，就是用内存映射、消息、pipe，当然还有socket
linux和windows编译器用到的库不同，具体函数在实现上可能有不同，但是理论上是相同的
UNIX 操作系统中进程之间调用的通信方式
1,管道 pipe 和 命名管道
named pipe
, semaphore
3,消息队列
First Input First Output，先入先出队列 报文队列
MQ Message queue
4,共享内存 shared memory
5,socket通讯
一般情况下，流是通过unix
socket实现的,
linux下的进程通信手段基本上是从Unix平台上的进程通信手段继承而来的
linux下进程间通信的几种主要手段简介
管道（Pipe）及有名管道（named pipe）：
管道可用于具有亲缘关系进程间的通信，有名管道克服了管道没有名字的限制，因此，除具有管道所具有的功能外，它还允许无亲缘关系进程间的通信；
信号（Signal）：
信号是比较复杂的通信方式，用于通知接受进程有某种事件发生，除了用于进程间通信外，进程还可以发送信号给进程本身；
报文（Message）队列（消息队列）：
消息队列是消息的链接表，包括Posix消息队列system V消息队列,有足够权限的进程可以向队列中添加消息，被赋予读权限的进程则可以读走队列中的消息。消息队列克服了信号承载信息量少，管道只能承载无格式字节流以及缓冲区大小受限等缺点。
共享内存：使得多个进程可以访问同一块内存空间，是最快的可用IPC形式。是针对其他通信机制运行效率较低而设计的。往往与其它通信机制，如信号量结合使用，来达到进程间的同步及互斥。
信号量（semaphore）：
主要作为进程间以及同一进程不同线程之间的同步手段。
套接口（Socket）：
更为一般的进程间通信机制，可用于不同机器之间的进程间通信。起初是由Unix系统的BSD分支开发出来的，但现在一般可以移植到其它类Unix系统上：Linux和System V的变种都支持套接字。
一般来说，linux下的进程包含以下几个关键要素：
有一段可执行程序；
有专用的系统堆栈空间；
内核中有它的控制块（进程控制块），描述进程所占用的资源，这样，进程才能接受内核的调度；
具有独立的存储空间
进程和线程有时候并不完全区分，而往往根据上下文理解其含义。
参考文献：
UNIX环境高级
，作者：W.Richard Stevens，译者：尤晋元等，机械工业出版社。具有丰富的
实例，以及关键函数伴随Unix的发展历程。
linux内核源代码情景分析（上、下），毛德操、胡希明著，浙江大学出版社，提供了对linux内核非常好的分析，同时，对一些关键概念的背景进行了详细的说明。
第二卷：进程间通信，作者：W.Richard Stevens，译者：杨继张，清华大学出版社。一本比较全面阐述Unix环境下进程间通信的书（没有信号和套接口，套接口在第一卷中）。
----------------------------------------------------------------------------------------------------------------------------------
Linux进程间通信
Linux环境进程间通信 ——无名管道工作机制研究
Linux作为一个开源的操作系统，是我们进行操作系统和提高编程水平的最佳途径之一。
好的程序如同好的音乐一样，完成的完美、巧妙。开放源码的程序都是经过无数人检验地，本文将以linux-kernel-2.6.5为例对pipe的工作机制进行阐述。
二、进程间通信的分类
大型程序大多会涉及到某种形式的进程间通信，一个较大型的应用程序设计成可以相互通信的“碎片”，从而就把一个任务分到多个进程中去。进程间通信的方法有三种方式：
管道（pipe）
套接字（socket）
System v IPC 机制
管道机制在UNIX开发的早期就已经提供了，它在本机上的两个进程间的数据传递表现的相当出色；套接字是在BSD（Berkeley Software Development）中出现的，现在的应用也相当的广泛；而System V IPC机制Unix System V 版本中出现的。
三、工作机制
管道分为pipe（无名管道）和FIFO（
命名管道），它们都是通过内核缓冲区按先进先出的方式数据传输，管道一端顺序地写入数据，另一端顺序地读入数据读写的位置都是自动增加，数据只读一次，之后就被释放。在缓冲区写满时，则由相应的规则控制读写进程进入等待队列，当空的缓冲区有写入数据或满的缓冲区有数据读出时，就唤醒等待队列中的写进程继续读写。
管道的读写规则：
管道两端可分别用描述字fd[0]以及fd[1]来描述，需要注意的是，管道的两端是固定了任务的。即一端只能用于读，由描述字fd[0]表示，称其为管道读端；另一端则只能用于写，由描述字fd[1]来表示，称其为管道写端。如果试图从管道写端读取数据，或者向管道读端写入数据都将导致错误发生。一般文件的I/O函数都可以用于管道，如close、read、write等等。
四、pipe的数据结构
首先要定义一个文件系统类型：pipe_fs_type。
static struct file_system_type pipe_fs_type = {
= "pipefs",
= pipefs_get_sb,
= kill_anon_super,
变量pipe_fs_type其类型是 struct file_system_type 用于向系统注册文件系统。
Pipe以类似文件的方式与进程交互，但在磁盘上无对应节点，因此效率较高。Pipe主要包括一个inode和两个file结构——分别用于读和写。Pipe的缓冲区首地址就存放在inode的i_pipe域指向pipe_inode_info结构中。但是要注意pipe的inode并没有磁盘上的映象，只在内存中交换数据。
static struct super_block *pipefs_get_sb(struct file_system_type *fs_type,
int flags, const char *dev_name, void *data)
return get_sb_pseudo(fs_type, "pipe:", NULL, PIPEFS_MAGIC);
上为超级的生成函数。
Include/linux/pipe.h
#ifndef _LINUX_PIPE_FS_I_H
#define _LINUX_PIPE_FS_I_H
#define PIPEFS_MAGIC 0x
struct pipe_inode_info {
wait_queue_head_
unsigned int waiting_
unsigned int r_
unsigned int w_
struct fasync_struct *fasync_
struct fasync_struct *fasync_
2 管道等待队列指针wait
3 内核缓冲区基地址base
4 缓冲区当前数据量
6 管道的读者数据量
7 管道的写者数据量
8 等待队列的读者个数
9 等待队列的写者个数
11、12 主要对 FIFO
五、管道的创建:
通过pipe系统调用来创建管道。
int do_pipe(int *fd)
char name[32];
struct dentry *
struct inode *
struct file *f1, *f2;
error = -ENFILE;
f1 = get_empty_filp();
//分配文件对象，得到文件对象指针用于读管道
f2 = get_empty_filp();
//分配文件对象，得到文件对象指针用于读管道
goto close_f1;
inode = get_pipe_inode();
//调用get_pipe_inode获得管道类型的索引节点
if (!inode)
的指针inode。
goto close_f12;
error = get_unused_fd();
//获得当前进程的两个文件描述符。在当前的
if (error & 0)
进程的进程描述符file域中，有一个fd 域，
goto close_f12_
//指向该进程当前打开文件指针数组，数组
元素是指向文件对象的指针。
error = get_unused_fd();
if (error & 0)
goto close_f12_inode_i;
error = -ENOMEM;
sprintf(name, "[%lu]", inode-&i_ino);
//生成对象目录dentry，
this.name =
并通过它将上述两个文
this.len = strlen(name);
件对象将的指针与管道
this.hash = inode-&i_ /* will go */
索引节点连接起来。
dentry = d_alloc(pipe_mnt-&mnt_sb-&s_root, &this);
if (!dentry)
goto close_f12_inode_i_j;
dentry-&d_op = &pipefs_dentry_
d_add(dentry, inode);
f1-&f_vfsmnt = f2-&f_vfsmnt = mntget(mntget(pipe_mnt));
f1-&f_dentry = f2-&f_dentry = dget(dentry);
f1-&f_mapping = f2-&f_mapping = inode-&i_
/* read file */
f1-&f_pos = f2-&f_pos = 0;
//为用于读的两个文件对象设置属性值
f1-&f_flags = O_RDONLY;
f_flage设置为只读，f_op设置为
f1-&f_op = &read_pipe_
read_pipe_fops 结构的地址。
f1-&f_mode = 1;
f1-&f_version = 0;
/* write file */
//为用于写的两个文件对象设置属性值
f2-&f_flags = O_WRONLY;
f_flage设置为只写，f_op设置为
write_pipe_fops 结构的地址。
f2-&f_op = &write_pipe_
f2-&f_mode = 2;
f2-&f_version = 0;
fd_install(i, f1);
fd_install(j, f2);
//将两个文件描述符放入参数fd数组返回
close_f12_inode_i_j:
put_unused_fd(j);
close_f12_inode_i:
put_unused_fd(i);
close_f12_inode:
free_page((unsigned long) PIPE_BASE(*inode));
kfree(inode-&i_pipe);
inode-&i_pipe = NULL;
iput(inode);
close_f12:
put_filp(f2);
put_filp(f1);
六、管道的释放
管道释放时f-op的release域在读管道和写管道中分别指向pipe_read_release()和pipe_write_release()。而这两个函数都调用release（），并决定是否释放pipe的内存页面或唤醒该管道等待队列的进程。
以下为管道释放的代码：
static int pipe_release(struct inode *inode, int decr, int decw)
down(PIPE_SEM(*inode));
PIPE_READERS(*inode) -=
PIPE_WRITERS(*inode) -=
if (!PIPE_READERS(*inode) && !PIPE_WRITERS(*inode)) {
struct pipe_inode_info *info = inode-&i_
inode-&i_pipe = NULL;
free_page((unsigned long) info-&base);
kfree(info);
wake_up_interruptible(PIPE_WAIT(*inode));
kill_fasync(PIPE_FASYNC_READERS(*inode), SIGIO, POLL_IN);
kill_fasync(PIPE_FASYNC_WRITERS(*inode), SIGIO, POLL_OUT);
up(PIPE_SEM(*inode));
return 0;}
七、管道的读写
1．从管道中读取数据：
如果管道的写端不存在，则认为已经读到了数据的末尾，读函数返回的读出字节数为0；
当管道的写端存在时，如果请求的字节数目大于PIPE_BUF，则返回管道中现有的数据字节数，如果请求的字节数目不大于PIPE_BUF，则返回管道中现有数据字节数（此时，管道中数据量小于请求的数据量）；或者返回请求的字节数（此时，管道中数据量不小于请求的数据量）。
2．向管道中写入数据：
向管道中写入数据时，linux将不保证写入的原子性，管道缓冲区一有空闲区域，写进程就会试图向管道写入数据。如果读进程不读走管道缓冲区中的数据，那么写操作将一直阻塞。
八、管道的局限性
管道的主要局限性正体现在它的特点上：
只支持单向数据流；
只能用于具有亲缘关系的进程之间；
没有名字；
管道的缓冲区是有限的（管道制存在于内存中，在管道创建时，为缓冲区分配一个页面大小）；
管道所传送的是无格式字节流，这就要求管道的读出方和写入方必须事先约定好数据的格式，比如多少字节算作一个消息（或命令、或记录）等等。
写完本文之后，发现有部分不足之处。在由于管道读写的代码过于冗长，限于篇幅不一一列出。有不足和错误之处还请各位老师指正。通过一段时间对Linux的内核代码的学习，开源的程序往往并非由“权威人士”、“享誉海内外的专家”所编写，它们的由一个个普通的程序员写就。但专业造就专家，长时间集中在某个领域中能够创建出据程序员应该珍视的财富。
----------------------------------------------------------------------------------------------------------------------------------
reference:http://blog.csdn.net/hgf_006/archive//1928395.aspx
windows下进程通信方式
随着人们对应用程序的要求越来越高，单进程应用在许多场合已不能满足人们的要求。编写多进程/
多线程程序成为现代程序设计的一个重要特点，在多进程程序设计中，进程间的通信是不可避免的。Microsoft Win32 API
提供了多种进程间通信的方法，全面地阐述了这些方法的特点，并加以比较和分析，希望能给读者选择通信方法提供参考。
进程通信 IPC Win32 API
进程与进程通信
　　进程是装入内存并准备执行的程序，每个进程都有私有的虚拟地址空间，由代码、数据以及它可利用的系统资源(
如文件、管道等)
组成。多进程/
多线程是Windows
操作系统的一个基本特征。Microsoft Win32
应用编程接口(Application Programming Interface, API)
提供了大量支持应用程序间数据共享和交换的机制，这些机制行使的活动称为进程间通信(InterProcess Communication, IPC)
，进程通信就是指不同进程间进行数据共享和数据交换。
　　正因为使用Win32 API
进行进程通信方式有多种，如何选择恰当的通信方式就成为应用开发中的一个重要问题，下面本文将对Win32
中进程通信的几种方法加以分析和比较。
进程通信方法
　　文件映射(Memory-Mapped Files)
能使进程把文件内容当作进程地址区间一块内存那样来对待。因此，进程不必使用文件I/O
操作，只需简单的指针操作就可读取和修改文件的内容。
　　Win32 API
允许多个进程访问同一文件映射对象，各个进程在它自己的地址空间里接收内存的指针。通过使用这些指针，不同进程就可以读或修改文件的内容，实现了对文件中数据的共享。
　　应用程序有三种方法来使多个进程共享一个文件映射对象。
继承：第一个进程建立文件映射对象，它的子进程继承该对象的句柄。
命名文件映射：第一个进程在建立文件映射对象时可以给该对象指定一个名字(
可与文件名不同)
。第二个进程可通过这个名字打开此文件映射对象。另外，第一个进程也可以通过一些其它IPC
有名管道、邮件槽等)
把名字传给第二个进程。
句柄复制：第一个进程建立文件映射对象，然后通过其它IPC
有名管道、邮件槽等)
把对象句柄传递给第二个进程。第二个进程复制该句柄就取得对该文件映射对象的访问权限。
　　文件映射是在多个进程间共享数据的非常有效方法，有较好的安全性。但文件映射只能用于本地机器的进程之间，不能用于网络中，而开发者还必须控制进程间的同步。
　　Win32 API
中共享内存(Shared Memory)
实际就是文件映射的一种特殊情况。进程在创建文件映射对象时用0xFFFFFFFF
来代替文件句柄(HANDLE)
，就表示了对应的文件映射对象是从操作系统页面文件访问内存，其它进程打开该文件映射对象就可以访问该内存块。由于共享内存是用文件映射实现的，所以它也有较好的安全性，也只能运行于同一计算机上的进程之间。
　　管道(Pipe)
是一种具有两个端点的通信通道：有一端句柄的进程可以和有另一端句柄的进程通信。管道可以是单向－一端是只读的，另一端点是只写的；也可以是双向的一管道的两端点既可读也可写。
　　匿名管道(Anonymous Pipe)
在父进程和子进程之间
，或同一父进程的两个子进程
之间传输数据的无名字的单向管道。通常由父进程创建管道，然后由要通信的子进程继承通道的读端点句柄或写
端点句柄，然后实现通信。父进程还可以建立两个或更多个继承匿名管道读和写句柄的子进程。这些子进程可以使用管道直接通信，不需要通过父进程。
　　匿名管道是单机上实现子进程标准I/O
重定向的有效方法，它不能在网上使用，也不能用于两个不相关的进程之间。
　　命名管道(Named Pipe)
是服务器进程和一个或多个客户进程之间通信的单向或双向管道。不同于匿名管道的是命名管道可以在不相关的进程之间和不同计算机之间使用，服务器建立命名管道时给它指定一个名字，任何进程都可以通过该名字打开管道的另一端，根据给定的权限和服务器进程通信。
　　命名管道提供了相对简单的编程接口，使通过网络传输数据并不比同一计算机上两进程之间通信更困难，不过如果要同时和多个进程通信它就力不从心了。
　　邮件槽(Mailslots)
供进程间单向通信能力，任何进程都能建立邮件槽成为邮件槽服务器。其它进程，称为邮件槽客户，可以通过邮件槽的名字给邮件槽服务器进程发送消息。进来的消
息一直放在邮件槽中，直到服务器进程读取它为止。一个进程既可以是邮件槽服务器也可以是邮件槽客户
，因此可建立多个
邮件槽实现进程间的双向
　　通过邮件槽可以给本地计算机上的邮件槽、其它计算机上的邮件槽或指定网络区域中所有计算机上有同样名字的邮件槽发送消息。广播通信的消息长度不能超过400
字节，非广播消息的长度则受邮件槽服务器指定的最大消息长度的限制。
　　邮件槽与命名管道相似，不过它传输数据是通过不可靠的数据报(
协议中的UDP
完成的，一旦网络发生错误则无法保证消息正确地接收，而命名管道传输数据则是建立在可靠连接基础上的。不过邮件槽有简化的编程接口和给指定网络区域内的所有计算机广播消息的能力，所以邮件槽不失为应用程序发送和接收消息的另一种选择。
　　剪贴板(Clipped Board)
实质是Win32 API
中一组用来传输数据的函数和消息，为Windows
应用程序之间进行数据共享提供了一个中介，Windows
已建立的剪切(
－粘贴的机制为不同应用程序之间共享不同格式数据提供了一条捷径。当用户在应用程序中执行剪切或复制操作时，应用程序把选取的数据用一种或多种格式放在剪贴板上。然后任何其它应用程序都可以从剪贴板上拾取数据，从给定格式中选择适合自己的格式。
　　剪贴板是一个非常松散的交换媒介，可以支持任何数据格式，每一格式由一无符号整数标识，对标准(
剪贴板格式，该值是Win32 API
定义的常量；对非标准格式可以使用Register Clipboard Format
函数注册为新的剪贴板格式。利用剪贴板进行交换的数据只需在数据格式上一致或都可以转化为某种格式就行。但剪贴板只能在基于Windows
的程序中使用，不能在网络上使用。
动态数据交换
　　动态数据交换(DDE)
是使用共享内存在应用程序之间进行数据交换的一种进程间通信形式。应用程序可以使用DDE
进行一次性数据传输，也可以当出现新数据时，通过发送更新值在应用程序间动态交换数据。
和剪贴板一样既支持标准数据格式(
如文本、位图等)
，又可以支持自己定义的数据格式。但它们的数据传输机制却不同，一个明显区别是剪贴板操作几乎总是用作对用户指定操作的一次性应答－如从菜单中选择Paste
命令。尽管DDE
也可以由用户启动，但它继续发挥作用一般不必用户进一步干预。DDE
有三种数据交换方式：
冷链：数据交换是一次性数据传输，与剪贴板相同。
温链：当数据交换时服务器通知客户，然后客户必须请求新的数据。
热链：当数据交换时服务器自动给客户发送数据。
交换可以发生在单机或网络中不同计算机的应用程序之间。开发者还可以定义定制的DDE
数据格式进行应用程序之间特别目的IPC
，它们有更紧密耦合的通信要求。大多数基于Windows
的应用程序都支持DDE
对象连接与嵌入
　　应用程序利用对象连接与嵌入(OLE)
技术管理复合文档(
由多种数据格式组成的文档)
提供使某应用程序更容易调用其它应用程序进行数据编辑的服务。例如，OLE
支持的字处理器可以嵌套电子表格，当用户要编辑电子表格时OLE
库可自动启动电子表格编辑器。当用户退出电子表格编辑器时，该表格已在原始字处理器文档中得到更新。在这里电子表格编辑器变成了字处理器的扩展，而如果使用DDE
，用户要显式地启动电子表格编辑器。
技术相同，大多数基于Windows
的应用程序都支持OLE
动态连接库
动态连接库(DLL)
中的全局数据可以被调用DLL
的所有进程共享，这就又给进程间通信开辟了一条新的途径，当然访问时要注意同步问题。
　　虽然可以通过DLL
进行进程间数据共享，但从数据安全的角度考虑，我们并不提倡这种方法，使用带有访问权限控制的共享内存
的方法更好
远程过程调用
　　Win32 API
提供的远程过程调用(RPC)
使应用程序可以使用远程调用函数，这使在网络上用RPC
进行进程通信就像函数调用那样简单。RPC
既可以在单机不同进程间使用也可以在网络中使用。
　　由于Win32 API
服从OSF-DCE(Open Software Foundation Distributed Computing Environment)
标准。所以通过Win32 API
应用程序能与其它操作系统上支持DEC
应用程序通信。使用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
协议，而且还支持其它协议(
的唯一缺点是它支持的是底层通信操作，这使得在单机的进程间进行简单数据传递不太方便，这时使用下面将介绍的WM_COPYDATA
消息将更合适些。
2.13 WM_COPYDATA
　　WM_COPYDATA
是一种非常强大却鲜为人知的消息。当一个应用向另一个应用传送数据时，发送方只需使用调用SendMessage
函数，参数是目的窗口的句柄、传递数据的起始地址、WM_COPYDATA
消息。接收方只需像处理其它消息那样处理WM_COPY DATA
消息，这样收发双方就实现了数据共享。
　　WM_COPYDATA
是一种非常简单的方法，它在底层实际上是通过文件映射
来实现的。它的缺点是灵活性不高，并且它只能用于Windows
平台的单机环境
　　Win32 API
为应用程序实现进程间通信提供了如此多种选择方案，那么开发者如何进行选择呢？通常在决定使用哪种IPC
方法之前应考虑以下一些问题：
应用程序是在网络环境下还是在单机环境下工作。
PHP开发框架
开发工具/编程工具
服务器环境【Linux的高级应用编程】进程间的通信机制
进程 间的 通信 机制 Sailor_forever sailing_ 转载请注明 http://blog.csdn.net/sailor_8318/archive//3658912.aspx 进程 间 通信 就是在不同 进程 之间传播或交换信息，那么不同 进程 之间存在着什么双方都可以访问的介质呢？ 进程
进程间的通信机制
Sailor_forever sailing_ 转载请注明
http://blog.csdn.net/sailor_8318/archive//3658912.aspx
进程间通信就是在不同进程之间传播或交换信息，那么不同进程之间存在着什么双方都可以访问的介质呢？进程的用户空间是互相独立的，一般而言是不能互相访问的，唯一的例外是共享内存区。但是，系统空间却是“公共场所”，所以内核显然可以提供这样的条件。除此以外，那就是双方都可以访问的外设了。在这个意义上，两个进程当然也可以通过磁盘上的普通文件交换信息，或其它数据库中的某些表项和记录交换信息。广义上这也是进程间通信的手段，但是一般都不把这算作“进程间通信”。因为那些通信手段的效率太低了，而人们对进程间通信的要求是要有一定的实时性。
Linux间进程的通信机制来源颇多，其中，最初Unix IPC包括：管道、FIFO、信号；System V IPC包括：System V消息队列、System V信号灯、System V共享内存区；Posix IPC包括： Posix消息队列、Posix信号灯、Posix共享内存区。
1、管道pipe：管道可用于具有亲缘关系进程间的通信，允许一个进程和另一个与它有共同祖先的进程之间进行通信。适用于生产者消费者模型，是一种单向的数据流，一个进程写入数据另外一个进程读取数据。管道基于文件系统，对管道的读写采用read及write系统调用。在最后一个访问管道的进程终止后，管道就被完全删。Pipe的不足之处在于无法打开已经存在的pipe，这样不便于任意两个进程实现共享，除非此管道由共同的祖先创建。
2、FIFO命名管道：克服了管道没有名字的限制，因此，除具有管道所具有的功能外，它还允许无亲缘关系进程间的通信。命名管道存在于目录树中，在文件系统中有对应的文件名。命名管道通过命令mkfifo或系统调用mkfifo来创建。
3、信号：信号是比较复杂的通信方式，用于通知接收进程有某种事件发生，除了用于进程间通信外，进程还可以发送信号给进程本身；除了支持Unix早期信号语义函数signal外，还支持语义符合Posix.1标准的信号函数sigaction。
4、System V IPC：
IPC资源可以由任何进程共享，当需要访问资源时动态建立IPC数据结构，并作为一个IPC标识，进程间通过此标识访问共享资源。不足是关键字KEY_T使用了内核标识，占用了内核资源，而且只能被显式删除
信号灯Semaphores：用于各个进程间的互斥，比内核信号量更为复杂，其为一个或者多个信号量的集合而非象内核一样只有一个值，另外其具备失效安全机制，防止进程异常死亡时无法释放信号量。操作顺序为：semget、semop、semop、semctl。
消息messages：一个进程将消息发往消息队列中，另外一个进程从中读取，读取之后内核将销毁此消息，因此一个消息只可能被一个进程接收。消息由一个公用头和可变长度的数据组成。消息队列克服了信号承载信息量少，管道只能承载无格式字节流以及缓冲区大小受限等缺
共享内存shared memory：多个进程可以将资源放在共享内存中进行共享，是最快的可用IPC形式。是针对其他通信机制运行效率较低而设计的。往往与其它通信机制，如信号量结合使用，来达到进程间的同步及互斥。
5、Socket套接字：允许同一个甚至是不同主机上的进程进行通信，如X windows即是利用socket进行通信。
参考文献：
UNIX环境高级编程，作者：W.Richard Stevens，译者：尤晋元等，机械工业出版社
linux内核源代码情景分析（上、下），毛德操、胡希明著，浙江大学出版社
UNIX网络编程第二卷：进程间通信，作者：W.Richard Stevens，译者：杨继张，清华大学出版社。
深入理解Linux内核 第19章进程通信
深刻理解Linux进程间通信（IPC）
http://blog.chinaunix.net/u/786/showart.php?id=16443
Linux系统下进程间通信主要几种手段
你最喜欢的