我们有一个“发布者”应用程序，它使用多播发送数据。该应用程序对性能非常敏感（我们在微秒级别进行优化）。收听此发布数据的应用程序可以（通常）与发布应用程序位于同一台计算机上。
我们最近注意到一个有趣的现象：执行sendto（）的时间与计算机上的侦听器数量成比例增加。
例如，假设没有监听器，sendto（）调用的基准时间是5微秒。每个额外的侦听器将sendto（）调用的时间增加大约2微秒。因此，如果我们有10个侦听器，那么现在sendto（）调用需要2 * 10 + 5 = 25微秒。
这对我来说建议sendto（）调用阻塞，直到数据被复制到每个侦听器。
分析监听方面也支持此功能。如果有10个侦听器，则每个侦听器比前一个侦听器接收数据两个微秒。 （即，第一个侦听器在大约5微秒内获取数据，最后一个侦听器在大约23--25微秒内获取数据。）
有没有办法在程序级别或系统级别更改此行为？像非阻塞/异步sendto（）调用的东西？或者至少只阻止消息被复制到内核的内存中，所以它可以返回而不等待所有的监听器）？
答案 0 :(得分：0)
很抱歉要问明显，但套接字是否无阻塞？ （将O_NONBLOCK添加到端口的标志集 - 请参阅fcntl）
答案 1 :(得分：0)
组播循环非常低效，不应用于高性能消息传递。正如您在每次发送时都注意到的，内核正在将消息复制到每个本地侦听器。
推荐的方法是使用单独的IPC方法分发到同一主机上的其他线程和进程，共享内存或unix套接字。
例如，通过在同一个ZeroMQ插槽上的PGM多播连接上方添加IPC连接，可以使用ZeroMQ套接字轻松实现这一点。