问题背景： 两台公版GK6320板子,在同一局域网下进行分布式图库连接功能的时候，必现连接失败现象。   定位过程&根因分析： 从日志分析来看，是OpenP2PConnection failed 了。 初步怀疑是软总线建链这边失败了导致连接失败。查看代码，发现分布式图库在连接时会先触发设备上线流程，然后这里会直接返回成功，软总线去异步创建连接。dfs这里的流程会继续正常往下走。

  问题背景： 文件互传功能从统一互联移植到Gk6780dev分支后，传输功能基本ok，但出现开机后第一次分享图片成功，第二次传输在输入完PIN码后必现传输失败，后面继续图片分享均失败，关机重启可恢复，但仅限于第一次传输成功，后续传输必现失败。   定位过程&根因分析： 从应用分析来看，显示第二次传输在连接后，应用在等待对端的消息等待15s，未等到随后应用走了传输失败流

在软总线中有发现、连接、组网、传输四大模块。其中发现作为整个业务的第一步，核心目标即发现周边的设备。只有发现了设备，才能组成分布式网格，进而在此基础上实现分布式业务。根据底层使用的媒介，发现分为两大类：基于局域网络的Coap发现和基于蓝牙的BLE发现。 OH-BLE发现设备流程 BLE发现流程，主要通过蓝牙BLE广播发送ADV_IND消息完成同被发现设备的交互。支持通过SCAN_REQ进一步获取

1、开机启动软总线 代码路径：foundation/communication/dsoftbus/core/frame/standard/init/src/softbus_server.cpp void SoftBusServer::OnStart() { COMM_LOGI(COMM_SVC, "SoftBusServer OnStart called!"); Ini

分布式设备认证流程如下图所示 JSAPP 调用DM模块NAPI提供的认证接口，DM内部调用软总线的接口同另一台设备进行交互，交互完成后，通过设备认证模块进行互信认证，认证通过后，将认证结果通过NAPI 机制通知JSAPP。 分布式设备管理设备认证流程详见附件

设备发现的流程流程如下图所示 JSAPP 调用DM模块NAPI提供的发现接口，并设置对应的监听方法，DM内部去调用软总线的发现接口启动发现，发现局域网的设备后，软总线通知DM，DM 再通过NAPI 机制通知JSAPP。 分布式设备管理发现设备流程详见附件

1：系统SA开机启动 ipc_server_stub.cpp SystemAbility (DISTRIBUTED_HARDWARE_DEVICEMANAGER_SA_ID 4802) 开机启动，生命周期 OnStart方法中初始化DM模快，并添加SOFTBUS_SERVER_SA_ID启动监听，在softbus 服务启动后，DM 模块初始化软总线模块的上下线监听。 代码位置：ipc_serve

DeviceManager组件在OpenHarmony上提供账号无关的分布式设备的认证组网能力，并为开发者提供了一套用于分布式设备间监听、发现和认证的接口。 其组成及依赖如下所示： 目录 foundation/distributedhardware/distributedhardware_device_manager ├── common # 公共能力头文件存放目录 │ ├── inclu

背景 随着生活场景的智能化，我们对周边设备之间的互联提出了更高的要求，但是不同的设备使用的通信技术也有所不同，例如WLAN、蓝牙、NFC、LoRa等等，同时不同技术使用的频段、通信协议有所不同，导致这些设备无法直接通信，甚至在一定情况下会发生相互冲突。比如我们在使用电子设备的时，想要多个设备之间想要共享数据，发现会非常麻烦。比方说两个手机发送文件，需要连接网络，需要登录app，需要选择文件

一、背景简介 1、分布式软总线是什么 分布式软总线是openharmony中系统服务层一个重要的子系统。 分布式软总线是Openharmony社区开源的分布式设备通信基座，为设备之间的互联互通提供了统一的分布式通信能力，为设备之间的无感发现，零等待传输和高效任务分发创造了条件。 Openharmony主要面向强交互等需求的智能终端、物联网终端和工业终端。通过以分布式