2

我希望能够通过dat.

这里说，

dat:// 协议不支持文件级别的部分更新，这意味着在单个文件中有多个记录，每次用户添加记录时，任何关注该用户的人都必须同步并重新下载整个文件。随着文件的不断增长，性能会下降。将每条记录放在单独的文件中效率更高：创建记录时，网络中的对等方将只下载新创建的文件。

但是，这里也说使用Rabindat指纹识别来创建确定性的文件块，因此大概 dat 客户端将能够通过其哈希轻松识别它已经下载的块，因此应该只能下载最新的最终文件文件的块，如果这是唯一改变的部分。

在常见问题解答中，它还说：

Dat 使用的 Merkle 树类型允许对等方比较他们各自拥有的数据集的特定版本的哪些部分，并有效地交换增量以完成完全同步。

有hypervision，但从我对其工作原理的初步了解来看，它看起来像是为视频数据保存了自己的“bundle.js”文件，我不确定它是如何实现流式传输的，但这与我想要实现的目标是能够有效地流式传输任意大且扩展的文件，例如 .ts 或 .mkv 视频流。

所以，我的问题是 - 是有效的视频实时流式传输（即无需重新下载已经下载的块）目前根本不支持并且可以在将来添加的东西，还是使用该dat协议本质上无法实现的东西？

4

1 回答 1

2

简而言之，Dat 所基于的低级超核协议应该适用于视频和其他“软实时”流媒体使用。但是，Dat（应用程序）构建的超光速文件/目录抽象目前不适用于这些用例。没有什么可以阻止超空间驱动器与单个“任意大且扩展的文件”一起正常工作，但它尚未针对该特定用例进行优化。

据我所知，当前所有的视频流原型都是通过将视频内容直接编码到超核中来工作的，而不是在超驱动“文件和目录”抽象中。这有点像将原始字节写入硬盘而不是使用文件系统之间的区别。P2P 视频和音频流是超核的明确设计目标。请注意，可能有也可能没有到现有文件格式或流协议的直接映射；超核抽象以字节块流的形式呈现，每个字节块的上限约为 1 兆字节。

作为一个小细节，dat/hypercore协议和磁盘格式没有指定任何特定的“分块”机制。Rabin-chunking 已经过实验，但默认情况下，几乎所有客户端都使用固定大小的分块来简单和快速（这并不意味着将来不可能实现对性能位置敏感的分块）。理论上，客户端在任何情况下都能够检测到重复的块并避免重新下载（以及磁盘上的重复存储），但截至 2018 年夏季，此优化尚未实施。

Hyperdrive 当前要求将所有文件作为连续块存储在“内容”超核心提要中。这是非常高效的，但使重复数据删除变得困难。作为一种特殊情况，应该可以支持追加到最新文件（直接追加到内容提要）而不复制整个文件。任何时候更新或创建提要中的任何其他文件，都会破坏连续块，但对于您的用例来说，它可能已经足够好了（如果要实施此优化）。

于 2018-07-31T00:58:34.623 回答