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

已于 2023-05-11 14:14:44 修改
阅读量394 收藏 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通信机制的全部内容到此结束！

国家一级假勤奋研究牲
关注
  • 1
    点赞
  • 踩
  • 7
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
HarmonyOS之分布式软总线
LinkEverything的博客
12-25 1万+
HarmonyOS的亮点之一是分布式软总线。什么是分布式软总线？为什么要提出分布式软总线？在这里我们对它做简要的介绍。
鸿蒙实战开发：【分布式软总线组件】
2301_76813281的博客
03-15 1634
现实中多设备间通信方式多种多样(WIFI、蓝牙等)，不同的通信方式使用差异大，导致通信问题多；同时还面临设备间通信链路的融合共享和冲突无法处理等挑战。发现连接：提供基于Wifi、蓝牙等通信方式的设备发现连接能力。设备组网：提供统一的设备组网和拓扑管理能力，为数据传输提供已组网设备信息。数据传输：提供数据传输通道，支持消息、字节、流、文件的数据传输能力。业务方通过使用分布式软总线提供的API实现设备间的高速通信，不用关心通信细节，进而实现业务平台的高效部署与运行能力。
OpenHarmony 实战开发——分布式软总线
最新发布
m0_70748458的博客
05-13 756
在 OpenHarmony 的源码里和系统功能相关的部分大多都放在 foundation 这个文件夹里，而通讯相关的部分则是在 communication 这个文件夹内。├── adapter //适配层│ ├── common //适配层管理，网络适配，协议适配等│ └── default_config //适配层配置├── components //依赖组件│ ├── mbedtls //开源ssl库，在三方库里。
HarmonyOS最核心的“分布式软总线”技术解读
HarmonyOS技术社区
12-24 9264
文章来源 | HarmonyOS开发者公众平台 什么是分布式软总线呢？ 分布式软总线是HarmonyOS架构中最底层的技术 分布式软总线是HarmonyOS的大动脉 开发跨端应用，开发者们是否面临以下挑战： 1.跨端操作需要每次重复建立连接 2.近场通信方式（蓝牙，WiFi，UWB等）必须感知才能实现连接 3.无线环境必须建立标准的用于服务器的协议栈 4.不同物理层无法实现统一的开发体验 针对这些开发者的开发之痛，技术专家郑凯带来的分布式软总线的技术解读将给大家带来全新解决..
鸿蒙源码分析（十三）
安辰的博客
08-05 1700
软总线模块中trans_service目录分析总结 本文主要总结软总线模块下trans_service目录中个文件的作用和功能，宏观上把握trans_service在鸿蒙系统中发挥的作用。 一、分布式软总线介绍 1.1 总线 总线（Bus）是一个非常广泛的概念，在传统计算机硬件体系中应用的非常广泛。它是一种内部结构，是cpu、内存、输入、输出设备传递信息的公用通道，主机的各个部件通过总线相连接，外部设备通过相应的接口电路再与总线相连接，从而形成了计算机硬件系统。在计算机系统中，各个部件之间传送信息的公共通路
OpenHarmony 4.0 分布式软总线解析：设备发现与传输
maniuT的博客
04-10 1519
OpenHarmony 的分布式软总线子系统为 OpenHarmony 系统提供的通信相关的能力，包括：WLAN 服务能力、蓝牙服务能力、软总线、进程间通信 RPC（Remote Procedure Call）等通信能力。下面我们通过阅读 OpenHarmony 4.0 的源码，来解读一下 OpenHarmony 软总线当前的一个实现情况。
基于CAN总线的分布式电火花线切割控制系统.pdf
08-08
针对这些问题，一种新的解决方案——基于CAN总线的分布式控制系统应运而生。 CAN（Controller Area Network）总线是一种高效、可靠的串行通信网络，最初应用于汽车电子系统，因其独特的技术和性价比优势，现已广泛...
基于CAN总线的分布式电池管理系统
10-23
随着高科技及其产业的迅速发展，大存储容量的电池组能源系统已经越来越被人们所重视，在很多领域中都得到广泛地应用，如在汽车产业发展的新方向、新热点——电动汽车及混合动力车的研究及产业化中，将作为车载能源的...
SpringCloud——消息总线（Bus）
09-18
SpringCloud——消息总线（Bus）之Spring Cloud Bus将分布式系统的节点与轻量级消息代理链接。
基于CAN总线的电动汽车分布式控制系统研究.pdf
09-04
《基于CAN总线的电动汽车分布式控制系统研究》这篇文章深入探讨了现代电动汽车中的一种关键技术——基于CAN（Controller Area Network）总线的分布式控制系统。随着汽车电子化程度的加深，传统的故障检测手段已经...
CAN总线研究及应用
08-05
CAN总线控制器局部网（CAN-Controller Area Network）属于现场总线的范畴，支持分布式控制或实时控制。 二、CAN总线控制器的硬件构成 CAN控制器的硬件构成包括控制寄存器、命令寄存器、状态寄存器、中断寄存器、...
软考复习文档12.docx
05-08
海明校验则通过分布式冗余位来检测和纠正错误，了解它们的计算方法和应用场景对于保证数据传输的准确性至关重要。 这份复习文档全面覆盖了软件设计师考试的关键知识点，深入学习这些内容，将有助于考生在考试中取得...
ESB-Enterprise Service Bus企业服务总线.ppt
06-20
**ESB——企业服务总线** 企业服务总线（Enterprise Service Bus，ESB）是现代企业级集成解决方案的核心，它旨在解决不同应用系统间的通信问题，实现服务的解耦和互操作性。ESB概念起源于传统中间件技术与XML、Web...
分布式测控技术在空气透平试验台中的应用.pdf
08-11
本文主要探讨了分布式测控技术在大型、复杂试验设备——空气透平试验台中的具体应用，以及其带来的优势。 首先，空气透平试验台是一个涉及多个不同功能系统的大型试验设施。为了确保试验的顺利进行，各系统之间需要...
SOA实践指南-分布式系统设计的艺术.pdf
05-09
第5章：企业服务总线 　5.1　esb职责 　5.2　异质的esb 　5.3　esb的差异 　5.4　esb增值服务 　5.5　总结 第6章：服务分类 　6.1　基础服务分类 　6.2　基本服务 　6.3　组合服务 　6.4　流程服务 　6.5　其他服务...
SpringCloudMultiModule:SpringCloud快速构建微服务springCloud为开发人员提供了快速扩展分布式系统的一些工具，包括配置管理，服务发现，断路器，路由，微代理，事件总线，交错锁，决策，分散会话等等，下面进行个服务分部构建原始码与测试案例，此项目初于学习迭代商有待深入了解！
03-24
SpringCloud快速构建微服务springCloud为开发人员提供了快速扩展分布式系统的一些工具，包括配置管理，服务发现，断路器，路由，微代理，事件总线，交错锁，决策，分散会话等等，下面进行个服务分部构建原始码与测试...
HarmonyOS核心能力 | 关于分布式软总线
HarmonyOS技术社区
12-28 6000
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)，余总表示
OpenHarmony源码分析之分布式软总线：trans_service模块(6)/TCP会话管理
weixin_46669761的博客
05-28 507
一、概述 trans_service模块基于系统内核提供的socket通信，向authmanager模块提供设备认证通道管理和设备认证数据的传输；向业务模块提供session管理和基于session的数据收发功能，并且通过GCM模块的加密功能提供收发报文的加解密保护。 本文是分布式软总线的会话管理机制的结尾部分，在前文中介绍了新会话中客户端请求数据的处理过程，本文重点介绍普通会话中的新数据处理。衔接OpenHarmony源码分析之分布式软总线：trans_service模块(5)/TCP会话管理。 二、源码
分布式软总线是什么？
02-24
分布式软总线是一种用于连接分布式系统各个节点的通信协议和架构。它通过在节点之间传输数据和控制信息，实现节点之间的通信和协作。分布式软总线的设计目标是提供高效、可靠、实时的通信机制，以支持分布式系统中的数据交换和协同处理。 分布式软总线通常由以下几个组成部分构成： 1. 总线协议：定义了节点之间的通信规则和数据格式。常见的总线协议有CAN（Controller Area Network）、Ethernet/IP、PROFINET等。 2. 总线网络：用于连接各个节点的物理媒介，可以是电缆、光纤等。总线网络提供了节点之间传输数据和控制信息的通道。 3. 节点：分布式系统中的各个设备或模块，通过总线网络连接在一起。每个节点都有一个唯一的标识符，用于在总线上进行通信。 4. 总线管理器：负责管理总线上的通信和数据传输。总线管理器可以控制节点之间的数据交换、节点的加入和退出等操作。 分布式软总线的优点包括灵活性、可扩展性和可靠性。它可以支持大规模系统的构建，并且能够适应系统的变化和扩展。同时，分布式软总线还可以提供实时性能和容错机制，以确保系统的可靠性和稳定性。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

国家一级假勤奋研究牲

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

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

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

打赏作者

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

抵扣说明：

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

余额充值