Mediasoup Channel Notification 机制技术解析
在 Mediasoup 的架构中，Channel 作为信令层与媒体层（mediasoup-worker）之间的通信桥梁，其 Notification 机制是实现双向异步通信的核心组件。该机制允许媒体层主动向信令服务推送状态变更、事件通知等数据，而无需等待信令服务的显式请求。
1. Notification 的触发与数据结构
Notification 的主动推送由Notifier::Emit方法实现。其核心逻辑是构造一个包含目标标识符、事件类型及负载数据的 JSON 对象，并通过 Channel 的底层传输机制发送 。
void Notifier::Emit(uint32_t targetId, const std::string& event, Json::Value& data) { MS_TRACE(); static const Json::StaticString JsonStringTargetId{ "targetId" }; static const Json::StaticString JsonStringEvent{ "event" }; static const Json::StaticString JsonStringData{ "data" }; Json::Value json(Json::objectValue); json[JsonStringTargetId] = Json::UInt{ targetId }; json[JsonStringEvent] = event; json[JsonStringData] = data; this->channel->Send(json); }该方法生成的 JSON 数据格式示例如下：
{ "data": { "entries": [ [87344059, -89], [42826186, -24] ] }, "event": "audiolevels", "targetId": 37286065 }targetId: 标识事件的目标实体，如Transport、Producer或Consumer的唯一 ID。event: 事件类型字符串，用于信令服务区分不同的通知，如"audiolevels"表示音频电平事件。data: 事件相关的负载数据，其结构因事件类型而异。
2. Notification 的底层传输流程
无论是对请求的响应（Accept/Reject）还是主动通知（Emit），最终都通过UnixStreamSocket::Send方法进行序列化和发送 。该流程的核心是将 JSON 对象转换为带长度前缀的字节流，以确保消息边界的正确性。
序列化与格式化过程如下表所示：
| 步骤 | 操作 | 关键代码/说明 |
|---|---|---|
| 1. JSON 序列化 | 使用Json::FastWriter或Json::StyledWriter将Json::Value对象转换为字符串。 | this->jsonWriter->write(msg, &stream); |
| 2. 长度计算 | 计算序列化后字符串的长度nsPayloadLen。 | nsPayloadLen = nsPayload.length(); |
| 3. 长度校验 | 检查消息长度是否超过最大限制MessageMaxSize。 | if (nsPayloadLen > MessageMaxSize) { ... } |
| 4. 协议封装 | 将长度信息以"长度:内容,"的格式封装。 | std::sprintf(..., "%zu:", nsPayloadLen);WriteBuffer[nsNumLen + nsPayloadLen + 1] = ','; |
| 5. 异步写入 | 调用UnixStreamSocket::Write，通过 libuv 进行异步 I/O 写入。 | Write(WriteBuffer, nsLen); |
底层写入逻辑 (UnixStreamSocket::Write) 的策略选择：
// 策略一：尝试直接写入（同步，高效） written = uv_try_write(reinterpret_cast<uv_stream_t*>(this->uvHandle), &buffer, 1); if (written == static_cast<int>(len)) { return; // 全部写入成功，立即返回 } // 策略二：无法直接写入，转为异步写入 else if (written == UV_EAGAIN || written == UV_ENOSYS) { written = 0; // 重置写入长度，准备异步操作 } // 策略三：发生错误，关闭连接 else if (written < 0) { Close(); UserOnUnixStreamSocketClosed(this->isClosedByPeer); return; } // 异步写入剩余数据 size_t pendingLen = len - written; auto* writeData = static_cast<UvWriteData*>(std::malloc(sizeof(UvWriteData) + pendingLen)); std::memcpy(writeData->store, data + written, pendingLen); uv_write(&writeData->req, ..., static_cast<uv_write_cb>(onWrite));该实现优先使用uv_try_write进行非阻塞的同步写入以降低延迟；当内核缓冲区满时，回退到uv_write进行异步写入，避免阻塞事件循环，体现了高性能网络编程中常见的“乐观尝试，悲观兜底”的设计模式。
3. Notification 在信令交互中的角色
Channel 的通信模型可归纳为以下两类交互：
| 交互类型 | 触发方 | 数据流向 | 典型用例 |
|---|---|---|---|
| 请求-响应 (Request-Response) | 信令服务 | 信令服务 → Channel → 媒体层 → Channel → 信令服务 | createRouter,createWebRtcTransport |
| 通知推送 (Notification) | 媒体层 (主动) | 媒体层 → Channel → 信令服务 | "audiolevels"(音频电平),"dtlsstatechange"(DTLS状态变更) |
Notification 机制使得媒体层能够实时地将内部状态（如传输层状态变更、媒体流统计信息、异常事件）异步地告知信令服务，是实现诸如房间内用户音量监测、连接质量反馈、流状态同步等实时功能的基础。信令服务在收到这些通知后，通常会通过 WebSocket 等长连接协议进一步转发给对应的客户端，从而完成从底层媒体事件到前端用户界面的完整信息通路。
参考来源
- mediasoup源码分析(四)channel返回信令及notify通知
