3、消息传递核心API：MsgSend()、MsgReceive()、MsgReply() 三件套详解

好，咱们直接进入正题。QNX 的消息传递，说白了就是三个函数撑起一片天：MsgSend()、MsgReceive()、MsgReply()。我管它们叫「三件套」。你只要搞懂这三个家伙，QNX 进程间通信的基本功就算打牢了。

很多刚接触 QNX 的朋友会问：这不就是发消息、收消息、回消息吗？有什么难的？嗯，表面看确实简单，但实际用起来，坑不少。我当年第一次写多进程通信程序，就因为没搞懂阻塞机制，调试了一整晚。今天咱们就把这三个 API 掰开揉碎了讲清楚。

3.1 三件套的协作模型

先看一张简单的协作图（脑补一下）：

  • 客户端 调用 MsgSend()，把自己挂起，等回复。
  • 服务端 调用 MsgReceive()，阻塞等待消息到来。
  • 服务端 处理完消息后，调用 MsgReply()，唤醒客户端。

这个模型的核心是什么？同步。客户端发完消息后，啥也不干，就等着。服务端不回复，客户端就一直睡。这跟网络编程里的异步回调完全不同，你想想看，是不是有点像两个人打电话——你说一句，我回一句，谁也不能抢话。

关键点：MsgSend() 是阻塞的。它不返回，客户端就卡在那。所以服务端必须及时回复，否则整个系统可能「假死」。

3.2 MsgSend()：客户端的那一嗓子

函数原型长这样：

int MsgSend(
    int coid,           // 连接ID，指向服务端
    const void *smsg,   // 发送缓冲区
    int sbytes,         // 发送字节数
    void *rmsg,         // 接收缓冲区
    int rbytes          // 接收缓冲区大小
);

我个人习惯把 coid 叫做「电话线」。你拨通了这个号码，才能跟服务端说话。smsg 是你递过去的小纸条，rmsg 是等着对方回信的信封。

这里有个细节：sbytes 和 rbytes 可以不一样。我见过有人把发送和接收设成同样大小，其实没必要。你发个请求可能就几十字节，但回复可能带一大包数据。灵活点。

避坑指南：我曾经犯过一个低级错误——发送缓冲区 smsg 指向了栈上的局部变量，函数返回后数据就没了。记住：MsgSend() 是同步的，但数据拷贝发生在内核态，你的缓冲区在调用期间必须有效。

3.3 MsgReceive()：服务端的守候

服务端这边，就是死等：

int MsgReceive(
    int chid,           // 通道ID，服务端创建的监听端口
    void *rmsg,         // 接收缓冲区
    int rbytes,         // 接收缓冲区大小
    struct _msg_info *info  // 消息附加信息（可选）
);

chid 是服务端提前创建好的通道。你可以理解成邮局的信箱。所有客户端都把信投到这个信箱里，服务端一封一封地取。

注意 info 参数。很多人忽略它，其实它很有用。比如 info->srcnd 能告诉你消息来自哪个节点，info->coid 能帮你追踪客户端连接。我在做分布式系统调试时，全靠这个参数定位问题。

嗯，这里要注意：MsgReceive() 返回的是消息的字节数。如果返回 0，说明客户端发了个空消息？不，更可能是出错了。检查一下 errno。

3.4 MsgReply()：给客户端一个交代

服务端处理完消息，得回复：

int MsgReply(
    int rcvid,          // 接收ID，MsgReceive() 返回的那个
    int status,         // 状态码，0 表示成功
    const void *msg,    // 回复缓冲区
    int bytes           // 回复字节数
);

rcvid 是 MsgReceive() 返回的接收ID。它就像一把钥匙，专门用来回复对应的客户端。别搞混了，每个客户端都有自己的 rcvid。

status 参数很有意思。它会被直接传递给客户端的 MsgSend() 返回值。我习惯用 0 表示成功，负数表示错误码。这样客户端拿到返回值就能判断服务端处理结果，不用再解析消息体。

警告：MsgReply() 只能调用一次。同一个 rcvid 不能回复两次。我曾经在异常处理分支里不小心调了两次 MsgReply()，结果客户端收到了错误的数据，系统直接崩溃。记住：一次发送，一次回复，一一对应。

3.5 完整示例：一个简单的计算器服务

光说不练假把式。咱们写个简单的加法计算器：

// 服务端代码
#include <sys/neutrino.h>
#include <stdio.h>

typedef struct {
    int a;
    int b;
} request_t;

typedef struct {
    int result;
} reply_t;

int main() {
    int chid = ChannelCreate(0);  // 创建通道
    printf("Server chid: %d\n", chid);

    request_t req;
    reply_t rep;
    int rcvid;

    while (1) {
        rcvid = MsgReceive(chid, &req, sizeof(req), NULL);
        if (rcvid == -1) break;

        rep.result = req.a + req.b;  // 计算加法
        MsgReply(rcvid, 0, &rep, sizeof(rep));
    }

    ChannelDestroy(chid);
    return 0;
}
// 客户端代码
#include <sys/neutrino.h>
#include <stdio.h>

int main() {
    int coid = ConnectAttach(0, 0, chid, 0, 0);  // 连接服务端
    if (coid == -1) {
        perror("ConnectAttach");
        return 1;
    }

    request_t req = {10, 20};
    reply_t rep;

    int status = MsgSend(coid, &req, sizeof(req), &rep, sizeof(rep));
    if (status == -1) {
        perror("MsgSend");
    } else {
        printf("Result: %d\n", rep.result);  // 输出 30
    }

    ConnectDetach(coid);
    return 0;
}

这个例子很简单，但包含了三件套的完整流程。你想想看，如果我要改成乘法、除法，只需要改服务端的计算逻辑，客户端几乎不用动。这就是消息传递的魅力——解耦。

3.6 性能与注意事项

API 阻塞行为 典型耗时 注意事项
MsgSend() 阻塞直到收到回复 微秒级（同节点） 缓冲区必须有效，不能太小
MsgReceive() 阻塞直到有消息 取决于消息到达时间 可设置超时（用脉冲）
MsgReply() 非阻塞 微秒级 只能调用一次，rcvid 不能重复使用

我个人建议：消息大小尽量控制在 64KB 以内。超过这个值，QNX 内核会走额外的拷贝路径，性能会下降。我在项目中遇到过一个大块数据传输的场景，一开始没注意消息大小，结果延迟飙升。后来拆分成多个小消息，问题就解决了。

小技巧：如果你需要服务端同时处理多个客户端，可以考虑用 MsgReceivePulse() 配合脉冲消息，或者用多线程。但那是进阶内容了，咱们后面章节再聊。

3.7 常见错误与调试

调试消息传递程序，最头疼的是「死锁」。客户端等回复，服务端等消息，两边都卡住。我曾经遇到过一个 bug：服务端在处理消息时调用了 MsgSend() 去请求另一个服务，结果那个服务反过来又请求当前服务，形成了循环依赖。嗯，这种问题用 pidin 命令一看进程状态就明白了——全是 RECEIVE 或 REPLY 阻塞。

另一个常见错误是 缓冲区溢出。MsgReceive() 的 rbytes 如果小于实际消息大小，数据会被截断。我建议你始终让接收缓冲区大于等于发送缓冲区，或者用 info->msglen 动态分配。

好了，三件套的核心内容就这些。记住：MsgSend() 发、MsgReceive() 收、MsgReply() 回，三个函数一条线，同步通信不跑偏。下一章咱们聊聊更高级的用法——脉冲消息和异步通知。

← 上一章 📖 返回目录 下一章 →