Windows 7 上的 C#：IP 多播发送速度慢？
我有一个在 Windows 上运行良好的应用程序，但在 Windows 7 上似乎变得非常慢。我已将问题跟踪到一个未绑定的套接字，我在该套接字上使用“sendto”进行 IP 多播发送。这些调用通常在约 1 毫秒内完成，但在我的 Windows 7 64 位配置上，我看到一些完成时间为 1 秒到 2 秒（是的，慢了 1000 倍）。我的数据包相当大，我已经相应地重新配置了套接字缓冲区。
在这些特定的测试中，我在我的一台笔记本电脑上运行了六个应用程序，形成了一个多播组，因此多播发送实际上是环回的，并且永远不需要通过网络出去。我不知道我的应用程序在不同机器上是否会出现此问题；将测试这种情况，但即使问题在其他配置中消失，我也需要 Isis2 以这种方式工作。
有人曾经见过这样的事情吗？
我很乐意分享我的代码（这是 Isis2 系统的一部分，可以从康奈尔大学免费下载 http://www.cs.cornell.edu/ken/isis2），但我没有该问题的 2 行演示。然而，我要说的是，Isis2 的这一部分现在已经相当成熟，并且随着我对库的扩展和工作，它已经愉快地进行了 3 年左右的多播。如前所述，我怀疑这可能是 Windows 7 问题。
我从未见过小数据包的问题，所以这肯定与我发送大数据包有关。
I have an application that works well on Windows but seems to have become very slow on Windows 7. I've tracked the problem to an unbound socket on which I do IP multicast sends, using "sendto". These calls normally complete in ~1ms, but I'm seeing some completion times of 1s to 2s (yes, 1000x slower) on my windows 7 64-bit configuration. My packets are fairly large and I've reconfigured the socket buffers accordingly.
In these particular tests I've had six applications running on my single laptop, forming a multicast group, and thus the multicast sends actually loop back and never need to go out on the wire. I don't know if the issue arises with my apps on different machines; will test that case, but in even if the problem goes away in other configurations, I also need Isis2 to work this way.
Anyone ever seen anything like this before?
I'll be happy to share my code (this is part of the Isis2 system, available for free download from Cornell at http://www.cs.cornell.edu/ken/isis2) but I don't have a 2 line demo of the problem. However, I will say that this part of Isis2 is pretty mature by now and has been multicasting happily for 3 years or so as I've extended and worked with the library. As noted, I'm suspicious that this may be a windows 7 issue.
I never see the issue with small packets so it definitely has something to do with my sending large ones.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为 Benjie 关于 NIC 的建议可能是正确的。我在另外两台机器上尝试过，相同的代码运行没有问题。在我运行 Windows 的 Apple Mac 上，“卡住”了……非常好奇。那么，Benjie，既然我可以确认它可能是网卡，你知道我应该看什么吗？这一定是我正在做的事情......事实上，Mac 在另一个方面也表现得很奇怪：IPMC 流量的爆发导致我的 VPN 会话中断。很明显，在这些运行过程中，NIC 确实以某些方式参与其中，即使所有接收器都在一台机器上。
目前，我在仅限于在 Mac 上运行的单一 Windows 平台上进行实验时，通过将 TTL 值设置为 0 来解决此问题。这还有一个额外的好处，那就是我最终不会对楼下的网络广播和电视进行 DDoS 攻击。但我很好奇，很想了解在我家里无线进行 IPMC 时，什么可能会导致 2 秒的延迟！
不管怎样，谢谢本杰。好主意。
I think Benjie may be correct about the NIC suggestion. I tried it on two other machines and the same code ran without problems. Here on my Apple Mac running Windows, gets "stuck"... very curious. So, Benjie, now that I can confirm that it could be the NIC, do you have any idea what I should be looking at? It must be something I'm doing... In fact the Mac acts strange in another way too: bursts of IPMC traffic cause my VPN session to break. So clearly the NIC does get involved in some ways during these runs, even with all the receivers on a single machine.
For the time being I've worked around this by setting the TTL value to 0 when doing experiments confined to my single Windows platform running on the Mac. This has the added benefit that I don't end up doing a DDoS attack on my Internet radio and television downstairs. But I am curious and would love to understand what could possibly cause a 2s delay when doing IPMC wirelessly within my house!
Anyhow, thanks Benjie. Good idea.