我一直在使用Pusher一段时间。我一直认为“实时”意味着“瞬间”。最近我踏进这篇文章：https://en.wikipedia.org/wiki/Real-time_computing和句子抢了我的注意：为什么像推杆这样的解决方案声称是“实时”？
“实时程序必须保证规定的时间内响应 约束”
他们举一个例子基于音频处理：
“考虑一个音频DSP示例;如果一个过程需要2.01秒到 分析，合成，或处理声音2.00秒，它不是 实时。但是，如果它需要1.99秒，它或可制成 成实时DSP处理“
我的问题：1， 这个定义只适用于硬件/电子设备或可应用于软件是否也适用？ 2.如果适用于软件，它是否适用于远程服务，如Pusher？ 3.什么时间限制推杆被视为“实时”？ 4.什么是其他服务的时间限制WebRTC，Firebase？
对不起，您的问题没有具体回答，但我希望它会让您更好estand“实时”定义的来源。
是的，这是一个可以理解的混淆，“实时”是指“瞬时”。但如果你真的开始考虑这个问题，你很快就会发现“瞬间”很难定义。
瞬时意味着什么？从命令时间到响应时间的0（零）秒响应时间（如0秒0毫秒0纳秒0 ps）在物理上是不可能的。然后，我们可以试着说，瞬时意味着命令响应时间被瞬间感知，即它不会被视为延迟。但是......那“瞬间感知”到底意味着什么？被人类感知？好吧，那很好，我们正在某个地方。人眼和大脑图像处理是一个非常复杂的机器，它并不真正简单地用fps工作，但我们可以使用数据来近似一些。人眼可以“感知屏幕上闪烁的图像1/2秒”。这将是0.004秒或250帧/秒。所以通过这个近似值，如果图形程序的响应时间为< 0.004秒，或者比@ 250帧/秒运行得更快，则图形程序将是实时的。但是我们知道在实践中，大多数人只能以60 fps或0.01666秒的速度感受游戏的顺畅。所以现在我们有两个不同的答案。我们可以以某种方式证明他们两个？是。我们可以说在理论上实时意味着0.004秒，但在实践中0.01666秒就足够了。
我们可以很高兴并在这里停留，但我们正在探索之旅。所以我们进一步思考。你想要一个“实时”航空电子自动化系统有0.01666秒的响应时间吗？对于“实时”核电站系统，您认为是否可以接受0.01666秒响应时间？如果指令完成时间为0.0166秒，那么阀门在物理上需要15秒关闭的油控系统才会被定义为“实时”？所有这些问题的答案绝对不是。为什么？回答这个问题，你回答为什么“实时”被定义为“实时程序必须保证在特定的时间限制内响应”。
对不起，我对“Pusher”一点都不熟悉，但我可以回答你的第一个问题和第二个问题的一部分：“实时”可以应用于任何需要“反应”的系统或回应某种形式的投入。这里的“系统”比你想象的更通用。一个大脑会有资格，但在工程的背景下意味着整个堆栈：硬件+软件。
- 这个定义只适用于硬件/电子设备还是可以应用于软件？
它也适用于软件。任何有困难的时间限制。例如，有实时操作系统，甚至是Java的实时规范。
- 如果适用于软件，它是否适用于像Pusher这样的远程服务？
很难看到如果涉及到网络如何。顾名思义，它们更可能只是“及时”的意思，或者只是一种马虎的“推动模式”。本网站上的大量用户似乎认为“实时”意味着“真实世界”。在IT中，它意味着一个能够满足严格实时约束的系统。你引用的维基百科的定义是正确的，但这个例子不是很令人满意。
- 什么时间限制推杆被视为“实时”？
问题是畸形的。真正的问题是Pusher是否真的能够实际满足硬实时约束，并且只有它的最小值可能是什么。如果没有操作系统和网络支持，这似乎并不可能。
- WebRTC，Firebase等其他服务的时间限制是什么？
同上。
术语“实时”的大多数解释都是指传统的静态类型，通常称为“硬实时”。尽管对“硬实时”和“软实时”这两个术语的含义没有太多共识，但我根据科学的第一原则提供了这些和其他基本术语的定义，其中Introduction to Fundamental Principles of Dynamic Real-Time Systems.
大回答。一个小想法：（不熟悉推送器，但是）网络应用程序可以是“实时”的，不需要OS /网络支持。对于某些系统，超时响应可被视为可接受的响应。 – bolov
@bolov我想是这样，但是非实时操作系统甚至不能保证超时时间没有增加一些延迟。 – EJP