127.0.0.1 localhost 不受网卡约束，现代操作系统这两个基本上由cpu内存实现。

第二个，你这个要求强时序吗？也就是说你出的图每一帧都要被计算？是不是要求另一边处理的也要实时的？

如果可以丟帧，你你直接在一块内存中写入，另一个程序读就行，没有时序问题，基本表现就是一个只写一个只读。类似于虚拟屏幕的实现。

如果不能丢帧，考虑异步队列。

如果要求强实时，还不能丢帧，就得专门优化了，具体再说。

【 在 AlphaO 的大作中提到: 】
:
: 程序A是我的，数据原本自我闭环，用Rust写的。程序B是另一家单位的，想要引出A的内部数据做它们自己的科学研究，用C开发。
:
: 数据是3路实时图像帧，分别是10000×10000、5000×5000、5000×5000灰度图，帧率不算低，三路加起来大概1200MB/s，用上压缩顶多能降到1000MB/s，远超以太网传输带宽。
:

#发自zSMTH@23054RA19C
--
FROM 113.143.105.*

没有元信息。不需要元信息。
一个简单的协议而已。最多把轻量级文件传输协议再简化一下。
定义一个数据结构=头部+数据载荷。
欧洲高能物理搞这个都有二十多年了。
你有几个生产者？几个消费者？
你把网络协议看一看。很简单的。甚至都不用。

有三个生产者A、B、C，三个消费者X、Y、Z。 A和X是一对一关系，B和T是一对一关系，C和Z是一对一关系。 现在要设计一个数据封装格式，由头部和数据载荷组成，头部至少有一个能够反映生产者和消费者的一对一关系的区域，数据载荷是一个完整的图像。现在要求在Windows平台上采用缓冲区和信号量，设计这种读写关系的进程间通信软件。为了加快读写速度，应该尽可能采用内存共享方式。

有一个没有告诉AI，就是如果不是自己的数据，就释放资源，并且并不消费资源。你自己补充一下。




【 在 AlphaO 的大作中提到: 】
: 谢谢。
: 虽然现在我就类似这样，用Windows API实现的（信号邮箱用于交互元信息），但其实到头来还是得“拷贝”，从进程A的数据结构T，拷贝一部分结构T2到共享内存块SharedMemory中，然后共享给B进程映射回T2。
: 这里面多了一个拷贝到内存块的过程，看起来不是完全态的共享内存。
: ...................
--
FROM 111.4.64.*

以下是基于 Rust 语言实现的生产者 - 消费者内存共享通信程序，特别处理了消费者验证数据归属的逻辑：

rust-producer-consumer-ipc
Rust版生产者-消费者内存共享通信程序
V1
生成 lib.rs
生成 producer_main.rs
生成 consumer_main.rs

这个 Rust 实现包含以下关键特性：

数据验证机制：
消费者在获取锁后首先检查头部中的 consumer_id
如果数据不属于自己，立即释放信号量，不处理数据
实现了 CRC32 校验确保数据完整性
内存共享设计：
使用 Windows API 创建命名共享内存区域
每个生产者 - 消费者对使用独立的共享内存和信号量
头部和图像数据存储在连续内存中
同步机制：
使用两个信号量实现生产 - 消费同步
生产者等待消费者消费完成信号
消费者等待生产者生产完成信号
错误处理：
完整的错误处理机制
边界检查和数据验证
异常情况下的信号量释放
扩展性：
可以轻松添加更多生产者 - 消费者对
支持多种图像格式
线程安全设计

使用时，先运行生产者程序，再运行消费者程序。生产者将生成模拟图像数据并发送给对应的消费者，消费者会验证数据归属并处理属于自己的数据。


【 在 AlphaO 的大作中提到: 】
: 谢谢。
: 虽然现在我就类似这样，用Windows API实现的（信号邮箱用于交互元信息），但其实到头来还是得“拷贝”，从进程A的数据结构T，拷贝一部分结构T2到共享内存块SharedMemory中，然后共享给B进程映射回T2。
: 这里面多了一个拷贝到内存块的过程，看起来不是完全态的共享内存。
: ...................

附件(3.7KB) rust-producer-consumer-ipc.zip
--
FROM 111.4.64.*

几年前回环仍要走协议栈，有协议开销。

有时序要求，至少从A的角度看，每一帧都必须要计算，确保发出。从B的角度看，至少A能够B留出理论上充足的接收处理时间去应对每一帧。A-->光纤-->B倒是可以解决，但代价太大，放弃

【 在 VincentGe 的大作中提到: 】

: ...................
--
FROM 123.127.159.*

非常感谢，代码级指导，很有启发！
很值得参考，看着像是AI生成的，但质量看着很高，这个AI有点厉害。
先写lib再写app的风格，实在要赞美

这几天我也改善了一下，因为我发现共享内存其实不存在Send和Sync的问题，是可以天然多线程处理的。所以现在我从图像流的源头（GPU输出），就直接创建共享内存，从GPU Buffer直接拷贝到SharedMemory （不再经过原本的Vec<u16>图像缓冲图），而后所有后续地方都用Arc<SharedMemory>传递。结构大致为

unsafe impl Send for SharedMemory {}
unsafe impl Sync for SharedMemory {}

pub struct SharedMemory {
    handle: HANDLE,
    mapping: MEMORY_MAPPED_VIEW_ADDRESS,
    pub size: usize,
    pub header_size: usize,
    pub cursor: usize,
}

impl SharedMemory {
    #[inline]
    pub fn as_ptr(&self) -> *mut u8 {
        self.mapping.Value as *mut u8
    }
    #[inline]
    pub fn write(
        &mut self,
        data: &[u8],
    ) {
        unsafe {
            let ptr = self.as_ptr().add(self.cursor);
            std::ptr::copy(data.as_ptr(), ptr, data.len());
            self.cursor += data.len();
        }
    }
}

impl Drop for SharedMemory {
   //
}



【 在 xiaokang 的大作中提到: 】
: 以下是基于 Rust 语言实现的生产者 - 消费者内存共享通信程序，特别处理了消费者验证数据归属的逻辑：
: rust-producer-consumer-ipc
: Rust版生产者-消费者内存共享通信程序
: ...................
--
FROM 123.127.159.*