随笔分类 -  OpenHarmony

开源大赛
摘要:前言 hks_rkc.c文件主要定义了根密钥组件和对主密钥的管理。密钥管理的目的是确保密钥的安全性,即密钥的真实性和有效性,进而来保证密码系统的安全性。 密钥分层管理 Huks密钥管理模块应该也是使用了多级密钥分层管理机制,这里简单介绍密钥的层级结构以及各层密钥。 密钥的层次结构: 系统使用主密钥来 阅读全文
posted @ 2022-06-25 22:00 沉心慢慢 阅读(537) 评论(0) 推荐(0) 编辑
摘要:密钥管理子系统 HUKS提供了密钥与证书管理服务来保证数据安全。它可用于保障上层设备之间信任关系(设备认证)。 我们首先给出HUKS的总体框架图,之后再逐步分析其中的每个组件。 总体框架图 huks主要涉及的是密钥管理服务。其总体框架图: 根主密钥管理组件 HUKS密钥管理机制是采用了多级密钥管理方 阅读全文
posted @ 2022-06-25 21:56 沉心慢慢 阅读(625) 评论(0) 推荐(0) 编辑
摘要:前言 这部分将分析当设备收到对端设备发现报文时,需要发送响应报文的过程。 接收与响应coap设备发现 1 /* 2 函数功能: 获取服务发现信息 3 函数参数: 4 buf : 指向保存有服务信息的数据缓冲区 5 size : 数据缓冲区大小 6 deviceInfo: 用来保存设备信息 7 rem 阅读全文
posted @ 2022-06-25 21:49 沉心慢慢 阅读(362) 评论(0) 推荐(0) 编辑
摘要:前言 coap_discover.c实现了基于coap的设备发现功能的细节。在之前说过coap_service.c在实现coap服务发现的前期工作中做了许多前期初始化功能和注册服务的工作,这些功能函数是调用nstackx_device.c提供的接口函数,而nstackx_common.c中的接口函数 阅读全文
posted @ 2022-06-25 21:46 沉心慢慢 阅读(320) 评论(0) 推荐(0) 编辑
摘要:前言 coap_service.c代码中基本上每个接口函数都调用了nstackx_common.c中的接口,最终nstackx_common.c中的接口函数再调用coap_discover.c中的接口函数。所以coap_service.c中的接口函数是对外提供的顶层接口,分析过程也是从顶层宏观调用到 阅读全文
posted @ 2022-06-07 19:43 沉心慢慢 阅读(493) 评论(0) 推荐(0) 编辑
摘要:前言 coap_service.c这个文件是在设备启动时,为设备服务发现进行前期初始化并且负责注册设备信息和服务。初始化包括coap socket、消息队列线程、监听线程等。初始化之后就可以注册功能服务啦。下面来分析coap_service.c具体是如何做前期准备的。 代码分析 Coap服务发现初始 阅读全文
posted @ 2022-06-07 19:37 沉心慢慢 阅读(407) 评论(0) 推荐(0) 编辑
摘要:前言 之前在服务发布总体流程中说过OpenHarmony是服务发布功能是基于COAP轻量级协议的。在本篇中,将简单介绍COAP协议,并且分析OpenHarmony中对Coap协议的封包(拆包就是反操作)源码。 Coap协议[1][2] CoAP是受限制的应用协议(Constrained Applic 阅读全文
posted @ 2022-05-23 23:59 沉心慢慢 阅读(754) 评论(0) 推荐(0) 编辑
摘要:前言 iunknown是针对服务和功能的统一对外接口,头文件位于distributedschedule_samgr_lite\interfaces\kits\samgr\iunknown.h。iunknown为系统功能的外部功能提供基类和默认实现。 IUnknown背景 要想清楚的理解IUnknow 阅读全文
posted @ 2022-04-22 22:34 沉心慢慢 阅读(275) 评论(0) 推荐(1) 编辑
摘要:前言 之前说过鸿蒙实现了自己的vector容器,叫做SimpleVector,其代码位于distributedschedule_samgr_lite\interfaces\kits\samgr\common.h,现在来分析下其代码。 头文件分析 1 typedef struct SimpleVect 阅读全文
posted @ 2022-04-22 22:23 沉心慢慢 阅读(117) 评论(0) 推荐(0) 编辑
摘要:前言 之前分析了在同一进程内不同服务间采用的通信机制是消息队列。然而,在不同进程间服务的通信机制并不是鸿蒙系统设计的消息队列,而是采用了共享内存。这是因为同一进程内的各个服务的地址空间是共用的,所以消息队列的首地址一旦分配就是唯一的。而不同进程间的各个服务的地址空间是独立的,消息队列就不再适用。并且 阅读全文
posted @ 2022-04-19 22:12 沉心慢慢 阅读(784) 评论(0) 推荐(0) 编辑
摘要:前言 之前介绍了鸿蒙业务模型中的三大概念以及简单的注册过程,相信读者已经对鸿蒙的业务逻辑有了一定的了解。简单的来说,就是将多个子功能注册到服务中,再把服务注册到全局系统功能管理器(Samgr)中。这样,一个服务包含零个或多个功能,而功能又绑定了对外接口,然后我们可以向暴露的接口发送消息,等服务执行特 阅读全文
posted @ 2022-04-19 22:00 沉心慢慢 阅读(611) 评论(0) 推荐(0) 编辑
摘要:前言 在针对鸿蒙分布式任务调度的源代码分析中,发现它业务逻辑的实现围绕着三大概念展开,分别是服务(Service)、功能(Feature)和功能接口API(Iunknown)。所以理解并掌握这三个概念对于我们深入学习鸿蒙底层代码的业务逻辑有极大的帮助。下面将结合前期分析鸿蒙代码的经验,通过图文并茂的 阅读全文
posted @ 2022-04-19 21:24 沉心慢慢 阅读(456) 评论(0) 推荐(0) 编辑
摘要:引言 Reactor模式是处理并发I/O比较常见的一种模式,中心思想是将所有的事件(handler)的具体I/O事件注册到一个多路复用器(epoll)上,同时我们的主线程都阻塞在多路复用器(epoll)上,同时我们的事件有I/O事件触发(文件描述符可读、可写、错误、关闭),多路复用器(epoll)上 阅读全文
posted @ 2022-04-09 21:18 沉心慢慢 阅读(485) 评论(3) 推荐(2) 编辑
摘要:discovery_service.c 前言 分布式软总线是鸿蒙系统的基石,它不仅负责设备间的发现和服务的发布,还要负责实现设备间的数据传输。鸿蒙其他模块,比如设备认证等,都是需要通过软总线来与其他设备进行通信。本篇将基于OpenHarmony(v1.x)对其软总线进行分析。 发布与订阅 概述 分布 阅读全文
posted @ 2022-04-09 20:57 沉心慢慢 阅读(2781) 评论(0) 推荐(0) 编辑

点击右上角即可分享
微信分享提示