我需要在一台机器上实现非常快速、低延迟、高吞吐量的进程间(或应用程序域间)通信。
消息通常每隔几毫秒就会流动一次(但在几分钟内,每毫秒甚至可能有多达 3-5 条消息),每条消息的大小不到 1KB,目标往返延迟最大为 1 毫秒(通过往返 I意味着传递一条消息,然后以某种方式回调生产者以宣布消费者是否想要“认领”该消息)。
我做了一些研究,似乎内存映射文件是最快的可用可能性,但是我需要专有地实现围绕它的整个通信堆栈(共享内存的分配和管理,将消息复制到其中并从中复制消息以及发出信号向消费者表明新消息已准备好被消费)。 我在 Windows 上看到了显示 IPC 方法体系结构的图片 (http://blogs.msdn.com/b/salvapatuel/archive/2009/06/08/working-with-memory-mapped-files-in-net-4.aspx),这些方法似乎已经使用了 MMF。 所以根据我的描述 - 我不会通过重新实现命名管道已经做的事情来重新发明轮子。或者我真的可以实现比命名管道提供的协议(protocol)快得多的协议(protocol)吗?
Edit1:添加 frgotten 链接到显示命名管道构建在 MMF 之上的图片(http://blogs.msdn.com/b/salvapatuel/archive/2009/06/08/working-with-memory-mapped-files-in-net-4.aspx)
最佳答案
是的,管道是位于内核内存池中的共享内存之上的抽象。内存映射文件位于底部,让您可以原始访问共享内存,无需任何帮助,您可以仲裁对内存的访问并发出更改信号。
您所引用的消息速率并不接近于让管道难以跟上。典型的开销大约是 1 微秒的恒定操作系统开销加上复制消息所需的时间,该时间由内存总线的带宽设置。在配备 DDR2 RAM 的最低端消费类 PC 上至少每秒 5 GB。具有本地环回的 Socket 具有完全相同的开销。托管程序中的 MMF 也是如此,除非使用指针,否则复制数据是不可避免的。
关于C#.NET MMF : Is implementation of proprietary communication over Memory Mapped file just reinvention of Named Pipes?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18822508/