Node.js `dat`协议能否有效地支持视频直播？

我希望能够通过

dat

实时播放视频（或任何其他大的、不断修改/附加的文件）

上面说,

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

但是，它还说，

dat

使用拉宾指纹技术创建确定的文件块，因此推测dat客户端将能够轻松识别其已通过散列下载的文件块，因此应该只能下载文件的最新最后一块，如果这是唯一改变的部分

它还说：

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

有，但从我对其工作原理的初步理解来看，它似乎保存了自己的“bundle.js”文件用于视频数据，我不确定它是如何实现流式传输的，但这与我试图实现的并不完全相同，即能够高效地流式传输任意大且扩展的文件，例如.ts或.mkv视频流

---

因此，我的问题是-高效的视频直播（即不重新下载已下载的块）是目前不受支持的，将来可以添加的，还是使用

dat

协议无法实现的，Dat构建在其之上的低级hypercore协议应该可以很好地用于视频和其他“软实时”流媒体应用。然而，Dat（应用程序）构建的超硬盘文件/目录抽象目前无法很好地用于这些用例。没有任何东西可以阻止hyperdrive在处理单个“任意大且正在扩展的文件”时正常工作，但它尚未针对特定的用例进行优化

---

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

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

---

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

这令人失望。。。如果能够将

dat

与现有的视频编码器结合起来，以一种透明的方式进行直播，那就太好了。谢谢你的详细解释。您是否介意扩展“注意，可能存在或可能不存在到现有文件格式或流协议的直接映射”部分？我的意思是，可能存在具有“自然”分块（例如，在每个关键帧）的视频格式或容器，或者具有自然分帧或分块的协议，可以很容易地映射到超核心块。这超出了我的知识范围。hypercore上的视频引起了很多人的兴趣；AFAIK这是当前用于此用例的dweb协议中最好的协议之一，因此可能值得在IRC上做更多的研究或询问。再次感谢。就我个人而言，我不认为分块这件事会是一个大问题，因为它听起来像块通常在16kb的顺序无论如何。所以，即使有一些延迟-它只落后16kb。。。更大的问题是让它工作，而不必每次都重新下载整个文件！我很高兴听到有人对这个用例感兴趣。我发现了一个链接，明确地说拉宾指纹已经被禁用