消息机制

4 QCRIL消息发送 当ril有请求过来时，就会调用ril库的onRequest()方法，此时就会根据当前Qcril注册的函数列表 进入到qcril_request_api的onRequest_rid方法中,因此, onRequest_rid方法是QCRIL中的入口 方法。调用的流程如如下, qcril_execute_event首先调用qcril_hash_table_lookup方法从表中查找当前的Event，如果没有 找到当前的Request，就认为非法，找到之后，进入qcril_dispatch_event()中派发该Event, (entry_ptr->handler)(params_ptr, &ret); ret是返回的结果,通过entry_ptr->handler调用当前Event的处理函数。这里的handler对应 qcril_hash_table中的某一项。第一章中将qcril_event_table表中的数据拷贝给了qcril_hash_table， 所以这里的handler可以理解为qcril_event_table中的某一项。 之后的流程就会进入到某个具体请求的处理函数中，比如打电话是对应的请求是RIL_REQUEST_DIAL， 其处理函数为：qcril_qmi_voice_request_dial;挂断电话对应的请求是RIL_REQUEST

2.QMUX QMI Multiplexing Protocol（QMUX）：QMI的复用协议 消息从控制点经过类似socket的线程传到QMI接口后，QMI负责对数据进行封装，加上QMUX消息的头，发送到QMUX层， 再通过QMUX层传到共享内存到BP侧。 2.1 QMUX消息的格式： 整个QMUX控制信道的结构如上图， I/FType：QMI将控制点数据封装后，发送到QMUX前，加的消息头，长度为一个byte，值通常为0x01，表示这个 消息为QMUX消息，如果是其他值，则为其他消息。 Length： QMUX消息的长度，不包括I/F Type。 ControlFlags:控制位，表示消息传输的方向。长度为1个byte，只有第7个bit是标志位，其他位为0，bit7=1说明 QMUX消息由服务端发送，bit7=0由控制点发送。 Clien ID: 控制点的标识，在控制点和服务端都需要赋值，当在服务端发出的消息Client ID的值为0xFF，表示该 消息为广播消息，由服务端主动发出，被所有控制点搜到。 QMUX SDU和TLV结构： 在整个控制信道的消息中，出去消息标识头I/F Type，和QMUX消息头，数据传输在QMUXSDU中完成，QMUX SDU里面的数据需要支持Type Length Value(TLV)的格式。 TLV格式的数据存放在QMI Service

5 底层消息发送 在linux_qmi_qmux_if_server.c文件的入口main（）函数，通过一个select来监听所有从 linux_qmi_client端发出的socket，通过for循环调用linux_qmi_qmux_if_server_process_client_msg（） 处理这些监听的消息。进入到函数linux_qmi_qmux_if_server_process_client_msg（）后， 通过recv函数将监听的socket的消息写入buf_size这个buffer里面。调用流程图如下, if ((buf_size = recv (fd, (void*)&platform_msg_hdr, QMI_QMUX_IF_PLATFORM_SPECIFIC_HDR_SIZE,0))<= 0) recv方法在接收socket时，并没有全部接收。而且只接收了platform_msg_hdr。这个platform_msg_hdr 是在linux_qmi_qmux_client里面定义的，server接收到后，首先会判断从client端发过来的这个消息是否正常， 包括client_id和消息长度。 remaining_bytes = (size_t) platform_msg_hdr.total_msg_size - QMI_QMUX_IF_PLATFORM

android QMI机制---概论 android QMI机制---QMUX android QMI机制---Qcril初始化流程 android QMI机制---QCRIL消息发送 android QMI机制---底层消息发送 android QMI机制---Modem消息接收 android QMI机制---modem消息发送 转载于:https://www.cnblogs.com/linhaostudy/p/8647242.html 来源： CSDN 作者： weixin_38169886 链接： https://blog.csdn.net/weixin_38169886/article/details/99628579

7 modem消息发送 一般BP侧处理完请求后，都会回应一个响应给AP，一般是用宏QMI_SVC_PKT_PUSH将要作为响应 的消息发送出去。qmi_svc_utils.h中QMI_SVC_PKT_PUSH定义如下, #define QMI_SVC_PKT_PUSH(pkt,val,len) ( len == dsm_pushdown_packed(pkt,\ val,\ len,\ DSM_DS_SMALL_ITEM_POOL ) ) 将val里面的数据，传len个长度到pkt的buffer里面，然后发送出去。Val和len是我们要作为响应的数据 和数据包大小。QMI_SVC_PKT_PUSH（）只能传单一的参数，根据上文说明的QMUX消息中TLV格式 的原理，可以用多个QMI_SVC_PKT_PUSH连着用，这样可以将多个数据或参数打包到同一条消息中发送。 例如,在voice服务中，用多个QMI_SVC_PKT_PUSH回传消息。 QMI_SVC_PKT_PUSH(&response, (void*)&info->call_id, sizeof(info->call_id))) ) ••• QMI_SVC_PKT_PUSH(&response, (void *)&tag, VOICEI_TLV_TAG_SIZE) ••• 最后还要记得写上TLV的总长度，和标志位

RabbitMQ消息可靠性和插件机制 RabbitMQ消息可靠性 RabbitMQ插件机制 RabbitMQ消息可靠性 RabbitMQ插件机制 来源： https://blog.csdn.net/weixin_45489092/article/details/100853929

一、RabbitMQ消息确认机制 RabbitMQ的消息确认有两种： 1、对生产端发送消息的确认。这种是用来确认生产者将消息发送给交换器，交换器传递给队列的过程中，消息是否成功投递。发送确认分为两步，一是确认是否到达交换器，二是确认是否到达队列。 2、对消费端消费消息的确认。这种是确认消费者是否成功消费了队列中的消息。 二、RabbitMQ对生产端发送消息的确认 rabbitmq对生产端发送消息的确认分为事务和实现confirm机制。不过一般不使用事务，性能消耗太大。对生产端的confirm机制参见： https://www.cnblogs.com/alan6/p/11483419.html 三、消费端消费消息后对RabbitMQ的确认 为了保证消息能可靠到达消费端，RabbitMQ也提供了消费端的消息确认机制。消费者在声明队列时，可以指定noAck参数，当noAck=false时，RabbitMQ会等待消费者显式发回ack信号后才从内存(和磁盘，如果是持久化消息的话)中移去消息。否则，RabbitMQ会在队列中消息被消费后立即删除它。 采用消息确认机制后，只要令noAck=false，消费者就有足够的时间处理消息(任务)，不用担心处理消息过程中消费者进程挂掉后消息丢失的问题，因为RabbitMQ会一直持有消息直到消费者显式调用basicAck为止。 消费端消息的确认分为：自动确认

linux各种IPC机制 　　docker中的资源隔离，一种就是IPC的隔离。IPC是进程间通信。 下面的文章转载自https://blog.csdn.net/yyq_9623/article/details/78794775 原帖发表在IBM的developerworks网站上，是一个系列的文章，作者郑彦兴，通过讲解和例子演示了Linux中几种IPC的使用方式，我觉得很好，在这里做一个保留，能看完的话Linux IPC的基础是没有问题的了。 一）Linux环境进程间通信（一）管道及有名管道 http://www.ibm.com/developerworks/cn/linux/l-ipc/part1/ 二）Linux环境进程间通信（二）: 信号 上： http://www.ibm.com/developerworks/cn/linux/l-ipc/part2/index1.html 下： http://www.ibm.com/developerworks/cn/linux/l-ipc/part2/index2.html 三）Linux环境进程间通信（三）消息队列 http://www.ibm.com/developerworks/cn/linux/l-ipc/part3/ 四）Linux环境进程间通信（四）信号灯 http://www.ibm.com/developerworks

windows操作系统最大的特殊是良好的用户交互性 消息机制：产生消息，传递消息并处理消息的过程 1.产生消息 不可控 1 typedef struct tagMSG 2 { 3 HWND hwnd;//窗口句柄 4 UINT message;//消息id 5 WPARAM wParam;//消息的辅助参数 6 LPARAM lParam;//消息的辅助参数 7 DWORD time;//消息产生的时间 8 POINT pt;//消息产生时鼠标的坐标 9 } MSG; 2.传递消息（分成两个部分，1、系统传递消息给应用程序 不可控；2.应用程序传递消息给应用程序 可控） windows操作系统为每一个正在运行的应用程序维护一个消息队列 3.消息处理 可控 吧消息当成条件 ，如何去拿到这个条件 主消息循环： GetMessage是从消息队列中得到消息 如果消息队列没有消息，消息堵塞 等待消息 如果的带了消息，要判断这个消息是否是WM_QUIT消息如果是返回false 如果不是 函数返回true 1 while (GetMessage(&msg, NULL, 0, 0))//从消息队列取消息，取出来放在第1个参数，最后两个参数表示消息的过滤，第3个参数表示的id到第4个参数表示的id这个区间表示的消息id才能被得到，给0，表示不过滤 2 { 3 if (

1.移动网络的发展--引子 20世纪80年代，商业性移动通信网络得到发展 第一代移动通信系统：TACS、NMT等模拟系统 第二代移动通信系统：GSM、IS-95、DECT、IS-136等数字系统，目前建设的2G移动网络使用两种主要技术，GSM网络使用TDMA技术，大约占70%，IS-95网络基于CDMA技术，大约占25%。 1992年开始对3G移动通信系统进行研究：R99、R4、R5、R6、R7、R8、R9…… 2G (GSM), 基于电路交换 2.5G (GPRS), 引入分组交换 3G时代的到来 1992年ETSI发起对即将到来的3G移动通信系统进行研究。采用2GHz附近的频率，支持多种空中接口： WCDMA——使用2GHz频谱的宽带码分多址接入 EDGE——用于GSM演进的增强数据传输速率 CDMA2000（1xRTT）——多载波SCDMA系统，用于在与IS-95相同的频带上建设CDMA网络 TD-SCDMA——由中国提出 支持分组数据业务，采用通用体系结构——UMTS（由3GPP负责制定），已有6个版本: 3GPP R99、R4、R5、R6、R7和R8 具体的： 3G (R99), 引入全新的UTRAN 3G (R4),电路域采用移动软交换 3G (R5), 引入IMS域 3G (R6),引入WLAN接入 3G (R7), 功能增强： CSI (Combination of