下载器 -- IPC 调研(备忘) -- 2024.09.15 旧稿发布

一、需求

对于自研下载器，我们可以直接复用 Aria2c 模块中的 XML-RPC 或者调研新的 IPC 通信。

二、现状

端内集成的 Aria2c 下载器使用定制的 MaiaIPC 进行通信：http post。会存在一些问题：

• Http 链接：N 组资源下载，需要在业务层维持 N 个 Http链接
• 状态查询：定时主动轮询，会存在 60% 以上的无效查询。
• 异常同步：强依赖状态查询。若不查询，则无法获取异常信息。

三、预期

新版 IPC 要能做到按需同步信息，主要是状态信息。按照现有的资源下载机制，新版 IPC 流程大致如下：

一些针对性改进：

• 在业务层面，client只需要提前简历两个链接；downloader 也只需跟对应的两个链接通信
• client 可以主动给 downlaoder 下发命令（暂停，继续等）; downloader 也可以主动上报（状态，异常等）

四、调研

1、gRPC
库过于庞大，存在过多无用功能。暂不考虑应用在 IPC 通信。

2、Microsoft IPC
C++ 模板库。但提供的功能单一，仅支持了同步的 REQ/REP 机制。后续持续跟进，并验证可用性。

3、ZeroMQ
轻量的嵌入式IPC库。具有相对灵活的可定制性。非 Win10 或者 Win10（17063 以下）系统，只能使用 socket。不过，unix domain socket 挺香。
(注：RabbitMQ, RocketMQ, Kafka 各有其用，不在本文考虑范围内)

五、实现

使用 ZeroMQ 实现 IPC 通信功能。PUB/SUB 通信模式如下：

六、建议

• win 10 (17063) 以下系统，只能使用 socket 进行 IPC 通信。
• 在 windows 环境下，zmq 使用 wepoll 开源库支持 epoll。经线上实践，wepoll 存在问题。因此， windows 环境下的 polling 机制建议选择 select。