因此,我认为实时更新/通信的定义是,一个用户所做的更新在完成后立即转发给订阅该对象的其他用户。
但这不是瞬时的(数据需要有限的时间才能传输)。所以我想那意味着很短的时间。
如果您每5秒使用ajax轮询,则用户A看到用户B所做的事情所花费的时间为:5 + t1 + t2(数据(http请求)从用户B的PC到达服务器所花费的时间。t2为数据从服务器到达用户A的PC所需的时间)。
t1 + t2是无法从图片中提取的最小延迟(确保套接字减少了此时间,但是这些因素仍然存在,无论它是多少)。
因此,在使用套接字的情况下,可能会有t1 + t2 + d的延迟。 d是服务器注意到事件在内部发生并进行传播所花费的时间(取决于CPU能力)
我的问题是:是否有任何确定的基准/标准来定义实时通信应具有的d小。
还是实时只是我们每天都会使用的一个通用术语?
这完全出于好奇而不是任何应用。我很好奇,是否有针对实时数据的既定标准。
最佳答案
"is there any established benchmark/standard that defines how small d should be for the communication to be realtime?"
您的问题是有效的。应用程序始终由特征等待时间
t
定义。在不同的上下文中,就t
而言,“实时”可能具有完全不同的含义。我会说,在涉及Web和人类用户的应用程序上下文中定义实时事件处理的公认“标准”是(多个)用户应该能够与应用程序交互,而不会“感觉到”延迟。应用程序必须“感到响应”。从数量上讲,这可能意味着请求和响应之间的总体延迟时间(一般术语)应不大于约100毫秒。人类对现实世界事件的响应时间在这个数量级上。要求极快 react 时间的在线游戏绝对可以在10到60毫秒之间的总延迟(往返)时间上玩。
在其他情况下,例如在实验室中或用于控制行业中的机器,实时事件处理有时意味着保证事件处理在几毫秒,几微秒甚至更快的时间内进行。这是完全不同的情况。
回到Web应用程序,我认为现代实时Web服务显示以下一个或多个特征:
我希望这可以概括地回答您的问题。如果您想了解更具体的信息,请随时发表评论。
关于sockets - 是否有用于实时通信(websocket或ajax轮询等)的基准?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/17873504/