鸿蒙所谓的软总线，套娃DLNA SOMEIP协议，QNX系统

junwua

已于 2024-03-09 15:58:39 修改

阅读量4.8k

点赞数 8

分类专栏： OpenHarmony 文章标签： harmonyos 网络网络协议

于 2022-12-09 09:50:19 首次发布

本文链接：https://blog.csdn.net/junwua/article/details/128247482

版权

OpenHarmony 专栏收录该内容

4 篇文章 2 订阅

订阅专栏

一、开源鸿蒙官网资料

分布式软总线组件

简介

由于设备通信方式多种多样(WIFI、蓝牙等)，不同通信方式使用差异大，问题多。同时通信链路的融合共享和冲突无法处理。分布式软总线实现近场设备间统一的分布式通信能力管理，提供不区分链路的设备发现连接、组网和传输能力，主要包括如下：

发现连接：提供基于Wifi、蓝牙等通信方式的设备发现连接能力。
设备组网：提供统一的设备组网和拓扑管理能力，为数据传输提供已组网设备信息。
数据传输：提供数据传输通道，支持消息、字节数据传输等能力。

业务方通过使用分布式软总线提供的API实现设备间高速通信，不用关心通信细节，进而实现业务平台部署与运行能力。

这样归一化？？

二、鸿蒙概念忽悠

疑问：

1. 设备间统一的分布式通信能

简单的来说，就是 A设备和B设备，具备对等的COAP协议层，才能通讯。

很简单的问题，原来设备的BT协议，WIFI 协议并不会因为COAP协议的引进，而且消失。鸿蒙做的不过是简单的封装层的工作，而且非常致命的是，前提需要 局域网，更简单的理解是，这只不过是华为自家手机和IOT设备的私有协议而已，取了个名字，小米手机和小米生态，也一样的有这样的协议，也不比鸿蒙差。

BT的连接和配对，Wifi的接入，不会因为有所谓的软总线，而不需要调用，那么疑问软总线如何封装BT，WIFI的常规操作协议呢，从COAP代码看，根本没有这些，他们只是本身的类似UDP/TCP网络协议层一样，不涉及任何底层，所以其实调用所谓的API，我认为根本不可能实现BT WIFI的连接功能，所谓的发现功能，比简单的BT扫描要好？或者这本身就不是一个技术问题，封装层的目的一般是接口标准化，也许这个就是剩下唯一的点。

那么问题是：当一个BT设备时，为了搞这个协议，前提是要联网，就算是局域网，否则，连门都进不去，那这样到底有什么意义，实在是费解！BT有自己的mesh组网协议，都是标准的体系，用的好好的。而你所谓的软总线不过是包装在上面一层而已。增加了协议的开支，效率降低。

2. 发起组网请求，携带组网连接地址信息，并且提供组网执行结果回调函数。

等待组网结果，JoinLNN()返回成功表示软总线接受了组网请求，组网结果通过回调函数通知业务；组网回调函数中addr参数内容和JoinLNN()的入参互相匹配；retCode如果为0，表示组网成功，此时networkId为有效值，后续传输、退网等接口均需使用该参数；retCode如果不为0，表示组网失败，此时networkId为无效值。

使用传输相关接口进行数据传输。

发送退网请求，携带组网成功后返回的networkId，并且提供退网执行结果回调。

三、真假软总线

另外如果一切其他的 IOT设备集成了COAP，而且还要加入华为的 Hilink，给华为做生态，意义何在呢？如果在开源鸿蒙下，主的设备在哪里，是否各厂商会加入自己的限制，不会兼容所有的其他IOT设备，必有自己的私有协议。

DLNA协议中的UPnP协议，看一下，是否设计理念很相似，几乎一样

类似的SOME/IP 服务说明，其实所谓的软总线本质上只是一个网络中间件

服务是SOME/IP的最核心概念。在一个服务中，定义了Server和Client两个角色：Server提供服务，Client调用服务。对于同一个服务，只能存在一个Server，但可以同时存在多个Client调用服务。一个Service由0~多个Event/Method/Field组成。与CAN相比，面向服务的通讯方式能够大大降低总线的负载率。

2.1 Method

调用或引用一个进程/函数/子程序，通常由Client发起，并由Server答复。Request是最常见的一种Method，由Client向Server请求数据；Response是Request的结果，由Server答复Client的Request。而Method Fire & Forget方式，只Client向Server发起，但Server对该请求不回复。

2.2 Event

一个单向的数据传输，只能是on change类型，用于Server主动向订阅（Subscribe）了相关服务的Client发布（Publish）信息。

2.3 Field

由以下三项内容构成：

Notifier：通知，Server的Client订阅了服务后第一时间主动向其发送数据。

Getter：获取，由Client向Server请求数据。

Setter：设置，由Client修改Server的数据。

4. SOME/IP 服务发现SD

由于服务需要由Server和Client共同完成，因此在进行正常的数据传输之前，需要一系列的准备工作确认Server和Client之间是否已有网络连接。之后，Client还要询问Server能否提供所需的服务，并对服务的Event进行订阅。这些工作都是通过SOME/IP服务发现（Service Discovery）实现的。

SOME/IP服务发现用于定位服务实例、检查服务是否可用以及部署发布和订阅句柄。服务发现只能通过UDP实现。

原来，鸿蒙是把DLNA的概念抄过来，换个名字，连限制条件都一样。

各位怎么看呢，现在都流行吹牛不负责，哈哈