多进程PLC通信流程设计及跨机消息队列C++库等技术问询

一、跨设备消息队列库选型（Windows C++） #

Boost消息队列不支持跨机，推荐几个实用的替代方案：

• ZeroMQ：轻量级、跨平台的消息库，完美支持跨进程、跨设备通信，有成熟的C++绑定。它支持REQ/REP、PUB/SUB等多种通信模式，刚好适配你的双向通信需求——可以用REQ/REP实现应用向通信进程发指令（比如告知读取指定vector），通信进程返回PLC数据；也能通过PUB/SUB实现PLC数据的实时广播。对于固定120个uint16_t的vector，直接序列化字节流发送即可，非常方便。
• nanomsg：ZeroMQ的轻量化分支，API更简洁，资源占用更低，同样支持跨机通信，适合轻量场景，通信模式和ZeroMQ类似。
• Windows原生方案：不想用第三方库的话，本地进程间用命名管道，跨设备用TCP Socket，但需要自己封装消息帧、处理序列化和字节序转换，开发量会大一些。

二、双向通信的消息设计 #

先定义固定格式的消息结构体，方便序列化传输：

// 应用发给通信进程的指令
struct AppCmd {
    enum Type { READ_VEC, WRITE_PLC } type;
    uint32_t vec_id; // 指定要读取的vector标识
    uint16_t plc_data[120]; // 写PLC时的 payload
};

// 通信进程返回给应用的响应
struct CommResp {
    bool success;
    uint16_t vec_data[120]; // 返回的vector数据
    uint32_t err_code; // 错误码，比如PLC连接失败、指令无效
};

用ZeroMQ的话，直接把结构体转成字节数组发送就行，接收后再转回来，注意字节序转换——Windows是小端，PLC一般是大端，要用htons/ntohs处理uint16_t数据。

通信模式推荐 #

用REQ/REP + PUB/SUB组合：

• REQ/REP：处理应用主动发起的指令（比如读取指定vector、写PLC），属于请求-响应模式，逻辑清晰。
• PUB/SUB：通信进程主动把PLC的实时数据推送给所有连接的应用，适合不需要主动请求的实时同步场景。

三、通信进程自动启动逻辑（Windows） #

核心思路 #

应用进程启动时，先尝试连接通信进程的消息端口：

1. 连接成功：直接正常通信。
2. 连接失败：调用Windows API启动通信进程，然后等待通信进程初始化完成（比如通信进程启动后绑定端口，发送一个"ready"信号，应用收到后再开始交互）。
3. 通信进程要监听连接数，当所有应用都断开后自动退出，避免空跑占用资源——可以用ZeroMQ的zmq_socket_monitor监听连接事件，统计当前在线应用数，为0时延迟几秒退出。

启动进程的代码片段 #

#include <windows.h>

bool LaunchCommProcess() {
    STARTUPINFO si = { sizeof(si) };
    PROCESS_INFORMATION pi;
    // 替换成你的通信进程路径
    bool ok = CreateProcess(L"./plc_comm.exe", NULL, NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi);
    if (ok) {
        CloseHandle(pi.hThread);
        CloseHandle(pi.hProcess);
        return true;
    }
    return false;
}

四、通信进程内部逻辑设计 #

通信进程保留你原来的次级线程和PLC通信，线程负责：

• 定期读取PLC的各个vector数据，存在线程安全的缓存里（用std::mutex保护）。
• 处理应用发来的指令：读取vector时直接返回缓存数据；写PLC时调用原有的写接口发送。
• 异常处理：PLC连接中断时，要缓存错误状态，及时通知所有连接的应用。

五、关键注意点 #

• 字节序转换：一定要处理uint16_t的大小端问题，否则PLC数据会乱码。
• 权限配置：跨设备通信时，要确保Windows防火墙允许消息库用的端口（比如ZeroMQ默认5555端口）。
• 错误反馈：通信进程要把PLC连接失败、指令错误等情况明确返回给应用，方便排查问题。

内容的提问来源于stack exchange，提问作者Chenoille