webrtc - 为什么像 Pusher 这样的解决方案声称是 "Real time"？

Question

我已经使用 Pusher 一段时间了。我一直认为“实时”意味着“瞬时”。最近我进入了这篇文章:https://en.wikipedia.org/wiki/Real-time_computing ，还有一句话引起了我的注意:

"Real-time programs must guarantee response within specified time constraints"

他们给出了一个基于音频处理的例子:

"Consider an audio DSP example; if a process requires 2.01 seconds to analyze, synthesize, or process 2.00 seconds of sound, it is not real-time. However, if it takes 1.99 seconds, it is or can be made into a real-time DSP process."

我的问题:1. 这个定义仅适用于硬件/电子设备还是也可以适用于软件？2. 如果适用于软件，是否适用于 Pusher 等远程服务？3. 推送器被视为“实时”的时间限制是多少？4. WebRTC、Firebase 等其他服务的时间限制是多少？

Answer 1

抱歉，这篇冗长的文章没有具体回答您的问题，但我希望它能让您更好地理解“实时”定义的来源。

<小时/>

是的，“实时”意味着“瞬时”，这是一种可以理解的混淆。但如果你真正开始思考，你很快就会发现“瞬时”很难定义。

瞬时是什么意思？从命令时间到响应时间的 0(零)秒响应时间(如 0 秒 0 ms 0 ns 0 ps)在物理上是不可能的。然后我们可以尝试说瞬时意味着命令响应时间是瞬时感知的，即它不会被视为延迟。但是……“瞬间感知”到底是什么意思呢？被人类感知？好吧，那很好，我们正在取得进展。人眼和大脑图像处理是一个非常非常复杂的机器，它并不是简单地以 fps 工作，但我们可以使用数据来近似一些。人眼可以“感知屏幕上闪烁的 1/250 秒的图像”。这将是 0.004 秒或 250 fps。因此，通过这种近似，如果图形程序的响应时间 < 0.004 秒或运行速度快于@250 fps，则该图形程序将是实时的。但我们知道，在实践中，大多数人在 60 fps(即 0.01666 秒)下就可以感受到游戏的流畅。所以现在我们有两个不同的答案。我们能以某种方式证明它们都是合理的吗？是的。我们可以说，理论上实时意味着 0.004 秒，但实际上 0.01666 秒就足够了。

我们可以很高兴就此止步，但我们正踏上探索之旅。所以让我们进一步思考。您想要一个具有 0.01666 秒响应时间的“实时”航空电子自动化系统吗？您认为“实时”核电站系统0.01666秒的响应时间可以接受吗？如果命令完成时间为 0.0166 秒，则阀门实际需要 15 秒才能关闭的油控系统是否会被定义为“实时”？所有这些问题的答案绝对是否定的。为什么？回答这个问题，你就回答了为什么“实时”被定义为:“实时程序必须保证在指定的时间限制内响应”。

抱歉，我对“Pusher”一点也不熟悉，但我可以回答你的第一个问题和第二个问题的一部分:“实时”可以应用于任何需要“ react ”或响应的系统某种形式的输入。这里的“系统”比你想象的更通用。大脑就符合条件，但在工程背景下意味着整个堆栈:硬件+软件。