单源推送:如何每5分钟向50000个客户端发送5kb

发布于 2024-10-31 22:40:53 字数 949 浏览 4 评论 0原文

我需要实现服务器发送的客户端服务器架构 通过互联网向许多客户传达相同的信息。 我需要大约每 5 分钟发送一条消息。 该消息不会超过 5KB。 我需要解决方案能够扩展到大量连接的客户端 (50.000-100.000)

我考虑了很多解决方案:

  • TCP 套接字

  • UDP 多播

  • WCF http 双工服务(comet)

我认为我必须放弃 UDP 解决方案,因为它仅对于同一网络上的客户端来说是一个很好的解决方案,并且它无法在互联网上工作。 我在某处读到,如果我连接了许多客户端,WCF 多播将导致瓶颈,但我找不到任何显示性能统计信息的文档。 在我看来,Tcp 套接字是选择的解决方案。 你觉得怎么样?我说得对吗?


当我说 UDP 不能在互联网上工作时,我当然错了......我想 这是因为我读了一些文章指出你需要正确 配置网络中的路由器以支持多播...我读到 udp 端口​​多播范围并认为它应该是本地的。 相反,可以通过 Internet 访问范围 224.0.0.1 - 239.255.255.255(D 类地址组)。


考虑到在我的情况下可靠性不是关键点,udp 多播是一个不错的选择。 .net 框架提供了非常有用的类来完成此任务。 我可以轻松启动 UdpClient 并开始使用两行代码在多播地址上发送数据。 在客户端,这真的很容易。 UdpSingleSourceMulticastClient 类完全可以满足我的需要。 对于可靠性和安全性,.net 框架有一种智能而简单的方法来处理 DoS 攻击、DNS 重新绑定攻击和反向隧道攻击,如下所述:http://msdn.microsoft.com/en-us/library/ee707325(v=vs.95).aspx

I need to implement a client server architecture where the server sends
the same message to many clients over the internet.
I need to send a single message every 5 minutes about.
The message won't excede 5KB.
I need the solution to scale to a big number of clients connected (50.000-100.000)

I considered a bunch of solutions:

  • TCP Sockets

  • UDP Multicast

  • WCF http duplex service (comet)

I think I have to discard UDP solution because it is a good solution only for clients on the same network and it won't work over the internet.
I read somewhere that WCF multicast will cause a bottleneck if I have many clients connected but I can't find anywhere documentation showing performance statistics.
Tcp sockets seems to me the solution to chose.
What do you think about? Am I correct?


I'm certainly wrong when I say UDP doesn't work on internet... I thought
this because I read some articles pointing out that you need properly
configured routers in the network to support multicasting... I read of the
udp ports multicast range and thought it was meant to be locally.
Instead, the range 224.0.0.1 - 239.255.255.255 (Class D address group), can be reached over the internet


Considering that in my case reliability is not a crucial point, the udp multicast is a good choice.
The .net framework offers really helpful classes to accomplish this.
I can easily start an UdpClient and begin send data on a multicast address with two lines of code.
At client side it is really easy to.
There is the UdpSingleSourceMulticastClient class that does exactly what I need.
For what concernes reliability and security the .net framework has a smart and simple way of handle DoS attacks, DNS Rebinding attacks and Revers tunnel attacks that is described here: http://msdn.microsoft.com/en-us/library/ee707325(v=vs.95).aspx

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

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

发布评论

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

评论(2

┊风居住的梦幻卍 2024-11-07 22:40:54

主要问题是:您关心更新是否到达客户端吗?

如果您这样做,那么您将需要在 UDP 之上构建一些东西来增加可靠性。 UDP 数据报不可靠,因此您应该预料到有些数据报不会到达目的地。如果您快速推送 UDP 数据报,这种情况更有可能发生。请注意,在某些情况下,您的客户端也可能使用 UDP 获得同一数据报的多个副本。

如果您有一个不错的架构,那么使用 TCP 实现此级别流量的 50-100k 连接应该不难。

请参阅此处,了解我就该主题撰写的一些博客文章。

下面是一些处理向多个客户端发送数据的示例代码。

The main question is: Do you care if the updates get to the clients?

If you DO then you will need to build something on top of UDP to add reliability. UDP datagrams are NOT reliable and so you should expect that some wont get to the destination. This is more likely if you are pushing UDP datagrams out quickly. Note that your clients might also get multiple copies of the same datagram in some situations with UDP.

50-100k connections with this level of traffic shouldn't be that difficult to achieve with TCP if you have a decent architecture.

See here for some blog posts that I've done on the subject.

And here's some example code that deals with sending data to many clients.

金橙橙 2024-11-07 22:40:54

单播(tcp 套接字)对于像这样的相对少量的流量来说可以正常工作,但是随着多播技术的发展,情况每年都在变化。

Unicast (tcp sockets) will work fine for a relatively small amount of traffic such as this, but keep on top of multicasting technology, the situation is changing every year.

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