分布式软总线——服务发布

已于 2023-05-11 14:14:44 修改
阅读量538 收藏 7
点赞数 1
分类专栏： Harmony 文章标签： 分布式 服务发布 鸿蒙OS
于 2021-11-15 20:29:29 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/enternalwiser/article/details/121327479
版权

服务发布——基于COAP协议的UDP通信机制

总体概述

  1. 入口函数PublishService
    首先检查是否有调用软总线的权限，然后申请互斥锁开始对数据的修改，调用初始化服务函数将设备信息保存，开启WiFi监听并开启软总线工作，建立服务并启动多个线程同时工作，用于数据的收发，将相关信息保存入队列并进行登记，然后将发布模式的信息进行登记保存完成服务的发布
    以下是函数流转图：
    在这里插入图片描述
  2. CoapInitDiscovery发现服务实际的初始化函数
    首先建立本设备的套接字作为UDP服务端，创建WiFi消息队列，用于接受WiFi相关信息，然后建立一个消息线程进行监听，线程调用线程处理函数在readSet中维护一个可读套接字的集合，从其中读取信息放入消息队列中处理，最后创建响应的UDP客户端进行数据的回应(注意这里创建的客户端是临时的，用完即销毁的，不会长期维护)
    以下为函数流转图：
    在这里插入图片描述
  3. COAP协议规定下的数据解析和封装过程
    char* 、cJSON类型的转换
    在本地时使用cJSON类型方便解析出对应的信息，方便验证和封装；
    在网络传输时使用char*类型方便网络传输
    在这里插入图片描述
  4. 基于COAP协议的UDP通信机制
    这里方便读者理解，将UDP通信的机制以及WiFi事件在队列相应被消息处理线程处理的两个过程在图中呈现。

这里需要注意两点：

  • WiFi接入的具体处理函数交给了WiFiEventTrigger来开启总线的通信以及后续的用户认证和TCP通信
  • 在该场景的UDP中也就是基于COAP协议的UDP传输中，服务端socket是一直存在的，而客户端socket是不断更新，不维护的，当有下一次数据需要回应时，就会更新客户端的套接字，进行数据封装和发送，数据的解析和报文的封装过程在上一张图中有详细解读
    在这里插入图片描述

经过上述的讲解，下面的源码解读会容易许多：

源码阅读——PublishService

函数较长但是大部分都是参数检查和错误处理

/*
函数功能：通过该函数来发现外部设备
函数参数：moduleName：上层模式名；info：包含发布服务的各种信息；cb：publish的回调函数
函数返回：<0失败；=0成功
*/
int PublishService(const char *moduleName, const struct PublishInfo *info, const struct IPublishCallback *cb)
{
    //权限检查
    if (SoftBusCheckPermission(SOFTBUS_PERMISSION) != 0 || info == NULL || cb == NULL) {
        SOFTBUS_PRINT("[DISCOVERY] PublishService invalid para(info or cb)\n");
        return ERROR_INVALID;
    }

    if (moduleName == NULL || strlen(moduleName) >= MAX_PACKAGE_NAME || info->publishId <= 0 ||
        info->dataLen > MAX_CAPABILITY_DATA_LEN) {
        SOFTBUS_PRINT("[DISCOVERY] PublishService invliad para\n");
        PublishCallback(info->publishId, PUBLISH_FAIL_REASON_PARAMETER_INVALID, NULL, cb);
        return ERROR_INVALID;
    }

    //是否为COAP协议(即WiFi)
    if (info->medium != COAP) {
        PublishCallback(info->publishId, PUBLISH_FAIL_REASON_NOT_SUPPORT_MEDIUM, NULL, cb);
        return ERROR_INVALID;
    }

    if (g_discoveryMutex == NULL) {
        g_discoveryMutex = MutexInit();
        if (g_discoveryMutex == NULL) {
            PublishCallback(info->publishId, PUBLISH_FAIL_REASON_UNKNOWN, NULL, cb);
            return ERROR_FAIL;
        }
    }

    //互斥锁的检查
    MutexLock(g_discoveryMutex);
    if (InitService() != ERROR_SUCCESS) {
        SOFTBUS_PRINT("[DISCOVERY] PublishService InitService fail\n");
        PublishCallback(info->publishId, PUBLISH_FAIL_REASON_UNKNOWN, NULL, cb);
        MutexUnlock(g_discoveryMutex);
        return ERROR_FAIL;
    }

    //添加新的g_publishModule并返回对应的结构体指针
    PublishModule *findModule = AddPublishModule(moduleName, info);
    if (findModule == NULL) {
        SOFTBUS_PRINT("[DISCOVERY] PublishService AddPublishModule fail\n");
        PublishCallback(info->publishId, PUBLISH_FAIL_REASON_UNKNOWN, NULL, cb);
        MutexUnlock(g_discoveryMutex);
        return ERROR_FAIL;
    }
	
    int ret = ERROR_SUCCESS;
    //不存在则将默认的0存入g_localDeviceInfo.serviceData[]中
    if (info->capability == NULL || info->capabilityData == NULL) {
        (void)CoapRegisterDefualtService();
    //存在则将其携带的capabilityMap和serviceData写入g_localDeviceInfo
    } else {
        ret = DoRegistService(info->medium);
    }
    //释放互斥锁
    MutexUnlock(g_discoveryMutex);

    if (ret != ERROR_SUCCESS) {
        PublishCallback(info->publishId, PUBLISH_FAIL_REASON_UNKNOWN, findModule, cb);
        return ERROR_FAIL;
    } else {
        PublishCallback(info->publishId, ERROR_SUCCESS, findModule, cb);
        return ERROR_SUCCESS;
    }
}

函数流程：
1. 首先调用SoftBusCheckPermission进行权限检查，判断当前是否能够启动服务
2. 对于传入参数的检查。检查moduleName的大小和info中规定的介质是否为COAP
3. 获取全局互斥锁g_discoveryMutex
4. 调用InitService完成服务的初始化
5. 调用AddPublishModule添加一个新的g_publishModule并返回对应的结构体指针
6. 对于info中的capability相关信息的注册(存储)

可以知道主要的初始化功能由InitService完成，其余的步骤起检查和存储作用

InitService

初始化的主要函数

/*
函数功能：初始化服务
函数参数：void
函数返回：ERROR_SUCCESS；ERROR_FAIL；ERROR_NOMEMORY
*/
int InitService(void)
{
    if (g_isServiceInit != 0) {
        return ERROR_SUCCESS;
    }
    //初始化g_deviceInfo——将deviceId进行了加密存储
    if (InitCommonManager() != 0) {
        SOFTBUS_PRINT("[DISCOVERY] InitService InitCommonManager fail\n");
        DeinitService();
        return ERROR_FAIL;
    }

    g_publishModule = calloc(1, sizeof(PublishModule) * MAX_MODULE_COUNT);
    if (g_publishModule == NULL) {
        DeinitService();
        return ERROR_NOMEMORY;
    }

    g_capabilityData = calloc(1, MAX_SERVICE_DATA_LEN);
    if (g_capabilityData == NULL) {
        DeinitService();
        return ERROR_NOMEMORY;
    }

    //调用WifiEventTrigger函数
    //并将其登记入g_wifiCallback
    RegisterWifiCallback(WifiEventTrigger);
    //coap协议服务初始化
    int ret = CoapInit();
    if (ret != ERROR_SUCCESS) {
        SOFTBUS_PRINT("[DISCOVERY] InitService CoapInit fail\n");
        DeinitService();
        return ret;
    }
    //将消息写入队列中
    CoapWriteMsgQueue(UPDATE_IP_EVENT);
    //根据DeviceInfo更新nstackInfo并将deviceHash和localDeviceInfo更新到g_localDeviceInfo中
    ret = CoapRegisterDeviceInfo();
    if (ret != ERROR_SUCCESS) {
        SOFTBUS_PRINT("[DISCOVERY] InitService CoapRegisterDeviceInfo fail\n");
        DeinitService();
        return ret;
    }
    g_isServiceInit = 1;
    SOFTBUS_PRINT("[DISCOVERY] InitService ok\n");
    return ERROR_SUCCESS;
}

可以主要从五个函数入手：InitCommonManager、RegisterWifiCallback、CoapInit、CoapWriteMsgQueue和CoapRegisterDeviceInfo

1. InitCommonManager

由该函数来完成初始化的功能

1.1 InitLocalDeviceInfo

//初始化本地设备信息(g_deviceinfo)
int InitLocalDeviceInfo(void)
{
    char deviceId[DEVICEID_MAX_NUM] = {0};

    if (g_deviceInfo != NULL) {
        memset_s(g_deviceInfo, sizeof(DeviceInfo), 0, sizeof(DeviceInfo));
    } else {
        g_deviceInfo = (DeviceInfo *)calloc(1, sizeof(DeviceInfo));
        if (g_deviceInfo == NULL) {
            return ERROR_FAIL;
        }
    }
    //初始化端口和是否信任状态为-1
    g_deviceInfo->devicePort = -1;
    g_deviceInfo->isAccountTrusted = 1;

    unsigned int ret;
    //获取加密后的deviceid
    ret = GetDeviceIdFromFile(deviceId, MAX_VALUE_SIZE);
    if (ret != ERROR_SUCCESS) {
        SOFTBUS_PRINT("[DISCOVERY] Get device fail\n");
        return ERROR_FAIL;
    }
    //不同内核存储的信息不同
#if defined(__LITEOS_M__) || defined(__LITEOS_RISCV__)
    g_deviceInfo->deviceType = L0;
    ret = (unsigned int)strcpy_s(g_deviceInfo->deviceName, sizeof(g_deviceInfo->deviceName), L0_DEVICE_NAME);
#else
    g_deviceInfo->deviceType = L1;
    ret = (unsigned int)strcpy_s(g_deviceInfo->deviceName, sizeof(g_deviceInfo->deviceName), L1_DEVICE_NAME);
#endif

    ret |= (unsigned int)strcpy_s(g_deviceInfo->deviceId, sizeof(g_deviceInfo->deviceId), deviceId);
    ret |= (unsigned int)strcpy_s(g_deviceInfo->version, sizeof(g_deviceInfo->version), "1.0.0");
    if (ret != 0) {
        return ERROR_FAIL;
    }

    SOFTBUS_PRINT("[DISCOVERY] InitLocalDeviceInfo ok\n");
    return ERROR_SUCCESS;
}

我们可以看看DeviceInfo结构体中都包含了哪些信息：
在这里插入图片描述
其中deviceType有如下定义：
在这里插入图片描述
该初始化函数初始化了以下属性：

devicePort：-1
isAccountTrusted：1
deviceName：L1_DEVICE_NAME|L0_DEVICE_NAME
deviceId：deviceId(加密过并存储在本地文件中)
version：" 1.0.0"

函数主要是初始化工作
有个函数比较有意思：GetDeviceIdFromFile

1.2 GetDeviceIdFromFile

deviceId作为设备的唯一标识符十分重要，所有要保证其独一无二性，这里使用了伪随机生成的方法生成deviceId
在这里插入图片描述
函数流程：
1. 调用ReadDeviceId将存储在本地的deviceId取出，如果本地存在则直接返回该deviceId
2. 本地不存在deviceId，则需要随机初始化一个deviceId：调用hks_generate_random生成一个随机密钥——>调用GetRandomStr根据规则生成deviceId——>调用WriteDeviceId将deviceId写入本地以便下次调用

注意这里的加密算法——也就是为随机生成算法是不可逆的，所以一次生成，不可解密，也不需解密

2. RegisterWifiCallback

其调用：

RegisterWifiCallback(WifiEventTrigger);

其内部：
在这里插入图片描述
这里就调用了前几篇花费大力气讲解的WiFiEventTrigger并将其加入WiFi发现的回调函数中——也就是说当发现一个外部设备通过WiFi想要接入时，就会回调WiFiEventTrigger函数进行对接

具体的WiFiEventTrigger的讲解这里不再赘述，可以参考我的前几篇博客：
再谈WiFiEventTrigger——开启监听
再谈WiFiEventTrigger——数据处理与发送
再谈WiFiEventTrigger——会话开始

3. CoapInit

内部实现为NSTACKX_Init——CoapInitDiscovery

3.1 NSTACKX_Init

在这里插入图片描述
函数流程：
1. 判断当前g_nstackInitState的状态是否为start状态，不是则说明初始化完毕直接返回EOK
2. 是start状态则改为ONGOING状态并调用cJSON_InitHooks进行初始化并给cJSON提供空间分配和释放的能力
3. 调用CoapInitDiscovery初始化基于COAP协议的发现服务
4. 将state改为DONE状态返回EOK

所以初始化的三个状态：START——ONGOING——DONE
下面接着看CoapInitDiscovery

3.2 CoapInitDiscovery

在这里插入图片描述
由四个函数共同完成COAP初始化的任务：

  1. 首先初始化COAP的套接字——注意COAP协议使用的是UDP模式！在函数讲解中会详细讲解
  2. 初始化WiFi实践处理创建消息队列
  3. 创立两个线程一个用于处理消息、一个用于处理监听

这里当内核为A核是需要额外调用一个CreateQueryIpThread进行IP队列线程的创建

3.2.1 CoapInitSocket

在这里插入图片描述
函数流程：
1. 检查g_serverFd是否大于等于0，是则服务端存在直接返回、不存在则初始化sockAddr以及sin_port
2. 调用CoapCreateUdpServer进行UDP服务端的创建
3. 调用COAP_SoftBusInitMsgId初始化g_msgId为0

需要注意的是在函数CoapCreateUdpServer中创建的流程基本和TCP一致都是先socket再bind，但是在socket创建的时候有一个参数不同：

UDP：
int sockfd = socket(AF_INET, SOCK_DGRAM, 0);
TCP:(来自函数OpenTcpServer)
int fd = socket(AF_INET, SOCK_STREAM, 0);

这就是区分TCP和UDP的典型参数之一了，我们看看它分别规定了啥

  • SOCK_STREAM：不保留消息边界，将每次的消息作为一个完整的单元进行接收，通过若干次独立的读操作将数据取走；有序性，保证接受的数据字节和发送顺序是完全一致的——也就是说必须双方建立通信连接；无错性，也就是说当丢包超时时会进行重发确保错误消除
  • SOCK_DGRAM：无序到达；报文可能丢失，不会采取补救措施；报文有尺寸大小限制；不需要建立连接也能够进行发送

上述参数规定的区别恰好就是TCP与UDP通信的差别！

3.2.2 CoapInitWifiEvent

首先贴上源代码注释：
在这里插入图片描述
函数的主要作用为WiFi事件创建了一个消息队列wifiQue并且当定义了(LITEOS_M)或(LITEOS_RISCV)时为其配置了WiFi状态变换是回调处理函数g_coapEventHandler

3.2.3 CreateMsgQueThread

在这里插入图片描述
这里的线程创建同样因为内核的差异所以使用了不同的os_adapter进行适配，同样是通过CreateThread和一个running函数CoapWifiEventThread来完成一个线程资源的分配和线程处理函数的调度

来看看CoapWifiEventThread的内部逻辑
在这里插入图片描述
可以看到其调用ReadMsgQue将g_wifiQueueId消息队列中的数据读入handle中并调用handler进行处理

而这里的handler就是下面CoapWriteMsgQueue中的handler——也就是前面的主角wifiEventTrigger函数

3.2.4 CreateCoapListenThread

在这里插入图片描述

创建过程不再赘述，这里同样重点看下线程的实际运行函数CoapReadHandle
在这里插入图片描述
同样是select机制监测可读有请求的fd，检查刚刚创建的g_serverFd是否在其中，是则对其调用函数HandleReadEvent进行处理

由于调用较深，这里仅放上重要的源代码片段，更注重过程和逻辑

HandleReadEvent
涉及三个重要函数(顺序向下执行)

CoapSocketRecv：调用recvfrom从g_serverFd所在的服务端接收数据入recvBuffer中

COAP_SoftBusDecode：解析报文。主要判断以下几个属性：
pkt->protocol = COAP_UDP
pkt->header.ver = COAP_VERSION
pkt->header.tokenLen <= MAX_TOK_LEN & > 0 
并解析其可选配置option和payload

PostServiceDiscover：针对解析后的decodePacket进行相应

PostServiceDiscover

GetServiceDiscoverInfo：解析数据包pkt的payload，
将设备信息存于deviceInfo中，并获取remoteUrl
inet_ntop：将数字地址转换为适合显示的文本字符串

if (remoteUrl != NULL)
CoapResponseService：向解析得到的remoteUrl和IP发送消息回复

CoapResponseService

1. 首先封装了结构体CoapRequest.remoteUrl .remoteIp
调用PrepareServiceDiscover得到char* payload包含：
a. deviceInfo中的八个信息：
deviceId
devicename
type
hicomversion
mode
deviceHash
serviceData
capabilityBitmap
b. g_interfaceList中的wlanIp
wlanIp

2. 然后得到读写的缓冲区COAP_ReadWriteBuffer
3. 调用BuildSendPkt构造应答的packet包括option、remoteIp、payload等信息的封装得到sndPktBuff
4. 将得到的sndPktBuff和其长度dataLen封装入coapRequest
5. 调用CoapSendRequest将coapRequest发送

这里到关键的发送环节结合源码分析
CoapSendRequest
在这里插入图片描述
函数流程：
1. 首先设置了sockAddr包括remoteIp、port、family
2. 调用CoapCreateUdpClient传入sockAddr创建一个UDP客户端
3. 调用GetCoapClientSocket得到本地的客户端Fd
4. 调用CoapSocketSend将coapRequest发送到对应的目的地址

这里有趣的是，在发送回应信息的时候创建了一个客户端——也就是说在进行UDP通信的时候一个终端设备在某些特定的时候充当服务端，有的时候充当客户端——在这里回复的时候就是创建了一个客户端来进行sendTo

另外在CoapCreateUdpClient的代码中每次调用都会新生成一个socket并进行bind，然后调用CloseSocket将原来g_clientFd对应的socket关闭，然后将新的sockfd赋给g_clientFd——也就是说每次回复信息是都需要新创建一个客户端进行回复报文的发送，发送完毕后就再下一次消息回复时被销毁，从而能够创建新的客户端进行回复

也符合UDP尽力、无保障的传输特点——发送完之后当前客户端就销毁

但是UDP的服务端socket却是一直保留的用于接收remoteURL和remoteIp

4. CoapWriteMsgQueue

在这里插入图片描述
注意这里的handler所指的函数CoapHandleWifiEvent实际上就是刚刚在RegisterWifiCallback函数中得到wifiEventTrigger的g_wifiCallback

函数流程：
1. 将g_wifiCallback赋给handler并将其state更新为参数所带的UPDATE_IP_EVENT
2. 调用函数WriteMsgQue将handler发送到g_wifiQueueId所在的消息队列中

通过上述操作，消息队列中就存在了处理函数——也就是wifiEventTrigger每当发现设备WiFi接入时，消息队列会调用该函数进行连接或数据处理

5. CoapRegisterDeviceInfo

在这里插入图片描述
同样是信息在各个结构体的流转和更新，这里不再赘述

至此服务发布——基于COAP协议的UDP通信机制的全部内容到此结束！

国家一级假勤奋研究牲
关注
专栏目录
数据库——总线系统.ppt
03-14
【总线系统】是计算机硬件中的重要组成部分，它在计算机系统的多个组件之间提供了一条共享的信息传输路径。在典型的冯·诺依曼计算机系统结构中，CPU、内存、输入设备和输出设备等都需要通过总线进行数据交互。总线...
OpenHarmony源码分析之分布式软总线：authmanager模块(2)/设备认证通信管理
weixin_46669761的博客
04-18 820
一、 概述 authmanager模块是鸿蒙为设备提供认证机制的模块。模块内的主要处理过程包括报文的接收、解密、再次封装、加密、发送的步骤。备注：该版本的鸿蒙仅实现了基于WiFi即局域网的设备身份认证机制。 本文重点介绍在设备间建立起socket连接之后，系统是如何处理接收到的新数据。处理过程主要集中在wifi_auth_manager.c文件中。 二、 源码分析 当有设备发起连接请求时，首先在trans_service模块建立socket连接，建立连接之后，若有设备发送认证请求的数据，将在函数 Proc
Openharmony重要特性之一浅析分布式软总线
流风的专栏
08-04 7193
​ 分布式软总线能做什么？​ 1.1 通过共享一个局域网(wifi或蓝牙)，可以发现设备。​ 通过设备名等关键字可以查找到在共享的网络中所有设备，并进行通信。关键是不需要预告知晓对方设备的IP地址与端口。​ 1.2 支持消息、字节、流、文件的数据传输能力。​ 实际应用中，可以将文字、图片、文件或音视频流进行传输。​ 1.3 支持富设备、小型设备、轻量设备。​ 实际应用中，可以做到跨设备间使用。笔者在L0与L2、L2与L2等两类设备间测试通过。
HarmonyOS之分布式软总线
LinkEverything的博客
12-25 1万+
HarmonyOS的亮点之一是分布式软总线。什么是分布式软总线？为什么要提出分布式软总线？在这里我们对它做简要的介绍。
鸿蒙所谓的软总线，套娃DLNA SOMEIP协议，QNX系统
求变，从思想开始
12-09 4851
鸿蒙软总线
鸿蒙系统学习 框架概述（一）
求变，从思想开始
07-05 1万+
。鸿蒙的LiteOS才是用来对标Linux的，值得注意的是LiteOS和Linux是一样的，都是宏内核而不是之前宣传的微内核，鸿蒙的微内核可能要到过段时间才会发布。那么鸿蒙对标的产品是什么呢？是安卓和Windows。这也让安卓特别的难受，因为与它正在开发的Funchsia系统在地位上有较大的吻合，都是面向IOT设备的操作系统。我们可以看看这张图，在鸿蒙的整个框架中内核只是占比较小的一部分，而内核这部分里还分了两个内核子系统：Linux和LiteOS。所以内核位于鸿蒙就像心脏位于人体，非常重要但占比很小。如果
一 、分布式软总线原理
jijie_ming的博客
07-04 886
在具体编码实现时，开发者会遵循一定的设计模式，如工厂模式创建通信组件，观察者模式处理设备状态变化，以及代理模式处理远程服务调用等，来提升代码的可维护性和扩展性。分布式软总线（Distributed Soft Bus）是HarmonyOS（鸿蒙操作系统）中的关键技术之一，它负责提供设备间统一的分布式通信能力，使得不同终端设备能够像在同一台设备上一样进行高速、低延迟的数据传输和任务协同。
基于CAN总线分布式伺服系统研究.pdf
08-08
双CAN总线接口的设计允许系统中的所有节点——包括显示控制模块、伺服控制模块和伺服驱动器——都通过单一的CAN总线进行连接，从而简化了系统的结构并提高了数据传输的效率。 文章指出，CAN总线数据协议和实时性...
基于HLA分布式实时仿真系统中软总线设计.pdf
08-09
综上所述，文档详细分析了HLA/RTI架构及其在分布式实时仿真系统中的应用，并提出了创新的设计理念——轻量级低耦合软总线架构，这一设计提高了仿真系统的性能和可扩展性，对相关领域的科研工作和实际应用有着重要的...
分布式涂鸦源代码.zip
08-30
在分布式涂鸦源代码中，你将会看到如何利用鸿蒙OS的分布式软总线、分布式数据管理以及分布式任务调度等技术，实现在不同设备间的无缝协同。 1. **分布式软总线**：这是鸿蒙OS中的关键组件，它允许设备之间的直接...
鸿蒙实战开发：【分布式软总线组件】
2301_76813281的博客
03-15 2400
现实中多设备间通信方式多种多样(WIFI、蓝牙等)，不同的通信方式使用差异大，导致通信问题多；同时还面临设备间通信链路的融合共享和冲突无法处理等挑战。发现连接：提供基于Wifi、蓝牙等通信方式的设备发现连接能力。设备组网：提供统一的设备组网和拓扑管理能力，为数据传输提供已组网设备信息。数据传输：提供数据传输通道，支持消息、字节、流、文件的数据传输能力。业务方通过使用分布式软总线提供的API实现设备间的高速通信，不用关心通信细节，进而实现业务平台的高效部署与运行能力。
OpenHarmony 4.0 分布式软总线解析：设备发现与传输
maniuT的博客
04-10 2559
OpenHarmony 的分布式软总线子系统为 OpenHarmony 系统提供的通信相关的能力，包括：WLAN 服务能力、蓝牙服务能力、软总线、进程间通信 RPC（Remote Procedure Call）等通信能力。下面我们通过阅读 OpenHarmony 4.0 的源码，来解读一下 OpenHarmony 软总线当前的一个实现情况。
HarmonyOS最核心的“分布式软总线”技术解读
HarmonyOS技术社区
12-24 9700
文章来源 | HarmonyOS开发者公众平台 什么是分布式软总线呢？ 分布式软总线是HarmonyOS架构中最底层的技术 分布式软总线是HarmonyOS的大动脉 开发跨端应用，开发者们是否面临以下挑战： 1.跨端操作需要每次重复建立连接 2.近场通信方式（蓝牙，WiFi，UWB等）必须感知才能实现连接 3.无线环境必须建立标准的用于服务器的协议栈 4.不同物理层无法实现统一的开发体验 针对这些开发者的开发之痛，技术专家郑凯带来的分布式软总线的技术解读将给大家带来全新解决..
鸿蒙源码分析（十三）
安辰的博客
08-05 1880
软总线模块中trans_service目录分析总结 本文主要总结软总线模块下trans_service目录中个文件的作用和功能，宏观上把握trans_service在鸿蒙系统中发挥的作用。 一、分布式软总线介绍 1.1 总线 总线（Bus）是一个非常广泛的概念，在传统计算机硬件体系中应用的非常广泛。它是一种内部结构，是cpu、内存、输入、输出设备传递信息的公用通道，主机的各个部件通过总线相连接，外部设备通过相应的接口电路再与总线相连接，从而形成了计算机硬件系统。在计算机系统中，各个部件之间传送信息的公共通路
【鸿蒙实战开发】 HarmonyOS软总线的简单使用
最新发布
HarmonyOS_001的博客
07-16 1913
这份鸿蒙（HarmonyOS NEXT）文档包含了鸿蒙开发必掌握的核心知识要点，内容包含了（ArkTS、ArkUI开发组件、Stage模型、多端部署、分布式应用开发、音频、视频、WebGL、OpenHarmony多媒体技术、Napi组件、OpenHarmony内核、OpenHarmony南向开发、鸿蒙项目实战等等）鸿蒙（HarmonyOS NEXT）技术知识点。
简析OpenHarmony软总线能力
maniuT的博客
04-12 1004
在 OpenHarmony 的源码里和系统功能相关的部分大多都放在 foundation 这个文件夹里，而通讯相关的部分则是在 communication 这个文件夹内。├── adapter //适配层│ ├── common //适配层管理，网络适配，协议适配等│ └── default_config //适配层配置├── components //依赖组件│ ├── mbedtls //开源ssl库，在三方库里。
HarmonyOS核心能力 | 关于分布式软总线
HarmonyOS技术社区
12-28 6113
HarmonyOS核心能力之一分布式软总线让多设备融合为“一个设备“，带来设备内和设备间高吞吐、低时延、高可靠的流畅连接体验。本文将详细地讲解分布式软总线、探讨鸿蒙分布式软总线子系统，其中技术专家郑凯带来的分布式软总线的技术解读将给大家开发跨应用之痛带来全新解决思路。 HarmonyOS最核心的“分布式软总线”技术解读 华为鸿蒙OS尖刀武器之分布式软总线技术 鸿蒙子系统解读-分布式软总线子系统初步研究（上） 鸿蒙子系统解读-分布式软总线子系统初步研究（下） ...
华为鸿蒙OS尖刀武器之分布式软总线技术
热门推荐
华科硕士，大厂打工中。编程问题咨询，请私我
10-11 1万+
目录 1 没有人能够熄灭满天星光 2 必须得补的传统总线知识 3 什么是分布式软总线？ 4 分布式软总线功能和原理 4.1 分布式软总线的架构 4.2 软总线之发现连接：从手动发现，进化成自发现 4.3 软总线组网关键技术-异构网络组网 4.4 软总线之传输 5 畅享未来，鸿蒙系统使能智慧生活 1 没有人能够熄灭满天星光 华为开发者大会2020在广东东莞松山湖欧洲小镇举办，在主题演讲环节中，华为消费者业务总裁余承东宣布“鸿蒙”系统升级到2.0版本(HarmonyOS 2.0)，余总表示
SOA架构解析：JBOSSESB企业服务器总线在分布式系统中的应用
JBOSSESB（Java Business Open Source Enterprise Service Bus）是JBoss企业服务器的一部分，它实现了SOA的关键组件——企业服务总线（ESB）。ESB作为中间件，负责连接和协调不同系统之间的通信，使得服务间的交互...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

国家一级假勤奋研究牲

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值