基于mediasoup的多方通话研究（二）

前言

时隔多年未更新这个领域的技术博客，时间和精力在大把浪费，实属愧疚。自责之下苦研数月，将mediasoup v3的nodejs部分全部翻译成了c++语法，其中99%的保留了原汁原味的架构和设计,其中涉及到的细节且听我慢慢道来。

开篇之前

本文为进阶篇，更适合有点基础的读者，初学mediasoup的小伙伴请查阅相关入门资料。

今天要讲的内容我认为读者已经具备以下能力（否则容易一头雾水）：

1. 掌握nodejs基本语法和开发调试；

1. 精通c++开发，以及了解至c++20的新特性，并能熟练使用；

1. 熟悉mediasoup相关的部署、调试以及二次开发或者修改相关逻辑、业务等；

1. 熟悉windows、linux平台开发环境和编译环境；

1. 掌握nodejs和c++20下异步、协程；

1. 掌握webrtc协议和内部实现，能够独自完成webrtc代码编译、调试和业务开发等。

庖丁解牛

事件循环

在此我选用libuv，nodejs内部依托v8引擎和libuv，我们在此处翻译nodejs语法使用libuv这种单线程模型再好不过了，且框架性能优秀，语法简洁。

内部通讯

指的是mediasoup的上层nodejs部分与核心worker部分的通讯，我们可以发现每一个内部业务的请求都会有一个request:

async request(method: string, handlerId?: string, data?: any): Promise<any>

其内部原理是上层通过管道，将数据发送给worker，同时创建一个promise并返回给调用者执行await。等待worker返回结果后触发promise的两种处理结果pResolve, pReject。

管道的实现来自于libuv的uv_spawn,我们可以通过 uv_process_options_t的stdio等参数传递管道uv_stream_t句柄来完成跨进程的通讯。下面是libuv唤起子进程并传递管道句柄的实例：

int main() {
    loop = uv_default_loop();

    /* ... */

    options.stdio_count = 4;
    uv_stdio_container_t child_stdio[4];
    child_stdio[0].flags = UV_IGNORE;
    child_stdio[1].flags = UV_IGNORE;
    child_stdio[2].flags = UV_INHERIT_FD;
    child_stdio[2].data.fd = 2;
    child_stdio[3].flags = UV_CREATE_PIPE | UV_READABLE_PIPE | UV_WRITABLE_PIPE;
    child_stdio[3].data.stream = (uv_stream_t*)your_steam;
    options.stdio = child_stdio;

    options.exit_cb = on_exit;
    options.file = args[0];
    options.args = args;

    int r;
    if ((r = uv_spawn(loop, &child_req, &options))) {
        fprintf(stderr, "%s\n", uv_strerror(r));
        return 1;
    }

    return uv_run(loop, UV_RUN_DEFAULT);
}

在上面的实例中可以用your_steam来控制管道数据的读写，达到通讯的目的。

协程

管道通讯、子进程处理结果并返回，这个过程可能略微有点长，如果我们同步等待，显然会卡住系统导致后面的请求无法继续，要么我们引入线程池来队列处理任务。显然这两种做法都不是最优秀的。由此我们引入了协程的概念，请求发出去后我们原地等待（挂起），等业务处理完我们在继续执行下面的任务，而且此过程其他请求不会被阻塞，且在同一线程内完成。看看nodejs的实现：

async setPriority(priority: number): Promise<void>
{
    const reqData = { priority };

    const data = await this.#channel.request(
        'consumer.setPriority', this.#internal.consumerId, reqData);

    this.#priority = data.priority;
}

channel.request请求处理，await挂起任务等待结果，成功后将结果赋给data。这一过程在简短的一两行代码中就完成了异步求情、回调函数等复杂的业务逻辑，简直不要太爽哈。

如此看来我们翻译成c++的话协程也是最重最难的任务，建议大家多参考github上优秀的写成库。

外部通讯

上层api与客户端的通信靠的是websockets实现，诸如此类开源的优秀框架还是蛮多的，不多赘述。

在此，我推荐大家用的是uWebSockets，它性能优异卓越超群，且支持多种事件循环。由于我们使用的是libuv来作为主事件循环，uWebSockets天生支持libuv、且包含优秀的http支持能力，所以选uWebSockets舍我其谁。不过uWebSockets内部封装了libuv形成了新的事件循环，需要把我们的事件循环交给它：

uv_loop_t* uv_loop = uv_default_loop();
uWS::Loop* loop = uWS::Loop::get(uv_loop);

如此才能保证整个系统使用同一个事件循环。

Object

nodejs中的object显然是弱类型，且扩展非常容易。这点让c++操作起来是很麻烦的，不过还是可以尽可能地照猫画虎吧，我们用json包装object属性，虽说代码任务略微繁重，但是殊途同归嘛。谁让我们这么爱c++呢（手动狗头)。首选的json库nlohmann/json，也是因为性能优异，操作方便。举个例子：

json reqData = {
    { "producerId",  id.empty() ? uuidv4() : id },
    { "kind", kind },
    { "rtpParameters", rtpParameters },
    { "rtpMapping", rtpMapping },
    { "keyFrameRequestDelay", keyFrameRequestDelay },
    { "paused", paused },
};

使用起来还是很简单的。

纵观全局

如果上述五部分技术调研我们都已经完成，那么翻译nodejs部分就容易起来了。其余的工作大部分为重复性的翻译和调试，说起来简单做起来难，小伙伴们不妨试一下。

那么我们贴出一段代码，来对比下两种不同语法的异同之处：

const u = url.parse(info.request.url, true);
const roomId = u.query['roomId'];
const peerId = u.query['peerId'];

if (!roomId || !peerId)
{
    reject(400, 'Connection request without roomId and/or peerId');
    return;
}

logger.info(
    'protoo connection request [roomId:%s, peerId:%s, address:%s, origin:%s]',
    roomId, peerId, info.socket.remoteAddress, info.origin);

queue.push(async () =>
{
    const room = await getOrCreateRoom({ roomId });

    const protooWebSocketTransport = accept();

    room.handleProtooConnection({ peerId, protooWebSocketTransport });
})
.catch((error) =>
{
    logger.error('room creation or room joining failed:%o', error);

    reject(error);
});

void Server::OnConnectRequest(std::string requestUrl, const protoo::FnAccept& accept, const  protoo::FnReject& reject)
    std::string roomId = Url::Request(requestUrl, "roomId");
    std::string peerId = Url::Request(requestUrl, "peerId");
    
    if (roomId.empty() || peerId.empty())
    {
        MSC_ERROR("Connection request without roomId and/or peerId");
    
        reject(Error("Connection request without roomId and/or peerId"));
    
        return;
    }
    
    MSC_DEBUG("Peer[peerId:%s] request join room [roomId:%s]",
        peerId.c_str(), roomId.c_str());
    
    this->_queue.push([=]() -> coro_t<void>
    {
        Room* room = co_await getOrCreateRoom(roomId);
    
        MSC_WARN("Peer[peerId:%s] handleConnection [roomId:%s]",
            peerId.c_str(), roomId.c_str());
    
        auto transport = accept();
    
        room->handleConnection(peerId, true, transport);
    });
}

看起来大同小异，这里面coro_t是我封装的协程库，使用起来毕竟方便。

我们再看看运行后的效果图：

新特性

再看看这次改版支持的一些新特性吧：

1. 同时支持webRtcServer和webRtcTransport，其中webRtcServer指的是同一个worker可以复用一个端口，虽然不是全局一个端口，至少把之前的上万个端口节约到个位数了；

1. 支持单进程和多进程模式，worker部分提供了一个倒出函数可供使用，且该函数支持管道通讯（多进程）和回调函数通讯（单进程）两种方式：

extern "C" int mediasoup_worker_run(
  int argc,
  char* argv[],
  const char* version,
  int consumerChannelFd,
  int producerChannelFd,
  int payloadConsumeChannelFd,
  int payloadProduceChannelFd,
  ChannelReadFn channelReadFn,
  ChannelReadCtx channelReadCtx,
  ChannelWriteFn channelWriteFn,
  ChannelWriteCtx channelWriteCtx,
  PayloadChannelReadFn payloadChannelReadFn,
  PayloadChannelReadCtx payloadChannelReadCtx,
  PayloadChannelWriteFn payloadChannelWriteFn,
  PayloadChannelWriteCtx payloadChannelWriteCtx);

在此着重讲下单进程模式，回调函数的方式执行速度有一定的优势，且通讯方式的代码相对简单得多：

_channel = new ChannelNative;
_payloadChannel = new PayloadChannelNative;

std::vector<char*> vecArgs;
for (std::string spawnArg : spawnArgs)
{
    vecArgs.push_back(strdup(spawnArg.c_str()));
}

_work_thread = std::thread([=]() {
    auto statusCode = mediasoup_worker_run(
        vecArgs.size(),
        (char**)vecArgs.data(),
        __MEDIASOUP_VERSION__,
        0,
        0,
        0,
        0,
        ChannelNative::channelReadFn,
        _channel,
        ChannelNative::channelWriteFn,
        _channel,
        PayloadChannelNative::payloadChannelReadFreeFn,
        _payloadChannel,
        PayloadChannelNative::payloadChannelWriteFn,
        _payloadChannel);

    switch (statusCode)
    {
    case 0:
        std::_Exit(EXIT_SUCCESS);
    case 1:
        std::_Exit(EXIT_FAILURE);
    case 42:
        std::_Exit(42);
    }
});

直接写两个Channel和实现对应的回调函数即可，可节约代码和开发周期。

又到了放大招的时间

创作不易、开发不易，且行且珍惜。目前作者处于创业初级阶段，没有完全的实力去开源，大家莫怪，如有商务合作或者其他需求，可直接私信我。

在此还是向往常一样放出可运行文件，仅供大家参考，相互切磋。

如上:

1. certs为证书文件，为了支持https和wss;

1. public为web端静态文件；

1. config.json为服务器端配置文件；

1. 运行前需要把内部的announcedIp换成自己的局域网ip或者公网ip；

1. singleProcess默认为true，为单进程模式；false为多进程模式，会启动mediasoup-worker.exe；

1. useWebrtcServer默认为true，即单端口模式（一个worker占用一个端口）；

1. ClusterServer.exe为服务器主程序，双击直接运行即可；

1. WebServer.exe为web端主程序，双击即可运行，启动后与mediasoup-demo的前端无异。

下载地址：

链接: 百度网盘 请输入提取码 提取码: 29pm

结束语

时间飞逝，转瞬间已经从业十年。从初出茅庐到三个娃娃的奶爸，昨日的付出历历在目，今日的幸福来之不易，且行且珍惜。

后面抽时间会继续完善该系统，提起我的老本行，拾起写作的习惯。

继续开发Windows、MacOS以及linux客户端，完善整个前后端。