.NET UDP 多播的替代方案
我正在寻找在 .NET Framework 上使用 UDP 多播的替代方案，并寻求建议。
我需要将消息发送到运行相当多 ASP.NET 应用程序的多个 Web 服务器。这些消息只能是单向的，来自几台不同的机器。 UDP 多播将是完美的，只是我无法使用它，因为它需要管理权限。有关原因的详细信息，请参阅 ASP.NET 多播 UdpClient 问题。
是否还有其他东西可以以类似的方式工作，允许多个应用程序接收广播类型的消息？
I am looking for an alternative to using UDP multicast on the .NET Framework and am looking for suggestions.
I need to send messages to several web servers running quite a few ASP.NET applications. These messages would be one-way only, coming from several different machines. UDP multicast would be perfect except that I can't use it due to it requiring administrative rights. See ASP.NET Multicast UdpClient problems for details as to why.
Is there something else that would work in a similar manner, allowing multiple applications to receive broadcast-type messages?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您是否考虑过使用 MSMQ 或 SQL 数据库？使用 SQL 2008 数据库，您还可以让 SQL 服务器通知您更改。
Have you considered using MSMQ or a SQL database? Using a SQL 2008 database you can have the SQL server notify you of changes as well.
我想到了几种可能性：
将多播 UDP 代码放入 Windows 服务中。由于端口上只有一个侦听器，因此您不需要提升权限。您可以使用共享内存或许多其他技术与服务进行通信。
使用到中央消息调度/中继节点的异步点对点原始 TCP 连接。 使用异步 I/O 发送和接收消息可以最大限度地减少等待时间。
使用持久队列机制，例如 SQL Server 中的 Service Broker。它仍然是单播的，但您可以有一个存储过程将消息发送到所有端点。再次强调，使用异步 I/O 来最大限度地减少等待时间。
使用在进程外运行的商业消息传递总线，例如 Tibco Rendezvous。
使用
A few possibilities come to mind:
Put your multicast UDP code into a Windows Service. By having only a single listener on the port, you wouldn't need elevated permissions. You could communicate with the service using shared memory or a number of other techniques.
Use async point-to-point raw TCP connections to a central message dispatch / relay node. Sending and receiving messages with async I/O would minimize wait time.
Use a persistent queuing mechanism such as Service Broker in SQL Server. It's still unicast, but you could have a single stored procedure that sent messages to all endpoints. Again, use async I/O to minimize wait times.
Use a commercial message passing bus that runs out of process -- something like Tibco Rendezvous.
ØMQ 有两个 CLR 绑定可能比滚动您自己的消息传递层更高效。您可以根据需要使用 PUB/SUB 套接字通过 TCP 或多播或多播消息。此外，由于该库位于 ASP.net 外部，因此这应该可以消除您遇到的受限权限问题。
ØMQ has two CLR bindings that may be productive than rolling your own messaging layer. You can use PUB/SUB sockets to multicast messages over TCP or IP multicast as desired. Also as the library is external to ASP.net this should remove the restricted rights problem you are encountering.
ActiveMQ 是一个像 msmq 一样的免费服务。它可以处理像您这样的非持久消息。缺点是它需要一台服务器，因为它基本上是辐条和集线器风格的方法，您有一个中央服务器。但它在.NET 中确实运行良好并且具有出色的性能。我每秒通过它发送数百条消息，而且它保持得很好。
ActiveMQ is a free service like msmq. It can handle non-durable messages such as yours. The downside is that is that it requires a server because it's bascially as spoke and hub style approach where you have a central server. But it does work well in .NET and has great performance. I'm sending hundreds of messages across it per second and it keeps up just fine.
Redis pubsub 使用 StackExchange.Redis API。
简单、性能卓越、可扩展，如果您选择它，您一定会将它用于其他用途，例如缓存/会话管理/监控或此瑞士军刀工具包的任何其他常见用途。
Redis pubsub using the StackExchange.Redis API.
Simple, excellent performance, scalable and if you choose it you're bound to use it for other things like caching/session management/monitoring or any one of the other common uses of this swiss army knife toolkit.