增强管道数据流转技术（EPDR）

增强管道数据流转技术（Enhance Pipeline Data Routing，EPDR）是 taskBus 跨平台多进程合作框架创立的开源数据分发技术，在软件无线电方向已经具有了较为完整的应用场景。本文介绍技术的起源，简述从最初的前向数据复制（Forward Data Replication，FDR）发展到EPDR的过程。

1. 前向数据复制（FDR）技术

FDR技术通过定义一些简单的标记格式，允许通过 A.exe|B.exe|C.exe级联三个可执行文件时，C.exe也能直接获得A.exe的输出（靠B来复制）。

1.1 标准输入输出设备与重定向

“标准输入输出设备”是在DOS时代就非常常用的系统文件设备。执行一个DOS/Bash命令行时，命令进程内通常会自动打开三个标准文件句柄（指针），即标准输入文件（stdin），通常对应终端的键盘；标准输出文件（stdout）和标准错误输出文件（stderr），这两个文件都对应终端的屏幕。进程将从标准输入文件中得到输入数据，将正常输出数据输出到标准输出文件，而将错误信息送到标准错误文件中。这三个文件是不需要通过“file.open”这样的函数手工打开的，进程一旦启动，其自然存在。因此，可以像读写一般文件一样，读写这三个文件:

#include <stdio.h>
int main(int argc, char *argv[])
{
    unsigned int a[4];
    //scanf("%u,%u,%u,%u",a,a+1,a+2,a+3);
    //等效为
    fscanf(stdin,"%u,%u,%u,%u",a,a+1,a+2,a+3);
    for(int i = 0; i < 4; ++i)
        a[i] = 0xFFFFFFFF ^ a[i];
    //printf("%u,%u,%u,%u\n",a[0],a[1],a[2],a[3]);
    //等效为
    fprintf(stdout,"%u,%u,%u,%u\n",a[0],a[1],a[2],a[3]);
    fprintf(stderr,"%u,%u,%u,%u\n",a[0],a[1],a[2],a[3]);
    return 0;
}

这种连接着输入输出设备的文件句柄，是一种特殊的文件，管道（pipeline）。管道也是一类流式设备。经常接触的另一种流式的设备是套接字的Stream模式，对应的是TCP协议。管道则是单机版本的底层的流式数据，在层级上和TCP完全不同。在默认状态，如bash交互时，stdin连着键盘缓存，stdout\stderr连着显示缓存。

操作系统允许重定向这些管道。通过符号“<”、”>”、”|”可以进行重定向。其中，

“A.exe < 1.txt” 是从某个文件里读取内容，丢给当前程序。
“B.exe > 2.txt” 是把输出定向到文件，写入到磁盘。
“A.exe| B.exe” 则是把A进程的输出（stdout）交给下一个进程B的输入。

如：

$  ls -na | grep "Sep" | less

则是把列出文件（ls）的结果送给 grep程序，进行字符串“ Sep ” 的搜索匹配，以只列出九月份的文件。而后，如果九月份的文件很多，则进行分屏显示(less)。这里要注意的是一般只能把 stdout 送给 stdin，stderr一直都连着默认的设备。在命令行下，“|” 是可以传输二进制数据的。很多开源的工具借助这种方式完成复杂的任务。如RTL-SDR的广播收听:

$ rtl_fm -f 91.8e6 -s 200000 -r 48000 - | ffplay -f s16le -ar 48000  -showmode 1 -i -

但是要注意的是，在windows下自己写程序时，由于要避免\r\n替换、EOF转义等问题，要指定二进制模式, 见如下代码：

#include <io.h>
#include <fcntl.h>
int main(int argc,char * argv)
{
    //用于在windows下吞吐二进制数据。
    setmode(fileno(stdout), O_BINARY);
    setmode(fileno(stdin), O_BINARY);
    unsigned int a[4];
    fread(a,sizeof(int),4,stdin);
    for(int i = 0; i < 4; ++i)
        a[i] = 0xFFFFFFFF ^ a[i];
    fwrite(a,sizeof(int),4,stdout);
    return 0;
}

1.2 前向数据复制（FDR）技术

在早期进行控制台SDR程序设计时，遇到一种情况需要进行不同层级的数据访问。比如，SDR获取的数据，一方面要进行fm解调，并收听广播；另一方面，又想要进行频谱显示，如下：

FDR

由于”|”链接的管道是顺序的、单向的，因此上图中的两路处理必须合成1路，其中前序的某些EXE要为后续处理流程转发数据。
采用的思路是统一各个exe的输入输出格式，给原本无边界的流，切割为包。而后，标记包的ID，并复制到后一级。为了有效的完成这类请求，流式数据被切割为包，并加入头部：

包序号	数据类型ID	长度	内容
1	2字节	2字节	N字节
2	2字节	2字节	N字节
3	2字节	2字节	N字节
	……

程序都会解析所有的stdin输入。
被解析的输入包会立刻丢往stdout。
程序产生的数据也要封装后，送往 stdout。
程序需要自行确保包的原子性。

1.3 FDR的问题

FDR有几个问题：

流量浪费。所有前序的流量会在下一级叠加，导致巨大的浪费。要知道尽管管道比起TCP贴近内核，但是它的带宽也是有限制的。具体的测试参考这个测试，引用结论见下表。
无法闭环。整个数据流程是前序的，没有环结构。也就是进程A无法消费C的请求。这样一来，很多需要反馈的结构就很难做了。如控制吞吐节奏的水位操作。

管道虽然是内存设备，但是流量也是有上限的. 基于教研室的 i7 6700K @ 4GHz, 内存 64GB DDR4 @ 2666MHz. Linux发行版为 Manjaro,内核5.10, 进行的最大流量测试结果如下表：

操作系统	编译器	级联层数	整体速率	sc16单路带宽
windows 10 x64	Mingw64	1	7016.842 MB/s	1754.21 MHz
windows 10 x64	Mingw64	2	3621.510 MB/s	905.37 MHz
windows 10 x64	Mingw64	3	2419.891 MB/s	604.97 MHz
windows 10 x64	Mingw64	4	1813.055 MB/s	453.26 MHz
windows 10 x64	vc2022	1	6843.942 MB/s	1710.98 MHz
windows 10 x64	vc2022	2	3567.249 MB/s	891.81 MHz
windows 10 x64	vc2022	3	2429.300 MB/s	607.325 MHz
windows 10 x64	vc2022	4	1899.506 MB/s	474.87 MHz
Linux x64	gcc	1	4046.54 MB/s	1011.63 MHz
Linux x64	gcc	2	2122.48 MB/s	530.62 MHz
Linux x64	gcc	3	2126.54 MB/s	531.64 MHz
Linux x64	gcc	4	1985.11 MB/s	496.28 MHz

因此，如果一味的进行前向复制，很容易塞满系统的IO带宽。

2. 增强管道数据流转（EPDR）技术

FDR有不足，它的主要限制是BASH和DOS命令行的语法决定的。这种语法是前向（无环）、单列的。于是，自然而然会想到要自己做一个增强的Shell出来，要更加灵活地流转数据。

参考分布式计算和消息队列的概念，把数据分为专题（Subject、Topic之类）、并由一个专门的程序管理他们之间的消费关系。这个程序应是实现EPDR 的关键，它构造了一个总线，或者是交换Hub，用来流转各个进程的包数据。

2.1 EPDR 交换矩阵

无论是在windows还是在Linux下，一个父进程启动了某个子进程，便可以调用API获取它的stdin, stdout, stderr三个指针。因此，若管理者进程启动了一堆子进程，则可以用一个矩阵来交换他们的数据。

生产消费
上表对应的流转图如下：

生产消费

2.2 taskBus的命名

当我们着手开始把EPDR的想法实现为平台时，遇到了命名的问题。如何命名这个数据交换总线呢？就叫EPDR Platform如何？

团队里的成员都觉得不好。EPDR比较拗口，还是要找一个简明的词。由于我们几个好基友在入门计算机时，接触的第一个DOS命令行操作的编程是在Turbo-BASIC 1.0下完成的，而第一个管道操作是在Turbo C2.0下完成的，于是自然就想用一个缩写为 TB的词，如Turbo Bus。但是，擅用专属于Borland大神的Turbo这个名讳，显然是对Borland的历史有所冲撞。考虑到计算机里task是与“进程”比较贴切的词语，很自然的想到任务管理器等计算机词汇，便用了 taskBus，任务总线，来命名未来的产品。如此这般，取首字母还是TB，真是亲切。

2.3 taskBus的LOGO由来

taskBus的LOGO是一个着了火的兔子。这个Logo是由团队成员的孩子引出的。当吃着一盒巴士饼干，只认得Bus而不识Task的孩子，把白板上taskBus的字母读成了兔巴士，taskBus的中文翻译就定了。同时，也取兔子敏捷、巴士装得多的意义。

而后，孩子们手绘了兔子巴士的样子，并认为应该用纸糊一个。此外，为了突出兔子巴士开的快，就让它的钛合金表面被大气层摩擦出火花来，就有了下图。

3. 优势和不足

基于管道的吞吐，具有很多优势：

编程简单。在跨进程通信中，直接使用stdin, 要比其他技术的代码量小得多。无论是共享内存、第三方消息队列，还是DCOM、Socket、DBus，都不如 fread来的直接、简单。
平台无关。无论在Arm，PC，还是MIPS上，标准输入输出管道都是一致的。
工具链低耦合。主流的开发语言都支持标准输入输出管道，它是操作系统提供的底层特性，是语言无关的。同时，不依赖任何MQ中间件，开发程序时，无需配置链接特殊的库。
传输友好。经过平台的处理，结合管道本身的流式可靠性，进程间的传输是按包传输、无需连接、无损保序的，这种特性如果用网络来处理，UDP/TCP都无法兼顾，只有考虑上更高级的消息队列。但消息队列会带来工具链依赖。
离线调试。可以通过文件来进行调试。把录制的文件作为输入，直接用”<”重定向给这个模块，就能脱离平台在IDE里调试了。

但与集约化的平台（如 GNURadio, Pothos FLow）相比，在某些方面有显著的不足。

界面零碎。用不同语言开发的进程，会有各自的窗口。风格也不统一。
控制复杂。A进程要精确控制B进程的行为，比如设置音量、更新配置，需要额外的协议定义。比如taskBus的指令系统。这种协议会稍微增加复杂度。
平台即瓶颈。通过矩阵交换的数据流转，在平台上是资源密集的调度活动。在数据速率很高的情况下，CPU会吃紧。目前通过Qt的实现，吞吐率不是最优的。后续如果使用无动态内存分配的C语言来重构交换逻辑，性能会好的多。