问题描述
在Windows本地计算机上，为什么通过UDP使用命名管道对IPC(进程间通信)更可取?还是UDP有时可能会更好?
Why Named Pipes are preferable for IPC (Inter Process Comunication) on local Windows machine over UDP? Or UDP sometimes might be somewhere better?
推荐答案
即使在本地主机上，UDP数据包也可能丢失.另外，由于UDP基于数据报且无法保证传递，因此很难传输较大的数据块.最后，本地主机上的UDP有时会被浏览器阻止.通常，单计算机IPC通常甚至不考虑UDP.
UDP packets even on localhost can be lost. Also, as UDP is datagram-based and has no guaranteed delivery, it's hard to transfer larger data blocks. Finally, UDP on localhost is sometimes blocked by browsers. In general, UDP is usually not even considered for single-computer IPC.
在Windows上，我建议将内存映射文件+同步原语作为最快且可能是最简单的方法.当您管理命名管道时，命名管道通常会很好地工作，但是我在这里看到很多有关如何使命名管道完全运行的问题(而且我还没有收到有关MMF的任何投诉).
On Windows I recommend memory-mapped files + synchronization primitives as the fastest and probably the easiest method. Named pipes usually work well when you manage them to work, but I see lots of questions here regarding how to make the named pipes work at all (and I have yet to see a single complaint regarding MMFs).
我们有一个产品MsgConnect，它提供基于套接字，基于UDP和MMF的传输，适用于本地或跨网络的IPC，因此我在此主题方面有实践经验.考虑使用命名管道作为支持，但后来放弃了此主意，转而采用其他机制.
We have a product, MsgConnect, which provides socket-, UDP- and MMF-based transports, suitable for IPC locally or across network, so I have practical experience with this topic. Named pipes were considered for support but then the idea was discarded in favor of other mechanisms.
这篇关于Windows上IPC的命名管道与UDP的比较的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！