【通信篇】【qnx通信机制】

系列文章

可跳转到下面链接查看下表所有内容https://blog.youkuaiyun.com/handsomethefirst/article/details/138226266?spm=1001.2014.3001.5501文章浏览阅读2次。系列文章大全https://blog.youkuaiyun.com/handsomethefirst/article/details/138226266?spm=1001.2014.3001.5501

---

目录

系列文章

1.简介

1.1 交互图

1.2 状态迁移图

1.2.1 客户端迁移图

 1.2.2 服务端迁移图

2.方法介绍

2.1 name_attach

 2.2 name_detach

 2.3 MsgReceive

 2.4 MsgReply

 2.5 name_open

 2.6 MsgSend

3.如何使用？

3.1 服务端

3.2 客户端

---

---

1.简介

QNX是一个微内核的操作系统，操作系统中，因为每一个进程都拥有自己的独立的进程虚拟地址空间，造成了进程独立性。但进程间总会需要进行交互，因此进程间的通信是难免的。常见的进程间通信有：socket、信号、信号量、andorid特有的binder通信，共享内存等。

本文主要介绍qnx操作系统的同步消息传递机制。

通信步骤和线程状态如下：

1.因为进程间消息的传递通过通道（channel）连接，所以首先服务端需要通过name_attach创建channel，然后调用MsgReceive接收消息。此时客户端没有发送消息，则服务端阻塞，服务端阻塞状态是RECEIVE blocked。

2.客户端调用name_open打开并连接服务端。

3.客户端调用MsgSend发送消息到服务端，若此时服务端没有调用MsgReceive()，则客户端状态是SEND blocked，若此时服务端调用了MsgReceive()，但是服务端还没调用MsgReply()/MsgError()，则客户端处于REPLY blocked。

4.服务端接收到客户端发送的消息后处理消息，此时服务端状态为ready状态。并调用MsgReply回复client。

1.1 交互图

1.2 状态迁移图

1.2.1 客户端迁移图

 send blocked：当客户端调用Msgsend函数后，服务端并没有调用MsgReceive的状态。

reply blocked：当客户端调用Msgsend函数后，服务端也调用了MsgReceive，但服务端还未调用

MsgReply/MsgError的状态。

ready：当客户端调用Msgsend函数后，服务端也调用了MsgReceive和MsgReply/MsgError的状态。

---

 1.2.2 服务端迁移图

 receive blocked：服务端调用MsgRecevie，但是客户端没调用Msgsend的状态。

ready：服务端调用MsgRecevie，然后客户端调用Msgsend的状态。

2.方法介绍

2.1 name_attach

//在路径名空间中注册一个名称并创建一个通道
name_attach_t * name_attach( dispatch_t * dpp,
                             const char * path,
                             unsigned flags );
//dpp可以是null，或者是成功调用dispatch_create（）或dispatch_ccreate_channel（）返回的调度句柄。
//path是要在/dev/name/[local|global]/下注册的路径。
//flags 这是控制函数行为的标志位。如果是NAME_FLAG_ATTACH_GLOBAL，代表创建全局的附加名称。默认附在本地
//返回值：返回一个指向name_attach_t结构的指针，结构如下：
//如果失败，则返回为空


typedef struct _name_attach {
dispatch_t* dpp; //创建此连接时使