上文讲到，客户端设备向服务端设备发起认证start请求，本文将介绍服务端接收到请求消息后的处理过程以及如何响应客户端。/*函数功能：构造json格式的认证start响应消息函数参数：data：待发送数据内容地址函数返回值：成功：json格式的字符串失败：NULL*///接收该响应数据//定义临时变量结构体//将原始的authData字节数据转换为十六进制的字符串//将原始的challenge字节数

在HiChain本端接收数据的处理过程中：（1）在正确解析并处理完接收的数据之后，应构造相应的通知消息回复给对端。（2）在消息处理过程中会有出现错误的情况，在发现错误之后，应针对相应的错误情况通知对端，否则对端会一直处于未知状态。本文将介绍回复通知的相应过程。

在上一篇博客中提到，服务端针对客户端发起的end请求，作出了end响应，因此，本文将介绍客户端接收到end响应之后的处理过程。

trans_service模块基于系统内核提供的socket通信，向authmanager模块提供设备认证通道管理和设备认证数据的传输；向业务模块提供session管理和基于session的数据收发功能，并且通过GCM模块的加密功能提供收发报文的加解密保护。本文是分布式软总线的会话管理机制的结尾部分，在前文中介绍了新会话中客户端请求数据的处理过程，本文重点介绍普通会话中的新数据处理。衔接OpenH

本文继续分析samgr_lite的函数实现。文件位于distributedschedule_samgr_lite\samgr\source\samgr_lite.c。本部分还有许多函数待分析，将在后续的文章进行分析。获取未初始化服务的下标。查询系统能力是否存在。获取已注册的系统能力。

从中可以看到厂商适配相关接口的存放目录应为“$ohos_vendor_adapter_dir/hals/utils/file”，且该目录下 BUILD.gn 文件中的目标应为 hal_file_static。utils 部件可被各业务子系统及上层应用使用，依赖芯片文件系统实现，需要芯片平台提供文件打开、关闭、读写、获取大小等功能。

该文件代码的功能主要是提供以cJSON格式获取各个设备的信息，包括设备id、链接信息、设备名、设备类型等。下面将对该文件的每一个函数进行详细分析。

本文主要针对service部分进行分析，这部分代码的分析囊括了interfaces\kits\samgr\service.h、samgr\source\service_impl.h和samgr\source\service.c。service.h的代码在service赏析一篇中已经进行过分析。

【鸿蒙OH 5.0】OpenHarmony轻量系统服务管理|进程间通信的核心机制详解(四)

操作的处理函数以及本部分的其他函数。接着上文继续分析剩下的。