鸿蒙模块一trans_service目录下auth_conn_manager.c和auth_conn_manager.h文件解析

其中trans_service目录主要负责设备的身份验证和传输通道，提供设备认证机制。而auth机制在设备认证和用户权限验证中发挥着重要的作用。

auth机制是一个开放标准，允许用户授权第三方移动应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容。

使用场景：
用户不再需要注册大量账号
用于单点登录
用于分布式系统的权限控制

运行流程

运行流程：
（A）用户打开客户端以后，客户端要求用户给予授权。
（B）用户同意给予客户端授权。
（C）客户端使用上一步获得的授权，向认证服务器申请令牌。
（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。
（E）客户端使用令牌，向资源服务器申请获取资源。
（F）资源服务器确认令牌无误，同意向客户端开放资源。

四种授权模式

1. 授权码
   

（1）用户访问客户端，后者将前者导向认证服务器，假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。
（2）客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌：GET /oauth/token?response_type=code&client_id=test&redirect_uri=重定向页面链接。请求成功返回code授权码，一般有效时间是10分钟。
（3）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。POST /oauth/token?response_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=重定向页面链接。请求成功返回access Token和refresh Token。

2. 简化模式
   

适用于公开的浏览器单页应用
Access Token直接从授权服务器返回(只有前端渠道)
不支持refresh tokens
假定资源所有者和公开客户应用在同一个设备上
最容易受安全攻击

3. 用户名密码
   

使用用户名密码登录的应用，例如桌面App
使用用户名/密码作为授权方式从授权服务器上获取access token
一般不支持refresh token
假定资源拥有者和公开客户子啊相同设备上

4. 客户端凭证
   

适用于服务器见通信场景，机密客户代表它自己或者一个用户
只有后端渠道，使用客户凭证获取一个access token
因为客户凭证可以使用对称或者非对称加密，该方式支持共享密码或者证书

代码部分：
auth_conn_manager.h内容
（路径：模块一\communication_softbus_lite-master\trans_service\include\libdistbus\auth_conn_manager.h）

#ifndef AUTH_CONN_MANAGER_H
#define AUTH_CONN_MANAGER_H
/// 这里使用条件编译，减少编译的工程量。加快共同调用时候的编译速度
#include "bus_manager.h"
int StartListener(BaseListener* callback, const char *ip);
void StopListener(void);
void CloseAuthSessionFd(int fd);
///添加三个函数定义声明，便于auth_conn_manager.c直接调用函数
#endif // AUTH_CONN_MANAGER_H
/// 使用宏定义来编辑头文件，加快执行效率

由于头文件有关于多种变量以及函数的声明，故在源文件包含的时候，容易造成多重包含，引起变量和函数的重复声明和定义。头文件一般选用条件编译的格式可以避免多个c文件共同调用同一个头文件时候重复编译。

auth_conn_manager.c头文件内容
（路径：模块一\communication_softbus_lite- master\trans_service\source\libdistbus\auth_conn_manager.c）

#include "auth_conn_manager.h"
#include <arpa/inet.h>
// defined()函数检查某常量是否存在，若存在则返回true，否则返回false
#if defined(__LITEOS_M__) || defined(__LITEOS_RISCV__)
/// 前者是基于鸿蒙内核LITEOS_M,后者是基于RISC-V的现有内核
/*这个条件编译检查__LITEOS_M__和__LITEOS_RISCV__是否存在，如果存在则调用else之前的头文件否则调用else和endif之间的头文件*/
#include <cmsis_os.h>
#include <lwip/sockets.h>
#else
#include <errno.h>
#include <pthread.h>
#include <signal.h>
#include <sys/socket.h>
#include <sys/time.h>
#endif
/* 前面使用条件编译*/
#include <stdbool.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/select.h>
#include <sys/types.h>
#include <unistd.h>
#include "data_bus_error.h"
#include "os_adapter.h"
#include "tcp_socket.h"
#define DEFAULT_BACKLOG    4 
#define SESSIONPORT        0
/* 定义默认返回日志为4，和服务器端口为0*/
BaseListener *g_callback = NULL;
static int g_listenFd = -1;
static int g_dataFd = -1;
static int g_maxFd = -1;
/*初始化部分变量*/
#if defined(__LITEOS_M__) || defined(__LITEOS_RISCV__)
static osThreadId_t g_uwTskLoID;
#endif
/*这里同上面使用条件编译，检查__LITEOS_M__和__LITEOS_RISCV__是否存在，如果存在则调用else之前的内容，否则调用else和endif之间的内容*/

任务or线程？

经过分析take_manager代码，我们发现任务的出现常常伴随着线程，任务池的工作和线程的工作原理有一定的相似度，我们今天分析一下这两者的区别。
鸿蒙中任务就是一种线程，二者本质上没有区别，只是在不同的应用环境下有不一样的名字
下面附上任务的定义代码

typedef struct {
    VOID            *stackPointer;      /**< Task stack pointer */ //内核态栈指针，SP位置，切换任务时先保存上下文并指向TaskContext位置
    UINT16          taskStatus;         /**< Task status */   //各种状态标签，可以拥有多种标签，按位标识
    UINT16          priority;           /**< Task priority */  //任务优先级[0:31]，默认是31级
    UINT16          policy;    //任务的调度方式(三种 .. LOS_SCHED_RR )
    UINT16          timeSlice;          /**< Remaining time slice *///剩余时间片
    UINT32          stackSize;          /**< Task stack size */  //非用户模式下栈大小
    UINTPTR         topOfStack;         /**< Task stack top */  //非用户模式下的栈顶 bottom = top + size
    UINT32          taskID;             /**< Task ID */    //任务ID，任务池本质是一个大数组，ID就是数组的索引，默认 < 128
    TSK_ENTRY_FUNC  taskEntry;          /**< Task entrance function */ //任务执行入口函数
    VOID            *joinRetval;        /**< pthread adaption */ //用来存储join线程的返回值
    VOID            *taskSem;           /**< Task-held semaphore */ //task在等哪个信号量
    VOID            *taskMux;           /**< Task-held mutex */  //task在等哪把锁
    VOID            *taskEvent;         /**< Task-held event */  //task在等哪个事件
    UINTPTR         args[4];            /**< Parameter， of which the maximum number is 4 */ //入口函数的参数 例如 main (int argc，char *argv[])
    CHAR            taskName[OS_TCB_NAME_LEN]; /**< Task name */ //任务的名称
    LOS_DL_LIST     pendList;           /**< Task pend node */  //如果任务阻塞时就通过它挂到各种阻塞情况的链表上，比如OsTaskWait时
    LOS_DL_LIST     threadList;         /**< thread list */   //挂到所属进程的线程链表上
    SortLinkList    sortList;           /**< Task sortlink node */ //挂到cpu core 的任务执行链表上
    UINT32          eventMask;          /**< Event mask */   //事件屏蔽
    UINT32          eventMode;          /**< Event mode */   //事件模式
    UINT32          priBitMap;          /**< BitMap for recording the change of task priority， //任务在执行过程中优先级会经常变化，这个变量用来记录所有曾经变化
                                             the priority can not be greater than 31 */   //过的优先级，例如 ..01001011 曾经有过 0，1，3，6 优先级
    INT32           errorNo;            /**< Error Num */
    UINT32          signal;             /**< Task signal */ //任务信号类型，(SIGNAL_NONE，SIGNAL_KILL，SIGNAL_SUSPEND，SIGNAL_AFFI)
    sig_cb          sig;    //信号控制块，这里用于进程间通讯的信号，类似于 linux singal模块
#if (LOSCFG_KERNEL_SMP == YES)
    UINT16          currCpu;            /**< CPU core number of this task is running on */ //正在运行此任务的CPU内核号
    UINT16          lastCpu;            /**< CPU core number of this task is running on last time */ //上次运行此任务的CPU内核号
    UINT16          cpuAffiMask;        /**< CPU affinity mask， support up to 16 cores */ //CPU亲和力掩码，最多支持16核，亲和力很重要，多核情况下尽量一个任务在一个CPU核上运行，提高效率
    UINT32          timerCpu;           /**< CPU core number of this task is delayed or pended */ //此任务的CPU内核号被延迟或挂起
#if (LOSCFG_KERNEL_SMP_TASK_SYNC == YES)
    UINT32          syncSignal;         /**< Synchronization for signal handling */ //用于CPU之间 同步信号
#endif
#if (LOSCFG_KERNEL_SMP_LOCKDEP == YES) //死锁检测开关
    LockDep         lockDep;
#endif
#if (LOSCFG_KERNEL_SCHED_STATISTICS == YES) //调度统计开关，显然打开这个开关性能会受到影响，鸿蒙默认是关闭的
    SchedStat       schedStat;          /**< Schedule statistics */ //调度统计
#endif
#endif
    UINTPTR         userArea;   //使用区域，由运行时划定，根据运行态不同而不同
    UINTPTR         userMapBase;  //用户模式下的栈底位置
    UINT32          userMapSize;        /**< user thread stack size ，real size : userMapSize + USER_STACK_MIN_SIZE */
    UINT32          processID;          /**< Which belong process *///所属进程ID
    FutexNode       futex;    //实现快锁功能
    LOS_DL_LIST     joinList;           /**< join list */ //联结链表，允许任务之间相互释放彼此
    LOS_DL_LIST     lockList;           /**< Hold the lock list */ //拿到了哪些锁链表
    UINT32          waitID;             /**< Wait for the PID or GID of the child process */ //等待孩子的PID或GID进程
    UINT16          waitFlag;           /**< The type of child process that is waiting， belonging to a group or parent，
                                             a specific child process， or any child process */
#if (LOSCFG_KERNEL_LITEIPC == YES)
    UINT32          ipcStatus;   //IPC状态
    LOS_DL_LIST     msgListHead;  //消息队列头结点，上面挂的都是任务要读的消息
    BOOL            accessMap[LOSCFG_BASE_CORE_TSK_LIMIT];//访问图，指的是task之间是否能访问的标识，LOSCFG_BASE_CORE_TSK_LIMIT 为任务池总数
#endif
} LosTaskCB;

代码定义部分很长，该结构体有一定复杂性。

描述

线程是计算资源竞争的最小单元，线程可以使用或等待CPU、使用内存空间等系统资源，并独立于其它线程运行。
鸿蒙内核每个进程内的线程独立运行、独立调度，当前进程内线程的调度不受其它进程内线程的影响。
线程的状态说明：

• 初始化（Init）：该线程正在被创建。
• 就绪（Ready）：该线程在就绪列表中，等待CPU调度。
• 运行（Running）：该线程正在运行。
• 阻塞（Blocked）：该线程被阻塞挂起。Blocked状态包括：pend(因为锁、事件、信号量等阻塞)、suspend（主动pend）、delay(延时阻塞)、pendtime(因为锁、事件、信号量时间等超时等待)。
• 退出（Exit）：该线程运行结束，等待父线程回收其控制块资源。
  
  这里的任务和线程概念已经没什么区别，主要是不同情况下的称谓不同而已。

OpenHarmony LiteOS-M的任务模块可以给用户提供多个任务，实现任务间的切换，帮助用户管理业务程序流程。任务模块具有如下特性：

• 支持多任务。
• 一个任务表示一个线程。
• 抢占式调度机制，高优先级的任务可打断低优先级任务，低优先级任务必须在高优先级任务阻塞或结束后才能得到调度。
• 相同优先级任务支持时间片轮转调度方式。
• 共有32个优先级[0-31]，最高优先级为0，最低优先级为31。

任务相关概念

任务状态

任务有多种运行状态。系统初始化完成后，创建的任务就可以在系统中竞争一定的资源，由内核进行调度。

任务状态通常分为以下四种：

• 就绪（Ready）：该任务在就绪队列中，只等待CPU。
• 运行（Running）：该任务正在执行。
• 阻塞（Blocked）：该任务不在就绪队列中。包含任务被挂起（suspend状态）、任务被延时（delay状态）、任务正在等待信号量、读写队列或者等待事件等。
• 退出态（Dead）：该任务运行结束，等待系统回收资源。

四种状态的关系

任务相关属性

任务ID

任务ID，在任务创建时通过参数返回给用户，是任务的重要标识。系统中的ID号是唯一的。用户可以通过任务ID对指定任务进行任务挂起、任务恢复、查询任务名等操作。

任务优先级

优先级表示任务执行的优先顺序。任务的优先级决定了在发生任务切换时即将要执行的任务，就绪队列中最高优先级的任务将得到执行。

任务入口函数

新任务得到调度后将执行的函数。该函数由用户实现，在任务创建时，通过任务创建结构体设置。

任务栈

每个任务都拥有一个独立的栈空间，我们称为任务栈。栈空间里保存的信息包含局部变量、寄存器、函数参数、函数返回地址等。

任务上下文

任务在运行过程中使用的一些资源，如寄存器等，称为任务上下文。当这个任务挂起时，其他任务继续执行，可能会修改寄存器等资源中的值。如果任务切换时没有保存任务上下文，可能会导致任务恢复后出现未知错误。因此在任务切换时会将切出任务的任务上下文信息，保存在自身的任务栈中，以便任务恢复后，从栈空间中恢复挂起时的上下文信息，从而继续执行挂起时被打断的代码。

任务控制块TCB

每个任务都含有一个任务控制块(TCB)。TCB包含了任务上下文栈指针（stack pointer）、任务状态、任务优先级、任务ID、任务名、任务栈大小等信息。TCB可以反映出每个任务运行情况。

任务切换

任务切换包含获取就绪队列中最高优先级任务、切出任务上下文保存、切入任务上下文恢复等动作。

任务运行机制

用户创建任务时，系统会初始化任务栈，预置上下文。此外，系统还会将“任务入口函数”地址放在相应位置。这样在任务第一次启动进入运行态时，将会执行“任务入口函数”。

一、获取源码与编译

用到的工具 虚拟机VMwareWorkstation   MobaXterm   RaiDrive    Visual Studio Code 四个工具

在MobaXterm用SSH连接到虚拟机上的地址的前提下在命令行敲命令 

第一种方法：使用HPM下载源码

1、创建文件夹 mkdir code
2、切换到文件夹 cd code
3、创建code1
4、切换到code1
5、hpm init -t default  获取源码   出现 initialization finised 表示成功

6、hpm dist 编译源码直至编译完成

第二种方法：从代码仓库下载源码

1、mkdir code2
2、cd code2
3、git clone https://gitee.com/bearpi/bearpi-hm _nano  下载   

3、查看下载目录 ls
4、python build.py BearPi-HM_Nano 编译源码直至完成       （BearPi-HM_Nano ）开发版的名字

二、烧录

烧录

1、

安装CH340驱动

2、

Hiburn烧录工具

3、电脑管理 设备管理器 端口 com几

4、打开hiburn工具

Com口改成对应的口

打开setting   com settings  波特率改成921600

Select file

路径：SFTP/home/bearpi/code/code1/out/BearPi-HM_Nano/Hi3861_wifiiot_app_allinone.bin

勾选 Auto burn

点击 Connect  之后按一下开发板的复位按键，开始烧录

出现上图表示烧录完成

烧录完成点击Disconnect

5、用MobaXterm查看开发板是否烧录成功

点击Session

点击Serial

改成对应的com口   波特率改成 115200 点击ok

接下来点击开发板的复位按钮  

上图显示烧录完成。