润小云解读鸿蒙OS系列(六):分布式软总线之discovery+COAP全流程
- 简介
Discovery 是一种基于coap 通信协议的设备发现机制;Coap(Constrained Application Protocol)是一种可以使用在资源受限的物联网设备上,并支持可靠传输的轻量化类web协议。它详细规范定义在 RFC 7252, coap 协议支持IP多播, 即可以同时向多个设备发送请求,鸿蒙OS的设备发现功能也是基于这个特性;用户使用discovery功能时,需要保证发现端设备与被发现端设备在同一个局域网内,并且都能收到对方coap协议报文;目前discovery服务仅支持基于Wi-Fi通信方式的设备发现机制。
- 代码分析
代码目录结构如下图:
Discovery 对外提供PublishService() 接口来实现设备的发现功能,其函数实现解读如下:
PublishService主要的代码流程图如下,由于篇幅有限我们本次不做详细的介绍。
被发现端主要是通过PublishService()这个函数发布服务。PublishService()函数的实现在discovery_service.c文件中,我们来看看这个函数的主流程代码;
函数参数三个:
moduleName:调用者的模块名称
info:PublishInfo结构体,发布的信息
cb:发布成功或者失败的回调函数
在函数实现中,我们可以看到权限检查,参数检验,信号量创建之类等代码;这里就不做介绍;我们从初始化服务 InitService()函数看,
InitCommonManager() 函数主要是调用InitLocalDeviceInfo()给g_deviceInfo结构体初始化;
RegisterWifiCallback(WifiEventTrigger)函数将WifiEventTrigger(unsigned int para)函数赋值给全局变量g_wifiCallback
最主要看CoapInit()函数
这里面我们优先分析下CoapInitSocket() 和 CreateCoapListenThread()
CoapInitSocket()函数实现如下:
可以看到CoapInitSocket()函数里面其实就是调用了socket()函数创建了socket,然后调用bind()绑定到指定的ip跟port,然后将socket描述符赋值给全局变量g_serverFd。以便后面GetCoapServerSocket()函数调用获取socket描述符。
CreateCoapListenThread() 创建线程接收消息,函数实现如下;
CoapReadHandle 接收并处理收到的消息
HandleReadEvent函数实现如下,我们分别看看CoapSocketRecv()、COAP_SoftBusDecode()、PostServiceDiscover()函数;
CoapSocketRecv()实现就是调用recvfrom()接收消息。
收到消息放到recvBuffer里面 然后调用COAP_SoftBusDecode()解码收到的消息。解码之后放到decodePacket里面然后调用PostServiceDiscover()函数对接收到的消息进行回应。
PostServiceDiscover()函数代码如下:
其中GetServiceDiscoverInfo(),这个函数可以获取到对端的ip 和remoteUrl。
这里可以获取到设备信息,也就是deviceInfo 结构体成员如下:
获取到这些信息之后我们就可以调用CoapResponseService()函数回复消息了。这里就看看主要的回复消息流程,其他的流程有兴趣可以自己继续钻研。
调用socket()创建socket 并将socket描述符返回跟全局变量g_clientFd,以便后面函数GetCoapClientSocket()获取socket描述符。
调用sendto发送消息。
此文档只是介绍了收发消息的主要流程,其他的细节这里并没有详细介绍。感兴趣的同学可以根据这个主流程继续钻研下其他的功能实现。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
云原生策略引擎 OPA 介绍
OPA(发音为 “oh-pa”)是一个全场景通用的轻量策略引擎(Policy Engine),OPA 提供了声明式表达的Rego语言来描述策略,并将策略的决策 offload 到 OPA,从而将策略的决策过程从策略的执行中解耦。OPA 可适用于多种场景,比如 Kubernetes、Terraform、Envoy 等等,简而言之,以前需要使用到 Policy 的场景理论上都可以用 OPA 来做一层抽象,如下所示: 在大多数场景下,Policy 即是一系列用来控制服务的规则(可理解为就是 if-else 语句)。比如: Authorization 场景:定义哪些用户(Identity)可对哪些资源(Resource)进行什么类型的操作(Operation)的规则 网络防火墙规则:比如 iptables 中设定的规则,Kubernetes 中的 Network Policy 都可认为是与网络相关的 Policy 资源准入控制:符合某种 Policy 的资源(比如必须设置某些属性或字段)才可以被业务层处理,否则将被拒绝服务,典型的有 Kubernetes 的 Admission Control...
- 下一篇
前端请求cookie丢失问题
问题提出 在开发中的登陆功能基本思路如下: 前端请求验证码,后端生成一个验证码(保存在session中)并将其返回给前端, 前端用户输入账号、密码、验证码后将表单传给后端,后端对比session中的验证码和用户输入的是否一致。 但是后端在第二步时,session中没有存有之前生成的验证码,也就无法对比用户的验证码是否正常,导致系统一直无法进入。 问题分析 首先需要考虑跨域问题,前端发送请求时要携带cookie,否则获取验证码请求和登陆请求会创建两次session,导致无法取出上一次产生的验证码。打开开发者工具会发现请求头中没有cookie。 解决思路 在项目前后端中加入跨域代码 https://www.jianshu.com/p/dc506490c796 // 前端案例 https://www.cnblogs.com/gcdd/p/12292415.html //后端案例 但是本项目在前后端已经加入了相关的代码,还是存在没有cookie的现象。 浏览器层面问题 之前测试都是在chrome浏览器中进行的,换了火狐发现这个问题不复存在了,所以很可能是chrome浏览器的问题,经过百度发现c...
相关文章
文章评论
共有0条评论来说两句吧...