venus-market or worker 订单远程传输问题改进建议

[litai686]

模块 / Components

• venus-sector-manager
• venus-worker
• 工具链 / toolchains
• 文档 / docs

描述 / Description

maket远程发单有个问题，接单传输过程中断的概率很大，每次renew后，它不支持断点续传….. 又要重新传，这样很容易造成超时…. ，建议传输改成断点续传，保证接单的稳定性

[dtynn]

想确认一下，这里提到的“中断”及“续传”，是发生在 venus-worker 封装 / 升级 过程中的 AddPiece 阶段，从 venus-market 下载 piece 数据填充到空白扇区中的么？

需要说明的是，基于 http 传输的 “断点续传“ 是一个需要服务端支持的能力。

[litai686]

@dtynn 从 venus-market 下载 piece 数据填充到空白扇区中的过程，中断概率有点高，尤其是并发几个同时下载的时候， 我没看源码不太懂venus-market和worker传输之间的具体业务， 我理解的是真正数据在maket端导入后，把piece传到worker，这个过程应该是做成断点续传，这两端如果是基于http传输，做断点续传更简单了，如果是libp2p，自己设计一下通过probuff来传效率应该也不低

[dtynn]

如你所描述，无论哪种方式，都首先需要服务端支持

[litai686]

我看 venus-market 就是服务端，提供一个wss 服务，worker应该只是一个客户端，这个是中断后的错误日志

[dtynn]

所以，你的建议很好，但这并不是一个很简单就能完成的工作，具体体现在：

• 任何断点续传方案都需要服务端和客户端同时支持
• AddPiece 过程中， Piece 数据并不是拿来就使用，需要进行padding 和 Fr32 encoding。这个过程使得续传并不像你想象的那样，数据 byte - byte 接上就能直接使用。

上述方案不会是一个短期内可以完成的方案，此时改善网络条件可能是更直接的方式。
当然，如果社区参与者能够就此issue 提出完善的 pr， 我们也非常乐意接受

毕竟，如果网络始终有问题，即使支持断点续传，也会变成一个冗长且令人抓狂的过程。

[litai686]

我看现在的业务是worker 一边接收数据一边做AddPiece，如果说先把数据下载下来，再做addpiece可能出错的概率会小很多，下载文件的过程通过wss协议做断点续传，不知道可行性怎么样？

[dtynn]

增加更复杂的协调机制（外部下载任务决定本地封装任务的启动时机）当然可能有助于改善体验。
但是这些”软手段“都无法解决”硬问题“，即网络本身的问题。
无论是将 http response body 视为数据流直接使用，还是下载到本地再使用，核心问题都是网络传输的稳定性和可靠性。

[litai686]

网络传输的稳定性确实不可控，但文件传输的完整性和效率是可以通过业务代码实现。目前的问题是首先保证文件从maket到worker传输的完整性和效率问题，断点续传也正是解决这个问题。
当完整的文件传输到本地后，进入封装的过程，那是另一套业务的逻辑，addpiece这套业务，我认为目前已经是很稳定了。

[dtynn]

当然当然。
这里只想指出：

1. 用于异常处理的逻辑和机制通常是用来应对低频率的偶发事件。如果一种情况变得频繁，我们恐怕无法通过仅盯着其中某一个点来解决问题。
2. 我们目前有其他优先级更高的任务，暂时无意立刻打破一套比较稳定的逻辑，去增加更多逻辑，仅为解决弱网条件下的piece数据传输问题。如你所知，基于 http 的传输本来也是一个相对稳定的事情。

[litai686]

理解，理论上maket跟worker应该是在一个局域网，这样就不会出现目前的问题了，主要是因为目前我们有些节点加入了venus的加速器，造成maket在远程发单，经过沟通，也可以自己本地跑maket，datacap消息签名由主办方发送，这样就暂时可以解决远程传输不稳定的问题。

[dtynn]

理解，从整个 venus 及 venus 相关的推广项目来说，我们也会考虑：

• 增加用于 piece 数据传输的 CDN 节点，尤其是面向特定区域的 CDN 节点
• 提供相对稳定的中转线路

等有助于提升传输可靠性和效率的方案。

@Fatman13

[Fatman13]

这个合之前的 #208 有关系吗？如果是下载下来再进行计算cid处理的话？

[dtynn]

@Fatman13 没有关系，at 你是因为跟 venus 的服务部署有关，可能需要记录一下

[dtynn]

resolved by #358 & #361