是否存在实时通信的基准(websocket或ajax轮询等)?

时间:2013-07-26 05:20:49

标签: sockets websocket real-time

所以我认为实时更新/通信的定义是当一个用户做出的更新一旦发布就被中继到订阅该对象的其他用户。

但这不是即时的(数据需要有限的时间旅行)。所以我想这意味着很短的时间。

如果每隔5秒使用ajax轮询,则用户A看到用户B所做的事情的时间是:5 + t1 + t2(数据(http请求)从用户B的PC到服务器所用的时间) .t2是数据从服务器到用户A的PC的时间。)

t1 + t2是无法从图片中取出的最小延迟(确保套接字减少了这个时间,但这些因素仍然存在,无论多么小)。 所以你可以在套接字的情况下延迟t1 + t2 + d。 d是服务器发现内部事件发生并传播它所需的时间(取决于CPU功率) 我的问题是:是否有任何既定的基准/标准来定义通信实时的小d应该是多少。

或者实时只是我们每天投掷的一般术语? 这纯粹是出于好奇而不是任何申请。我很好奇是否有任何既定的实时数据标准。

1 个答案:

答案 0 :(得分:1)

  

“是否有任何既定的基准/标准来定义小d   应该是为了实时沟通吗?“

您的问题是有效的。应用程序始终由特征延迟时间t定义。在不同的情境中,“实时”与t的含义完全不同。

我想说,在涉及网络和人类用户的应用程序的上下文中定义实时事件处理的公认“标准”是(多个)用户应该能够与应用程序交互而不会“感觉”阻碍延迟。应用程序必须“感觉敏感”。在数字中,这可能意味着请求和响应之间的总延迟时间(一般术语)应该不高于约100毫秒。人类对现实世界事件的响应时间是这个数量级。需要极快反应时间的在线游戏绝对可以玩,总延迟(往返)时间在10到60毫秒之间。

在其他环境中,例如在实验室中或在工业中控制机器,实时事件处理有时意味着保证事件处理在几毫秒,几微秒甚至更快。这是完全不同的情况。

回到Web应用程序,我认为现代实时Web服务显示以下一个或多个特征:

  • 用户界面是非常敏感的,部分通过例如本地执行来实现。 JavaScript的。在用户端(例如浏览器中)运行的代码与远程Web应用程序之间的最终通信是异步执行的(对用户隐藏)。
  • 后端实现基于有效的事件处理技术,而不是定期轮询。
  • 在用户和后端之间使用持久性TCP / IP连接,以消除由于连接打开/关闭而导致的延迟和开销(这是WebSockets发挥作用的地方)

我希望这能概括地回答你的问题。如果您想更具体地了解某些内容,请随时撰写评论。