Zeromq 是点对点视频聊天的正确解决方案吗

发布于 2024-12-24 21:43:34 字数 126 浏览 1 评论 0原文

我想知道我的zeromq想法是否正确?我正在考虑使用 Zeromq 编写一个点对点聊天应用程序,但当我进一步阅读它时,Zeromq 似乎比使用的(tcp 套接字)更低级别。 Zeromq 适合编写点对点聊天应用程序吗?或者这个用例不适用?

I was wondering if my idea of zeromq is right? I was thinking of writing a peer to peer chat application using zeromq but as i read further into it zeromq seems to be more low level than what one would use (tcp sockets). Is zeromq good for writing peer to peer chat app or is this use case not applicable?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

霓裳挽歌倾城醉 2024-12-31 21:43:34

首先,我不同意您的说法,即 Zeromq 比套接字低级。 AFAICT Zeromq 提供了一个类似于套接字 API 的 API。然而,它还可以处理其他事情,例如使用相同的发送调用向多个客户端发送消息。

其次,你的问题不是很清楚:你所说的“好”是什么意思:易于编写(因为你指的是低级)、可靠、足够高效等?您可以使用任何您想要的东西,实现的复杂程度当然会有所不同。

另外,您可能应该在视频聊天应用程序中使用 udp 而不是 tcp,因为数据及时到达比所有数据到达更重要,但这是一个完全不同的主题。如果您可以将 Zeromq 与 udp 结合使用(并且您必须对此进行研究),我认为您没有理由不能将其用于视频聊天。

您需要考虑的主要因素是您是否可以足够快地在对等点之间发送数据,以便提供可接受的 QoS:AFAIR 对于会话服务来说,大约 300 毫秒的最大 RTT 被认为是可以的。

以下链接适用于 VOIP,但也应适用于视频聊天要求:

大多数呼叫者在超过 250 毫秒时都会注意到往返延迟,因此单向延迟预算通常为 150 毫秒。 ITU-T G.114 建议书中还指定 150 毫秒作为实现高质量语音所需的最大单向延迟。除了往返延迟之外,呼叫者开始对进行双向对话感到不安,并且通常最终会互相交谈。在 500 毫秒及以上的往返延迟下,打电话是不切实际的,您几乎可以在离开房间后讲一个笑话并让对方发笑。

Firstly, I would disagree with your statement that zeromq is more low-level than sockets. AFAICT zeromq presents an API that is similar to the socket API. However it can also handle other things such as sending messages to multiple clients with the same send call.

Secondly, your question is not very clear: what do you mean by good: Easy to write ( since you refer to low-level), reliable, efficient enough, etc? You can use anything you want, the level of implementation complexity will of course differ.

Also, you should probably use udp instead of tcp in a video chat application, since it is more important that data arrives timeously than that all data arrives, but that is a whole different topic. If you can use zeromq with udp (and you'll have to research that), I see no reason why you couldn't use it for video chat.

The main factor you need to consider is whether you can send data between the peers fast enough in order to provide an acceptable QoS: AFAIR a maximum RTT of around 300ms is perceived as ok for conversational services.

The following link applies to VOIP but should also apply to video chat reqirements:

Most callers notice round-trip delays when they exceed 250mSec, so the one-way latency budget would typically be 150 mSec. 150 mSec is also specified in ITU-T G.114 recommendation as the maximum desired one-way latency to achieve high-quality voice. Beyond that round-trip latency, callers start feeling uneasy holding a two-way conversation and usually end up talking over each other. At 500 mSec round-trip delays and beyond, phone calls are impractical, where you can almost tell a joke and have the other guy laugh after you've left the room.

起风了 2024-12-31 21:43:34

正如 Ralf 指出的那样,ZeroMQ 是非常高级的,而不是低级的。此外,通常建议不要将 ZeroMQ 用于视频,因为 UDP 支持是新的且尚未通用(请参阅此答案 )。一般来说,ZeroMQ 是围绕使用 TCP 套接字构建的,尽管 PUB/SUB 架构模仿 UDP,但您不会获得真正的 UDP 性能(这对视频至关重要),因为 TCP 套接字上的错误检查使得很难获得延迟足够低以获得流畅的视频流。

As Ralf points out, ZeroMQ is very high-level, not low-level. Furthermore, generally one would be advised against using ZeroMQ for video simply because UDP support is new and not yet universal (see this answer). Generally, ZeroMQ was built around using TCP sockets, and although the PUB/SUB architecture mimics UDP, you won't get real UDP performance (which is crucial for video) because the error-checking on TCP sockets makes it hard to get the latency low enough to get a smooth video stream.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文