search

BioforestChain / dweb_browser

BioforestChain Infrastructure
https://docs.dweb-browser.org
MIT License
13 stars 4 forks source link

【提案】✨ ipc 协议升级 => ipcPool #46

Closed Gaubee closed 4 months ago

Gaubee commented 11 months ago

详见 desktop-dev/Readme.md

  1. ✨ 增加握手，使用 UTF8 文本进行握手（这是兼容性最广的标准，因为基本现代化所有编程语言一定会支持 UTF8 字符串）、

    需要在握手的过程中解决协议支持的 可以在握手里协商默认的 IpcBody 行为，现在默认是 Paused 状态，可以协商为默认为 Pulled 的状态，这对网络模块这种一定会进行数据转发的会比较友好

  2. ✨ 加入 cbor 的支持，在原生上会有更好的编码性能和效率，在 js 侧可以省去？
  3. ✨ 加入 createChannel 的支持，用于替代大多数场景下使用 ReadableStreamIPC
    1. ✨ ReadableStreamIpc 需要改变格式（现在时 len+body），避免阻塞（改成 channelId+len+body）
  4. ✨ 新增 IpcError，提供原生的错误支持
kingsword09 commented 8 months ago

✨ 加入 cbor 的支持，在原生上会有更好的编码性能和效率，在 js 侧可以省去？

  1. js的cbor-x和kotlin的kotlinx.serialization的cbor序列化反序列化使用的是同一个标准，可以直接使用；
  2. 安卓dwebview的MessageChannel的port已经修改为androidx.webkit.WebMessagePortCompat，支持传输ByteArray。
Gaubee commented 8 months ago

任何环境下抽象出来的ipcPool底层的消息通道我们统一称为 endpoint（端点）； 任何形式的端点都需要支持反压，如果不支持那么就在协议上进行软支持，同时要确保性能。

比如说MessageChannel本身并不支持反压，它底层的设计是一个UnlimitChannel，那么我们就需要构建一些特殊的信号来模拟反压； 这里建议用 双MessageChannel 来实现，一个用来传输数据，一个用来传输控制信号；就在握手阶段完成构建与连接。

双通道的在kotlin这里可以使用 select-on-send 来改进写法

Gaubee commented 8 months ago
  1. 安卓dwebview的MessageChannel的port已经修改为androidx.webkit.WebMessagePortCompat，支持传输ByteArray。

ByteArray的支持需要进一步严谨的测试，包括兼容性测试和性能测试两部分

waterbang commented 7 months ago

任何环境下抽象出来的ipcPool底层的消息通道我们统一称为 endpoint（端点）； 任何形式的端点都需要支持反压，如果不支持那么就在协议上进行软支持，同时要确保性能。

比如说MessageChannel本身并不支持反压，它底层的设计是一个UnlimitChannel，那么我们就需要构建一些特殊的信号来模拟反压； 这里建议用 双MessageChannel 来实现，一个用来传输数据，一个用来传输控制信号；就在握手阶段完成构建与连接。

双通道的在kotlin这里可以使用 select-on-send 来改进写法

双通道的构建对于开发者可能是负担，因为使用create的时候，还需要传递两个通道（channel,messageChanel,ByteChannel）,因此想根据上述所说通过select-on-send 来复用通道进行(close/pause/ping/pong) 等信号发送，但是这样没有对数据和信号进行区分，可能也不是好的方案。

或者是IpcPool.create 创建消息通道之后，再通过fork 创建信号通道。

Gaubee commented 7 months ago

任何环境下抽象出来的ipcPool底层的消息通道我们统一称为 endpoint（端点）； 任何形式的端点都需要支持反压，如果不支持那么就在协议上进行软支持，同时要确保性能。 比如说MessageChannel本身并不支持反压，它底层的设计是一个UnlimitChannel，那么我们就需要构建一些特殊的信号来模拟反压； 这里建议用 双MessageChannel 来实现，一个用来传输数据，一个用来传输控制信号；就在握手阶段完成构建与连接。 双通道的在kotlin这里可以使用 select-on-send 来改进写法

双通道的构建对于开发者可能是负担，因为使用create的时候，还需要传递两个通道（channel,messageChanel,ByteChannel）,因此想根据上述所说通过select-on-send 来复用通道进行(close/pause/ping/pong) 等信号发送，但是这样没有对数据和信号进行区分，可能也不是好的方案。

或者是IpcPool.create 创建消息通道之后，再通过fork 创建信号通道。

fork出来的IPC是不透明的，endpoint只确保它的消息能到，但不能确保它的消息什么时候到。 因此控制信号必须在底层endpoint这里解决。 这是一个一劳永逸的方案，在endpoint这里抽象地解决掉这个问题已经是心智负担最低的方案了。

waterbang commented 5 months ago

设计两种通信模式：一种安全的通信和一种不安全的通信类型TCP和UDP

ipc-tcp

  1. 每条消息都会被对方确认
  2. 消息丢失将会使用快重传机制（A向B发消息，B没收到，快速向A发3条消息）

ipc-udp

  1. 消息不用被对方确认，消息可能出现丢失，但是传输速度快，适用视频流。

安全问题

  1. 节点之间需要内置异常监听模块，对异常的数据包进行监控，防止一些网络层的DOS.
  2. 设置一些抽查信号，确认消息是否由对方发送，而不是转发的垃圾消息。
waterbang commented 4 months ago

close of 83e0fbc0c1e01bc88a7790560d24f50adfa42022