文档库 最新最全的文档下载
当前位置:文档库 › 5.进程间的通信原理之消息队列

5.进程间的通信原理之消息队列

5.进程间的通信原理之消息队列
5.进程间的通信原理之消息队列

进程间通信之消息队列

一.原理讲解

消息队列(也叫报文队列),它是System V3中进程间通信中的一种。

消息队列就是一个消息的链表。我们可以把这个消息看成一个记录[固定

的格式]。这个记录中包含了很多的信息,并且具有一定的格式和优先级。

对消息队列有写权限的进程可以向中按照一定的规则添加新消息;对消息

队列有读权限的进程则可以从消息队列中读走消息。,我们的操作系统提

供了一个struct msg_ids结构体来记录消息队列的全局数据结构。

struct msqid_ds{

struct ipc_perm msg_perm;//被用来传递ipc操作权限信息

struct msg *msg_first; //指向消息队列第一个结点

struct msg *msg_last; //指向详细队列最后一个结点

……;

};

我们可以将内核中某个特定的消息队列画成一个消息链表。如下图所示,假如一个具有三个消息的队列。长度分别为1byte,2byte和3byte,消息类型(type)为100,200,300.为那么这些消息的排序如下图。

OK,了解了之后,我们来回顾一下,我们以下学习的IPC通信,都是通过一个key值来标识一个ID,那么消息队列的可key值保存在哪里呢?我们来看看我们的

Ipc_perm结构。

二.常用操作

<1>创建消息队列msgget()

<2>发送消息队列msgnd(),我们按照一定的类型发送即可。

<3>接收消息队列的信息msgrcv()

<4>删除消息队列msgctl()

1)创建消息队列

int msgget(key_t key ,int msgflag);

功能:创建消息队列信息。得到其ID

参数:

@key IPC_PRIVATE 或者ftok()

@msgflg

IPC_CREAT | 0666 对应的消息队列不存在,则创建, 存在直接返回ID 或IPC_CREAT | IPC_EXEL | 0666 对应的消息队列段存在则调用失败。

否则,创建新的消息队列段。

返回值:成功返回显示消息队列的ID,失败返回-1

2)发送消息

int msgsnd(int msqid, const void *msgp, size_t msgsz, int msgflg);

功能:向消息队列中添加消息

参数:

msqid 消息队列的ID

msgp 消息存放的地址

msgsz 消息正文的大小--- sizeof(msg_t) - sizeof(long)

msgflg

0:阻塞的方式发送消息

IPC_NOWAIT:非阻塞发送消息(当消息队列中没有可用空间时,不阻塞,立即返回一个错误码EAGAIN)

返回值:

成功返回0,失败返回-1

注意:msgp在系统内部一个指定了一个消息的模板。用于我们发送和接收消息

struct msgbuf{

long mtype; //消息的类型

char mtext[1]; //消息的正文。

};

但是,大家可以看到,我们的上面的模板中的消息一般不止一个字节。所以我们一般

自定义封装的结构体如下。

typedef struct{

long type ; //第一个字段必须是消息的类型

//消息的正文[自己设定],例如

char msgbuf[1024];

}msg_t;

//消息正文的大小[除掉消息类型之后的大小]

#define MSG_LEN (sizeof(msg_t) – sizeof(long))

翻译如下:

那个msgsnd()和msgecv()函数被调用,分别用于从一个消息队列中发送消息和接收消息。那个调用

进程若是要发送消息,必须要有写权限,若是接收消息,必须要有读权限。

那个msgp 是一个访问结构体的指针,我们提供了下列的模板

struct msgbuf{

long mtype; //消息的类型

char mtext[1]; //消息的正文

};

我们的mtext是一个数组[或者说一个结构],它的大小由我们的msgsz这个参数指定,它是一个正整数值。

消息的长度也可以为0。那个mtype参数表示了一个消息的类型,它必须被指定为一个正整数。它可以

被用来接收消息选择的过程。

例如:

typedef struct

{

long type; //消息类型

char buf[1024] ;//正文的消息

}msg_t;

#define MSGLEN (sizeof(msg_t) – sizeof(long)) //正文消息长度

msg_t msg;

msg_t *pmsg = (msg_t *)malloc(sizeof(msg_t));

msg.type = 100;

strcpy(msg.buf,”hello”);

msgsnd(msgid,&msg,MSGLEN);

3)接收消息

ssize_t msgrcv(int msqid, void *msgp, size_t msgsz, long msgtyp,int msgflg);

功能:接收指定类型的消息

参数:

msgid 消息队列ID

msgp 接收的消息存放的地址

msgsz 消息正文的大小

msgtyp 接收的消息的类型

msgflg 0(阻塞方式调用) 或IPC_NOWAIT (没有指定类型消息,不阻塞,立即返回) 返回值:

成功返回接收正文的大小,失败返回-1

例如:

接收消息类型为100的消息

msg_t msg;

if(msgrcv(msgid,&msg,MSG_LEN,100,0) < 0)

{

.....

}

printf("------------------------------\n");

printf("TYPE : %ld.\n",msg.type);

printf("MTXT : %s.\n",msg.buf);

printf("------------------------------\n");

4)删除消息队列

int msgctl(int msqid, int cmd, struct msqid_ds *buf); 功能:对消息队列进行控制

参数:

@msgid消息队列的id

@cmd消息队列控制命令

IPC_RMID 删除共享内存。

@buf 填充当前进程的信息到msqid_ds 结构体中。

一般我们置为NULL,不适用。

例:msgctl(msqid,IPC_RMID,NULL); 详见man手册

实例代码:

msg_read.c

msg_write.c

运行结果:

练习:

通过消息队列让A终端上父子进程和B终端父进程了解,要求一边输入quit,所有进程退出。[A和B终端都可以接收和发送消息]

Linux进程间通信(2)实验报告

实验六:Linux进程间通信(2)(4课时) 实验目的: 理解进程通信原理;掌握进程中信号量、共享内存、消息队列相关的函数的使用。实验原理: Linux下进程通信相关函数除上次实验所用的几个还有: 信号量 信号量又称为信号灯,它是用来协调不同进程间的数据对象的,而最主要的应用是前一节的共享内存方式的进程间通信。要调用的第一个函数是semget,用以获得一个信号量ID。 int semget(key_t key, int nsems, int flag); key是IPC结构的关键字,flag将来决定是创建新的信号量集合,还是引用一个现有的信号量集合。nsems是该集合中的信号量数。如果是创建新集合(一般在服务器中),则必须指定nsems;如果是引用一个现有的信号量集合(一般在客户机中)则将nsems指定为0。 semctl函数用来对信号量进行操作。 int semctl(int semid, int semnum, int cmd, union semun arg); 不同的操作是通过cmd参数来实现的,在头文件sem.h中定义了7种不同的操作,实际编程时可以参照使用。 semop函数自动执行信号量集合上的操作数组。 int semop(int semid, struct sembuf semoparray[], size_t nops); semoparray是一个指针,它指向一个信号量操作数组。nops规定该数组中操作的数量。 ftok原型如下: key_t ftok( char * fname, int id ) fname就是指定的文件名(该文件必须是存在而且可以访问的),id是子序号,虽然为int,但是只有8个比特被使用(0-255)。 当成功执行的时候,一个key_t值将会被返回,否则-1 被返回。 共享内存 共享内存是运行在同一台机器上的进程间通信最快的方式,因为数据不需要在不同的进程间复制。通常由一个进程创建一块共享内存区,其余进程对这块内存区进行读写。首先要用的函数是shmget,它获得一个共享存储标识符。 #include #include #include int shmget(key_t key, int size, int flag); 当共享内存创建后,其余进程可以调用shmat()将其连接到自身的地址空间中。 void *shmat(int shmid, void *addr, int flag); shmid为shmget函数返回的共享存储标识符,addr和flag参数决定了以什么方式来确定连接的地址,函数的返回值即是该进程数据段所连接的实际地

进程的消息通信-带标准答案版

实验二进程管理 2.2 进程的消息通信 1.实验目的 (1) 加深对进程通信的理解,理解进程消息传递机制。 (2) 掌握进程通信相关系统调用。 (3) 理解系统调用和用户命令的区别。 2.实验类型:验证型 3.实验学时:2 4.实验原理和知识点 (1) 实验原理:消息通信机制允许进程之间大批量交换数据。消息通信机制是以消息队列为基础的,消息队列是消息的链表。发送进程将消息挂入接收进程的消息队列,接收进程从消息队列中接收消息。消息队列有一个消息描述符。对消息队列的操作是通过描述符进行的。任何进程,只要有访问权并且知道描述符,就可以访问消息队列。每个消息包括一个正长整型的类型字段,和一个非负长度的数据。进程读或写消息时,要给出消息的类型。若队列中使用的消息类型为0,则读取队列中的第一个消息。 (2) 知识点:消息、消息队列 5.实验环境(硬件环境、软件环境): (1)硬件环境:Intel Pentium III 以上CPU,128MB以上内存,2GB以上硬盘 (2)软件环境:linux操作系统。 6. 预备知识 (1) msgget()系统调用: 头文件 #include 函数原型int msgget(key_t key, int flag); 功能:创建消息队列,或返回与key对应的队列描述符。成功返回消息描述符,失败则返回-1。 参数:key是通信双方约定的队列关键字,为长整型数。flag是访问控制命令,它的低9位为访问权限(代表用户、组用户、其他用户的读、写、执行访问权),其它位为队列建立方式。(例:rwxrwx---:111111000) (2) msgsnd()系统调用: 头文件 #include 函数原型 int msgsnd(int id, struct msgbuf *msgp,int size,int flag); 功能:发送一个消息。成功返回0,失败返回-1。 参数:id是队列描述符。msgp是用户定义的缓冲区。size是消息长度。flag是操作行为,若(flag&IPC_NOWAIT)为真,调用进程立即返回;若(flag&IPC_NOWAIT)为假,调用进程阻塞,直到消息被发送出去或队列描述符被删除或收到中断信号为止。缓冲区结构定义如下:struct msgbuf{ long mtype; char mtext[n]; };

RabbitMQ的应用场景以及基本原理介绍

RabbitMQ的应用场景以及基本原理介绍 1.背景 RabbitMQ是一个由erlang开发的AMQP(Advanved Message Queue)的开源实现。 2.应用场景 2.1异步处理 场景说明:用户注册后,需要发注册邮件和注册短信,传统的做法有两种1.串行的方式;2.并行的方式 (1)串行方式:将注册信息写入数据库后,发送注册邮件,再发送注册短信,以上三个任务全部完成后才返回给客户端。这有一个问题是,邮件,短信并不是必须的,它只是一个通知,而这种做法让客户端等待没有必要等待的东西. (2)并行方式:将注册信息写入数据库后,发送邮件的同时,发送短信,以上三个任务完成后,返回给客户端,并行的方式能提高处理的时间。

假设三个业务节点分别使用50ms,串行方式使用时间 150ms,并行使用时间100ms。虽然并性已经提高的处理时间,但是,前面说过,邮件和短信对我正常的使用网站没有任何影响,客户端没有必要等着其发送完成才显示注册成功,英爱是写入数据库后就返回. (3)消息队列 引入消息队列后,把发送邮件,短信不是必须的业务逻辑异步处理 由此可以看出,引入消息队列后,用户的响应时间就等于写入数据库的时间+写入消息队列的时间(可以忽略不计),引入消息队列后处理后,响应时间是串行的3倍,是并行的2倍。2.2 应用解耦 场景:双11是购物狂节,用户下单后,订单系统需要通知库存系统,传统的做法就是订单系统调用库存系统的接口.

这种做法有一个缺点: 当库存系统出现故障时,订单就会失败。(这样马云将少赚好多好多钱^ ^)订单系统和库存系统高耦合. 引入消息队列 订单系统:用户下单后,订单系统完成持久化处理,将消息写入消息队列,返回用户订单下单成功。库存系统:订阅下单的消息,获取下单消息,进行库操作。 就算库存系统出现故障,消息队列也能保证消息的可靠投递,不会导致消息丢失(马云这下高兴了). 流量削峰 流量削峰一般在秒杀活动中应用广泛 场景:秒杀活动,一般会因为流量过大,导致应用挂掉,为了解决这个问题,一般在应用前端加入消息队列。 作用: 1.可以控制活动人数,超过此一定阀值的订单直接丢弃(我为

Linux系统编程实验六进程间通信

实验六:进程间通信 实验目的: 学会进程间通信方式:无名管道,有名管道,信号,消息队列, 实验要求: (一)在父进程中创建一无名管道,并创建子进程来读该管道,父进程来写该管道(二)在进程中为SIGBUS注册处理函数,并向该进程发送SIGBUS信号(三)创建一消息队列,实现向队列中存放数据和读取数据 实验器材: 软件:安装了Linux的vmware虚拟机 硬件:PC机一台 实验步骤: (一)无名管道的使用 1、编写实验代码pipe_rw.c #include #include #include #include #include #include int main() { int pipe_fd[2];//管道返回读写文件描述符 pid_t pid; char buf_r[100]; char* p_wbuf; int r_num; memset(buf_r,0,sizeof(buf_r));//将buf_r初始化 char str1[]=”parent write1 “holle””; char str2[]=”parent write2 “pipe”\n”; r_num=30; /*创建管道*/ if(pipe(pipe_fd)<0) { printf("pipe create error\n"); return -1; } /*创建子进程*/ if((pid=fork())==0) //子进程执行代码 {

//1、子进程先关闭了管道的写端 close(pipe_fd[1]); //2、让父进程先运行,这样父进程先写子进程才有内容读sleep(2); //3、读取管道的读端,并输出数据 if(read(pipe_fd[0],buf_r, r_num)<0) { printf(“read error!”); exit(-1); } printf(“%s\n”,buf_r); //4、关闭管道的读端,并退出 close(pipe_fd[1]); } else if(pid>0) //父进程执行代码 { //1、父进程先关闭了管道的读端 close(pipe_fd[0]); //2、向管道写入字符串数据 p_wbuf=&str1; write(pipe_fd[1],p_wbuf,sizof(p_wbuf)); p_wbuf=&str2; write(pipe_fd[1],p_wbuf,sizof(p_wbuf)); //3、关闭写端,并等待子进程结束后退出 close(pipe_fd[1]); } return 0; } /*********************** #include #include #include #include #include #include int main() { int pipe_fd[2];//管道返回读写文件描述符 pid_t pid; char buf_r[100]; char* p_wbuf; int r_num;

IBM MQ 概述

IBM MQ 介绍 消息队列(MQ)是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入列队的针对应用程序的数据(消息)来通信,而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信,而不是通过直接调用彼此来通信,直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。 IBM WebSphere MQ 产品支持应用程序通过不同组件如处理器、子系统、操作系统以及通信协议的网络彼此进行通信。例如,IBM WebSphere MQ 支持35 种以上的不同操作系统。 IBM WebSphere MQ 支持两种不同的应用程序编程接口:Java 消息服务(JMS)和消息队列接口(MQI)。在IBM WebSphere MQ 服务器上,JMS 绑定方式被映射到MQI。如图 3 所示,应用程序直接与其本地队列管理器通过使用MQI 进行对话,MQI 是一组要求队列管理器提供服务的调用。MQI 的引人之处是它只提供13 次调用。这意味着对于应用程序编程员它是一种非常易于使用的接口,因为大部分艰苦工作都将透明完成的。 图形 2. IBM WebSphere MQ 编程 图2 显示了IBM WebSphere MQ 编程的原理。第一步是让应用程序与队列管理器连接。它通过MQConnect 调用来进行此连接。下一步使用MQOpen 调用为输出打开一个队列。然后应用程序使用MQPut 调用将其数据放到队列上。要接收数据,应用程序调用MQOpen 调用打开输入队列。应用程序使用MQGet 调用从队列上接收数据。

linux进程间通讯的几种方式的特点和优缺点

1. # 管道( pipe ):管道是一种半双工的通信方式,数据只能单向流动,而且只能在具有亲缘关系的进程间使用。进程的亲缘关系通常是指父子进程关系。 # 有名管道(named pipe) :有名管道也是半双工的通信方式,但是它允许无亲缘关系进程间的通信。 # 信号量( semophore ) :信号量是一个计数器,可以用来控制多个进程对共享资源的访问。它常作为一种锁机制,防止某进程正在访问共享资源时,其他进程也访问该资源。因此,主要作为进程间以及同一进程内不同线程之间的同步手段。 # 消息队列( message queue ) :消息队列是由消息的链表,存放在内核中并由消息队列标识符标识。消息队列克服了信号传递信息少、管道只能承载无格式字节流以及缓冲区大小受限等缺点。 # 信号( sinal ) :信号是一种比较复杂的通信方式,用于通知接收进程某个事件已经发生。#共享内存( shared memory):共享内存就是映射一段能被其他进程所访问的内存,这段共享内存由一个进程创建,但多个进程都可以访问。共享内存是最快的IPC方式,它是针对其他进程间通信方式运行效率低而专门设计的。它往往与其他通信机制,如信号量,配合使用,来实现进程间的同步和通信。 # 套接字( socket ) :套解口也是一种进程间通信机制,与其他通信机制不同的是,它可用于不同及其间的进程通信。 管道的主要局限性正体现在它的特点上: 只支持单向数据流; 只能用于具有亲缘关系的进程之间; 没有名字; 管道的缓冲区是有限的(管道制存在于内存中,在管道创建时,为缓冲区分配一个页面大小);管道所传送的是无格式字节流,这就要求管道的读出方和写入方必须事先约定好数据的格式,比如多少字节算作一个消息(或命令、或记录)等等; 2. 用于进程间通讯(IPC)的四种不同技术: 1. 消息传递(管道,FIFO,posix和system v消息队列) 2. 同步(互斥锁,条件变量,读写锁,文件和记录锁,Posix和System V信号灯) 3. 共享内存区(匿名共享内存区,有名Posix共享内存区,有名System V共享内存区) 4. 过程调用(Solaris门,Sun RPC) 消息队列和过程调用往往单独使用,也就是说它们通常提供了自己的同步机制.相反,共享内存区

OSAL中的消息机制

OSAL中的消息机制 学习了zstack的整体框架后,会发现,每个zstack的工程中都有若干个任务,每个任务对应着任务事件,如: macEventLoop, nwk_event_loop, Hal_ProcessEvent, APS_event_loop, ZDApp_event_loop, SerialApp_ProcessEvent 通常最后一个是我们自定义的应用层任务事件(我用串口例子上手,在此以它为例) 为了方便搞懂,可以暂时这么理解: 把每个任务看成是一个小区中的某户人家,比如上例中一个小区7户,每户一个邮箱,那么小区就有7个任务,7个邮箱构成事件数组。 消息是包裹,SYS_EVENT_MSG事件(邮箱里收到的除了这种类型的事件,还有一些其他的,比如自定义的SERIALAPP_SEND_EVT SERIALAPP_RESP_EVT 等)就是包裹通知单,包裹通知单送达某户的邮箱(SYS_EVENT_MSG消息被发送到某个任务事件处理函数),这户人家查看邮箱,发现有包裹通知单,就去领出包裹(即执行osal_msg_receive( TaskID )函数),领出包裹后拆开其实就是解析消息后再决定是吃掉它,用掉它,回覆它还是丢掉它等等。 在学习的过程中, 如果有进入过这个函数: osal_msg_send( uint8 destination_task, uint8 *msg_ptr ),你会发现函数里有一下几句执行语句OSAL_MSG_NEXT(msg_ptr)、OSAL_MSG_ID( msg_ptr ),跟踪进去后,发现他们是个宏定义,如#define OSAL_MSG_ID( msg_ptr ) ((osal_msg_hdr_t *) (msg_ptr) - 1)->dest_id 意思是把msg_ptr强制转化为osal_msg_hdr_t的指针,但是,发现有个-1,我也是因为看到这个奇怪的-1才最终总结了这个消息机制。 先看一下OSAL消息结构:消息头结构+消息数据结构(Key)

实验6 进程及进程间的通信之共享内存

实验6 进程及进程间的通信 ●实验目的: 1、理解进程的概念 2、掌握进程复制函数fork的用法 3、掌握替换进程映像exec函数族 4、掌握进程间的通信机制,包括:有名管道、无名管道、信 号、共享内存、信号量和消息队列 ●实验要求: 熟练使用该节所介绍fork函数、exec函数族、以及进程间通信的相关函数。 ●实验器材: 软件: 1.安装了Ubunt的vmware虚拟机 硬件:PC机一台 ●实验步骤: 1、用进程相关API 函数编程一个程序,使之产生一个进程 扇:父进程产生一系列子进程,每个子进程打印自己的PID 然后退出。要求父进程最后打印PID。 进程扇process_fan.c参考代码如下:

2、用进程相关API 函数编写一个程序,使之产生一个进程 链:父进程派生一个子进程后,然后打印出自己的PID,然后退出,该子进程继续派生子进程,然后打印PID,然后退出,以此类推。

要求:1) 实现一个父进程要比子进程先打印PID 的版本。(即 打印的PID 一般是递增的) 2 )实现一个子进程要比父进程先打印PID 的版本。(即打印的PID 一般是递减的) 进程链1,process_chain1.c的参考代码如下:

进程链2,process_chain2.c的参考代码如下:

3、编写程序execl.c,实现父进程打印自己的pid号,子进程调用 execl函数,用可执行程序file_creat替换本进程。注意命令行参数。 参考代码如下: /*execl.c*/ #include #include #include

进程间通信实验报告

进程间通信实验报告 班级:10网工三班学生姓名:谢昊天学号:1215134046 实验目的和要求: Linux系统的进程通信机构 (IPC) 允许在任意进程间大批量地交换数据。本实验的目的是了解和熟悉Linux支持的消息通讯机制及信息量机制。 实验内容与分析设计: (1)消息的创建,发送和接收。 ①使用系统调用msgget (), msgsnd (), msgrev (), 及msgctl () 编制一长度为1k 的消息的发送和接收程序。 ②观察上面的程序,说明控制消息队列系统调用msgctl () 在此起什么作用? (2)共享存储区的创建、附接和段接。 使用系统调用shmget(),shmat(),sgmdt(),shmctl(),编制一个与上述功能相同的程序。(3)比较上述(1),(2)两种消息通信机制中数据传输的时间。 实验步骤与调试过程: 1.消息的创建,发送和接收: (1)先后通过fork( )两个子进程,SERVER和CLIENT进行通信。 (2)在SERVER端建立一个Key为75的消息队列,等待其他进程发来的消息。当遇到类型为1的消息,则作为结束信号,取消该队列,并退出SERVER 。SERVER每接收到一个消息后显示一句“(server)received”。 (3)CLIENT端使用Key为75的消息队列,先后发送类型从10到1的消息,然后退出。最后的一个消息,既是 SERVER端需要的结束信号。CLIENT每发送一条消息后显示一句“(client)sent”。 (4)父进程在 SERVER和 CLIENT均退出后结束。 2.共享存储区的创建,附接和断接: (1)先后通过fork( )两个子进程,SERVER和CLIENT进行通信。 (2)SERVER端建立一个KEY为75的共享区,并将第一个字节置为-1。作为数据空的标志.等待其他进程发来的消息.当该字节的值发生变化时,表示收到了该消息,进行处理.然后再次把它的值设为-1.如果遇到的值为0,则视为结束信号,取消该队列,并退出SERVER.SERVER 每接收到一次数据后显示”(server)received”. (3)CLIENT端建立一个为75的共享区,当共享取得第一个字节为-1时, Server端空闲,可发送请求. CLIENT 随即填入9到0.期间等待Server端再次空闲.进行完这些操作后, CLIENT退出. CLIENT每发送一次数据后显示”(client)sent”. (4)父进程在SERVER和CLIENT均退出后结束。 实验结果: 1.消息的创建,发送和接收: 由 Client 发送两条消息,然后Server接收一条消息。此后Client Server交替发送和接收消息。最后一次接收两条消息。Client 和Server 分别发送和接收了10条消息。message 的传送和控制并不保证完全同步,当一个程序不再激活状态的时候,它完全可能继续睡眠,造成上面现象。在多次send message 后才 receive message.这一点有助于理解消息转送的实现机理。

IEC 通讯机制

RTU上行通信IEC104协议简述

目录 1.RTU IEC104协议基本参数 (1) 2.应用规约控制单元(APDU)格式 (1) 2.1应用规约控制信息(APCI)格式 (1) 2.2应用服务数据单元(ASDU)格式 (3) 3.定时器定义 (7) 4.未被确认的I帧最大数目k和最迟确认数目W (7) 5.总召唤机制 (7) 6.电度总召唤机制 (8) 7.时钟同步机制 (8) 8.遥控机制 (8) 8.1正常遥控 (8) 8.2从站拒绝 (9) 8.3主站撤销 (9) 9.遥调机制 (9) 9.1正常遥调 (9) 9.2从站拒绝 (10) 9.3主站撤销 (10) 10.非标召唤机制 (10) 11.变位遥信机制 (11) 12.历史数据召唤机制 (11) 12.1RTU没有历史数据 (12) 13.地址分配 (12)

1.RTU IEC104协议基本参数 ●基于IEC60870-5-104协议; ●最大帧长度为255Byte; ●帧间隔:50ms; ●TCP/IP 网络通信端口号2404; ●采用平衡传输,每个节点(包括主站、厂站)均可以启动报文发送。 2.应用规约控制单元(APDU)格式 ●应用规约数据单元:APDU(Application protocol data unit) ●应用规约控制信息:APCI(Application protocol control information) ●应用服务数据单元:ASDU(Application protocol control unit) 2.1应用规约控制信息(APCI)格式 为了检出ASDU的启动和结束,每个APCI包括下列的定界元素:一个启动字符,ASDU 的规定长度,以及控制域(见下图)。可以传送一个完整的APDU(或者,出于控制目的,仅仅是传送APCI域)。

MQ介绍与选型

MQ介绍与选型 MQ使用场景 ?异步通信 有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制,允许用户把一个消息放入队列,但并不立即处理它。想向队列中放入多少消息就放多少,然后在需要的时候再去处理它们。 ?解耦 降低工程间的强依赖程度,针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求,是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层,两边的处理过程都要实现这一接口,当应用发生变化时,可以独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束。 ?冗余 有些情况下,处理数据的过程会失败。除非数据被持久化,否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中,在把一个消息从队列中删除之前,需要你的处理系统明确的指出该消息已经被处理完毕,从而确保你的数据被安全的保存直到你使用完毕。 ?扩展性 因为消息队列解耦了你的处理过程,所以增大消息入队和处理的频率是很容易的,只要另外增加处理过程即可。不需要改变代码、不需要调节参数。便于分布式扩容。 ?过载保护

在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量无法提取预知;如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力,而不会因为突发的超负荷的请求而完全崩溃。 ?可恢复性 系统的一部分组件失效时,不会影响到整个系统。消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理。 ?顺序保证 在大多使用场景下,数据处理的顺序都很重要。大部分消息队列本来就是排序的,并且能保证数据会按照特定的顺序来处理。 ?缓冲 在任何重要的系统中,都会有需要不同的处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行,该缓冲有助于控制和优化数据流经过系统的速度。 以调节系统响应时间。 ?数据流处理 分布式系统产生的海量数据流,如:业务日志、监控数据、用户行为等,针对这些数据流进行实时或批量采集汇总,然后进行大数据分析是当前互联网的必备技术,通过消息队列完成此类数据收集是最好的选择。

实验三 进程间通信

实验三进程间通信(2学时) 一、实验目的 (1)了解什么是信号。 (2)熟悉LINUX系统中进程之间软中断通信的基本原理。 (3)熟悉LINUX支持的管道通信方式。 二、实验内容 (1)编写一段程序,使其现实进程的软中断通信。 即:使用系统调用fork()创建两个子进程,再用系统调用signal()让父进程捕捉键盘上来的中断信号(即按 ctrl+c 键);当捕捉到中断信号后,父进程用系统调用kill( )向两个子进程发出信号,子进程捕捉到信号后,分别输出下列信息后终止: Child Process11 is killed by Parent! Child Process12 is killed by Parent! 父进程等待两个子进程终止后,输出如下的信息后终止 Parent Process is killed! 要求:运行以下参考程序并分析结果。 <参考程序> #include #include #include #include void waiting(),stop(),alarming(); int wait_mark; main() { int p1,p2; if(p1=fork()) /*创建子进程p1*/ { if(p2=fork()) /*创建子进程p2*/ { //父进程 wait_mark=1; signal(SIGINT,stop); /*接收到^c信号,转stop*/

signal(SIGALRM,alarming);/*接受SIGALRM*/ waiting(); kill(p1,16); /*向p1发软中断信号16*/ kill(p2,17); /*向p2发软中断信号17*/ wait(0); /*同步*/ wait(0); printf("parent process is killed!\n"); exit(0); //会暂时停止目前进程的执行,直到有信号来到或子进程结束。 } else { wait_mark=1; signal(17,stop); signal(SIGINT,SIG_IGN); /*忽略 ^c信号*/ while (wait_mark!=0); lockf(1,1,0); printf("child process2 is killed by parent!\n"); lockf(1,0,0); exit(0); } } else { wait_mark=1; signal(16,stop); signal(SIGINT,SIG_IGN); /*忽略^c信号*/ while (wait_mark!=0); lockf(1,1,0); printf("child process1 is killed by parent!\n"); lockf(1,0,0); exit(0); } } void waiting() { sleep(5); if (wait_mark!=0) kill(getpid(),SIGALRM); } void alarming()

进程同步实验报告

实验三进程的同步 一、实验目的 1、了解进程同步和互斥的概念及实现方法; 2、更深一步的了解fork()的系统调用方式。 二、实验内容 1、预习操作系统进程同步的概念及实现方法。 2、编写一段源程序,用系统调用fork()创建两个子进程,当此程序运行时,在系统中有一个父进程和两个子进程活动。让每一个进程在屏幕上显示一个字符:父进程显示字符“a”;子进程分别显示字符“b”和字符“c”。程序的输出是什么?分析原因。 3、阅读模拟火车站售票系统和实现进程的管道通信源代码,查阅有关进程创建、进程互斥、进程同步的系统功能调用或API,简要解释例程中用到的系统功能或API的用法,并编辑、编译、运行程序,记录程序的运行结果,尝试给出合理的解释。 4、(选做)修改问题2的代码,使得父子按顺序显示字符“a”;“b”、“c”编辑、编译、运行。记录程序运行结果。 三、设计思想 1、程序框架 (1)创建两个子进程:(2)售票系统:

(3)管道通信: 先创建子进程,然后对内容加锁,将输出语句存入缓存,并让子进程自己进入睡眠,等待别的进程将其唤醒,最后解锁;第二个子进程也执行这样的过程。父进程等待子进程后读内容并输出。 (4)修改程序(1):在子进程的输出语句前加上sleep()语句,即等待父进程执行完以后再输出。 2、用到的文件系统调用函数 (1)创建两个子进程:fork() (2)售票系统:DWORD WINAPI Fun1Proc(LPVOID lpPartameter); CreateThread(NULL,0,Fun1Proc,NULL,0,NULL); CloseHandle(hThread1); (HANDLE)CreateMutex(NULL,FALSE,NULL); Sleep(4000)(sleep调用进程进入睡眠状态(封锁), 直到被唤醒); WaitForSingleObject(hMutex,INFINITE); ReleaseMutex(hMutex); (3)管道通信:pipe(fd),fd: int fd[2],其中: fd[0] 、fd[1]文件描述符(读、写); lockf( fd,function,byte)(fd: 文件描述符;function: 1: 锁定 0:解锁;byte: 锁定的字节数,0: 从当前位置到文件尾); write(fd,buf,byte)、read(fd,buf,byte) (fd: 文件描述符;buf : 信息传送的源(目标)地址;byte: 传送的字节数); sleep(5); exit(0); read(fd[0],s,50) (4)修改程序(1):fork(); sleep(); 四、调试过程 1、测试数据设计 (1)创建两个子进程:

特别重大灾害应急通信响应机制

**市特别重大灾害应急通信响应机制(稿) 为做好特别重大灾害期间应急通信保障工作,依据应急管理部《特别重大灾害应急响应工作手册》,制定本文件。 一、应急响应 灾害发生后,**市消防救援支队指挥中心(以下简称“消防指挥中心”)汇总相关信息,根据事故灾害态势,通报有关地区和部门,通知**市消防应急通信保障分队(以下简称“应急通信保障分队”)启动特别重大灾害应急通信响应,调动属地或跨区域增援应急通信保障队启动应急响应。 (一)应急通信保障分队 应急通信保障分队以**市消防救援支队信息通信保障力量为主体,安全生产应急救援指挥中心、市通信信息中心、抗震救灾、森林防火、市防汛抗旱等部门通信保障人员共同参加,负责**市在重大灾害响应及处置过程中的应急通信保障工作,内设后方通信保障组、前方通信保障组。 1.后方通信保障组 后方通信保障组负责消防指挥中心的通信值守、通信力量调度与协调工作,主要任务: (1)启动消防指挥中心各类应急通信指挥系统,进行席位值守,并保障各通信网络畅通,根据灾害类型,通知安全生产、抗

震救灾、森林防火等相应救灾部门的人员到消防指挥中心协调通信保障。 (2)根据灾害类型调派属地消防、安全生产、地震、森林防火等部门的应急通信保障队伍赶赴灾害现场,明确出动人员、装备器材、通信车辆等数量、类型要求。 (3)根据灾害范围和通信保障需求,跨区域调派增援通信保障力量,视情调集消防、安全生产、抗震救灾、森林防火等部门的增援通信保障队伍。 (4)制定应急通信保障力量,由消防指挥中心协调**市应急响应交通保障组组织实施。 (5)建立并保持与各通信保障队伍和前方通信保障组、遂行地方领导同志的音视频通信联络。 (6)保障消防指挥中心与自然资源、生态环境、气象等部门的音视频通信畅通。 (7)保障消防指挥中心与**市各应急响应保障组及部内设机构和主要防灾救灾部门的通信联系。 (8)根据任务需要,调派应急通信保障分队的机动预备力量,为**市各应急响应保障组提供应急通信保障装备或通信人员保障。 2.前方通信保障组 前方通信保障组主要负责赴灾害现场统筹协调应急通信保障工作,应急响应阶段的任务为: (1)联系**市应急响应交通保障组确认出动交通方式。 (2)了解灾情及灾区通信保障需求,准备通信车辆或装备器

zeromq的工作原理及使用

zeromq的工作原理及使用

一、ZeroMQ使用 1.1ZeroMQ概述 ZeroMQ是一种基于消息队列的多线程网络库,其对套接字类型、连接处理、帧、甚至路由的底层细节进行抽象,提供跨越多种传输协议的套接字。ZeroMQ是网络通信中新的一层,介于应用层和传输层之间(按照TCP/IP划分),其是一个可伸缩层,可并行运行,分散在分布式系统间。 ZeroMQ看起来想一个可嵌入的网络库,但其作用就像是一个并发框架。它为你提供了各种传输工具,如进程内,进程间,TCP和组播中进行原子消息传递的套接字。你可以使用各种模式实现N对N的套接字连接,这些模式包括发布订阅,请求应答,扇出模式,管道模式。它的速度足够快,因此可以充当集群产品的结构,他的异步IO模型提供了可扩展的多核应用程序,用异步消息来处理任务。它虽然是以C为源码进行开发,但是可以绑定多种语言。 1.2请求/应答模式 说到“请求-应答”模式,不得不说的就是它的消息流动模型以及数据包装模型。 消息流动模型指的是该模式下,必须严格遵守“一问一答”的方式。发出消息后,若没有收到回复,再发出第二条消息时就会抛出异常。同样的,对于Rep也是,在没有接收到消息前,不允许发出消息。基于此构成“一问一答”的响应模式。 1.2.1服务端 import time import zmq

context=zmq.Context() socket=context.socket(zmq.REP) socket.bind("tcp://*:5555") while True: #Wait for next request from client message=socket.recv() print("Received request:%s"%message) #Do some'work' time.sleep(1) #Send reply back to client socket.send(b"World") 1.2.2客户端 import zmq context=zmq.Context() #Socket to talk to server print("Connecting to hello world server…") socket=context.socket(zmq.REQ) socket.connect("tcp://localhost:5555") #Do10requests,waiting each time for a response for request in range(10): print("Sending request%s…"%request) socket.send(b"Hello") #Get the reply. message=socket.recv() print("Received reply%s[%s]"%(request,message))

操作系统进程创建及通信实验报告

武汉工程大学计算机科学与工程学院 《操作系统》实验报告[Ⅰ]

一、实验目的 创建进程,实现进程消息通信和共享内存通信,了解进程的创建、退出和获取进程信。了解什么是映像文件、管道通信及其作用,掌握通过内存映像文件和管道技术实现进程通信。 二、实验内容 本例用三种方法实现进程通信,仅用于示例目的,没有进行功能优化。 1、创建进程A和B后,在进程A中输入一些字符,点“利用 SendMessage发送消息”按钮可将消息发到进程B。 2、在进程A中输入一些字符,点“写数据到内存映像文件”按钮, 然后在进程B中点“从内存映像文件读数据”按钮可收到消息。其中在点“写数据到内存映像文件”时,要求创建映像文件,B进程在印象文件中读取数据。 3、先在进程B中点“创建管道并接收数据”按钮,然后在进程A 中输入一些字符,点“写数据到管道文件”按钮可将消息发到进程B。管道是连接读/写进程使他们进行通信的一个共享文件,目的是更好地实现进程间的通信。 三、实验思想 这次试验最主要的内容和核心思想就是学会创建进程并实现进程间的简单通信、创建映像文件和创建管道文件来通信,后两者是实现进程通信的高级通信机制中的两种。. 创建一个程序A和程序B,其中程序A和B各有一个主窗体,A主窗体上要求可以实现创建进程B(即调用函数B)、结束进程B、关闭进程A、向进程B发送数据、创建映像文件、创建管道文件等功能,进程B要求有从映像文件读取数据、创建管道并接收数据、结束进程B功能。最终让A、B进程相互通信。

四、设计分析: 首先设得设计A、B两个程序的操作界面,然后编写各个功能模块。对于A 程序窗体,在“利用SendMessage发送消息”按钮的消息响应函数中,主要是利用Windows API函数CWnd::FindWindow来找到接收消息的窗体,即进程B,找到进程B后,利用这个函数返回的窗体指针的SendMessage函数来发送消息。在“写数据到内存印象文件”按钮的消息响应函数中,主要是利用函数CreateFileMapping来创建一个印象文件,这个函数返回的是这个印象文件的句柄,然后将这个句柄和要发送的消息字符串传递到函数sprintf中,就可以所要发送的消息写入印象文件,在B程序窗体中有个“从内存印象文件读数据”按钮,在这个按钮的消息响应函数中读取父进程所创建的印象文件中的数据就可以实现通信了。在B程序窗体按钮“写数据到管道文件”的消息响应函数中,不能直接将要发送的消息发送到管道文件,因为管道必须先由子进程通过函数CreateNamedPipe创建,只有待子进程创建好管道后父进程才能根据管道创建管道文件,将消息写入管道文件并及时发送给子进程。而且这个管道只能使用一次,即每次发送完消息后那个管道不能在使用了,必须再由子进程创建一个管道,A 进程才能再次创建管道文件并向其中写入消息。这个程序也不一定要MFC实现,还可以用其他的技术和语言实现,比如说Java、VB等,外表构架可以不一样,但核心技术都是一样的,只是不同的调用形式和调用方法,比如说在VB中,实现进程间的一般通信就是使用动态数据交换DDE,实现起来就比较简单,但是要创建映像文件和管道文件就比较繁琐,可以根据不同的需求采用不同的语言。 五、程序部分源代码: 1.“利用SendMessage发送消息”按钮中的主要代码 //找到接收消息的窗口(窗口名为Receiver) CString str="进程B"; CWnd *pWnd=CWnd::FindWindow(NULL,str); if(pWnd) { COPYDATASTRUCT buf; char * s=new char[m_Msg1.GetLength()]; //m_Msg1为CString类型的变量 s=m_Msg1.GetBuffer(0);

快速实现ARM和DSP的通信和协同工作(精)

快速实现ARM和DSP的通信和协同工作 德州仪器(TI)的第一颗达芬奇(DaVinci)芯片(处理器)DM6446已经问世快三年了。继DM644x之后,TI又陆续推出了DM643x,DM35x,DM6467,OMAP353x等一系列ARM+DSP或ARM+视频协处理器的多媒体处理器平台。很多有很强DSP开发经验或ARM开发经验的工程师都转到达芬奇或通用OMAP (OMAP353x)平台上开发视频监控、视频会议及便携式多媒体终端等产品。大家都面临着同一个问题,那就是如何实现ARM和DSP或协处理器的通信和协同工作?TI的数字视频软件开发包(DVSDK)提供了Codec Engine这样一个软件模块来实现ARM和DSP或协处理器的协同工作。有很多工程师反馈这个软件模块非常好用,节省了很多开发时间,也有工程师认为TI提供的资料太多,不知如何快速上手。本文将从一个第一次接触Codec Engine的工程师角度出发,归纳TI提供的相关资源(文档,例程和网络资源)并介绍相关开发调试方法帮您快速入门Codec Engine。 1. Codec Engine概述 如图1所示,Codec Engine是连接ARM和DSP或协处理器的桥梁,是介于应用层(ARM侧的应用程序)和信号处理层(DSP侧的算法)之间的软件模块。ARM应用程序调用Codec Engine的VISA (Video, Image, Speech, Audio)API,如图1中VIDENC_process(a, b, c 。Codec Engine的stub (ARM侧)会把参数a, b, c以及要调用DSP侧process这个信息打包,通过消息队列(message queue)传递到DSP。Codec Engine的skeleton(DSP侧)会解开这个参数包,把参数a, b, c转换成DSP 侧对应的参数x, y, z(比如ARM侧传递的是虚拟地址,而DSP只能认物理地址),DSP侧的server(优先级较低,负责和ARM通信的任务)会根据process这一信息创建一个DSP侧的process(x, y, x任务最终实现VIDENC_process(a, b, c的操作。

相关文档
相关文档 最新文档